Positions
Chair - elected representative of WG as a whole. It is an elected position. Election is done once every six months. Chair may be reelected. (1 person)
Process manager - person responsible for guarding and enforcing formal process within the WG. It is an elected position. Election takes place either when process manager in charge resigns or when PMC is unhappy with process manager's performance. (1 person)
Documentation manager - person responsible for incorporating changes to AMQP documents. It is an elected position. Election takes place either when documentation manager in charge resigns or when PMC is unhappy with documentation manager's performance. (1 person)
Issue manager - person responsible for work on specific issue. Issue manager is selected from developers volunteering to do the task by the PMC. If there is no volunteer, representative that brought the issue to the the PMC is obliged to become the issue manager. (1 person per issue solved)
Representative - each party joined in WG has single representative with the right to vote, make decisions etc. How to select the representative is internal issue of each member party. (1 person per WG member)
Developer - person assigned to work on AMQP by WG member or reviewer. Developer is not necessarily an employee of member party that assigned him/her. PMC MAY remove a person from developer list either if he/she is not active on AMQP for a long time ("zombie developer") or if he/she deliberately and consistently ignores the process or if the member party that assigned him/her asks for the removal explicitly – for example when the developer quits working for the member. (Unlimited number of developers is allowed.)
When there is single person responsible (process manager, documentation manager, issue manager, representative) he/she should choose a substitute in advance that will be in charge when he/she is ill, on leave etc. Moving of position from original official to substitute and vice versa MUST be announced publicly (on mailing list) by either the official or by the substitute in case original official is unable to do it personally. The substitute assumes all the rights and responsibilities of the person being substituted once the public announcement is sent. Once the original person is available again and sends public announcement about it, he/she automatically resumes all the rights and responsibilities.
Issue workflow1
1. Statement of problem is submitted by a representative.2
2. Discussion3.
3. Representative that posted the statement of problem has right to move the issue to PMC for confirmation.
4. If an issue is not passed to PMC within 1 month4, process manager SHOULD mark it as rejected.
5. PMC confirms that the problem falls into the scope of AMQP and should be worked on. Confirmation is based on majority vote5. If PMC doesn't confirm the problem, it MUST be rejected. PMC also assigns the issue to chosen volunteer thus making him/her issue manager and sets a deadline for its completion.
6. Discussion6.
7. Issue manager writes a formal proposal based on concensus reached in discussion.
8. Discussion7.
10. When concensus is reached, issue manager incorporates the changes into formal proposal and passes the solution to PMC.
11. PMC votes on the proposal. Acceptance is based on majority vote8. If proposal fails, it MUST be rejected.
12. Documentation manager incorporates accepted proposals into the documentation9. This SHOULD be done within 1 week.
1 Issue wokrflow is a linear process. There are no loops there so it is impossible for any party to slow down the development by reiterating the process. Each step in the process has clearly defined deadline. Deadline can be changed by PMC vote if convincing reasons are presented. It follows that each issue is either rejected or solved in the time determined in advance. Also each step of the process has a single person responsible for it. This avoids the problem of shared responsibility. If something goes wrong there's single person responsible for it. Failure will thus result in loss of credibility and PMC will be obviously hesitant about assigning new tasks to the same person.
2 In fact, statements of problem MAY come from any developer or from the public, however, submission must be done by a representative to have a single person responsible for the issue.
3 Each round of discussion MUST take at least 1 week; it may take longer but issue deadline should be kept on mind. Issue manager is obliged to report on the progress of the issue to PMC and WG as a whole at least once a week (in case discussion lasts longer than 1 week). Also note that there are 3 rounds of discussion in the workflow. This copies existing 3 week process.
4 As the statement of problem haven't passed through the PMC so far, there's nobody to set deadline for it. Therefore one month period is used as default deadline.
5 Each voting results either in issue being moved to another step of the process or rejecting it altogether. This seems to be dangerous but NB that the issue is proposed for voting by the party that advocates the issue, so it is in their best interest not to move controversial issues for voting until group concensus is reached.
6 See note 3.
7 See note 3.
8 See note 4.
9 There is no formal reviewing step for the documentation. Typos can be corrected using rapid editorial process. If the proposal introduced into documentation does not match the one accepted by PMC, the issue should be brought back to PMC either by process manager or by a representative.
Rapid editorial process
- Editorial changes like corrections of typos and obvious errors should be passed to PMC.
- They are voted on en masse on the next PMC meeting.
- If at least one representative objects about specific editorial change, the change MUST be rejected, but may be entered into process once more as a statement of problem (following standard process).
Process manager
Process manager MUST watch all the WG traffic and cry out if process is not being observed.
Process manager MUST keep all the deadlines under control.
Process manager MAY warn in advance if specific issue looks like it won't match the deadline
If process is not observed or deadline is not matched, process manager MUST pass the issue to PMC. It MUST be done publicly to allow everyone to monitor the work of process manager.
PMC either warns the issue manager and asks him/her to get the things right or reassigns the issue to different person.
PMC and WG as a whole should observe the work of process manager and complain if there are problems.
PMC can change process manager at any point if he/she doesn't fulfil his/her duties well.
Documentation manager
Documentation manager MUST incorporate all the proposals accepted by PMC into the documentation in 1 week time.
Documentation manager SHOULD try to keep original wording of the proposal intact.
Process manager and WG as a whole should monitor documentation manager's work and report any problems to the PMC.
PMC can change documentation manager at any point if he/she doesn't fulfil his/her duties well.