Change management process

Problem statement, goals, vision

The AMQP protocol development process suffers from a lack of cross-team organisation, which is most visible in the lack of progress made on most fronts, alternated with large, unclear changes in some areas.

The goal of this change management process is to:

1. Ensure that changes are properly scoped into manageable units of work;
2. Ensure that these units of work are properly documented and recorded;
3. Ensure that this work is either carried out as planned, or stopped for clear reasons;
4. Allow the PMC to have a meaningfull overview of all work in progress;
5. Allow outside teams to participate by submitting requests and bugs;
6. Ensure that we can provide a change log for protocol releases.

The vision is one in which changes are more formally scoped, better managed, and can this flow more predictably and smoothly from problem statement to tested proposal.

The cost of changing the protocol must be reduced, so that it becomes attractive for teams to contribute. Today the cost is unreasonably high and this is preventing active participation from all protocol developers.

Change scoping and types of change

Unclear scope is the biggest risk factor in change. If the scope of a unit of work is not very clearly defined, it becomes unreasonably expensive to manage the change. For software development, we tend to restrict the scope of a change by tying it to a specific issue:

• A bug
• A feature request
• A refactoring

Good developers learn to do one or other of these, never to mix them. We should apply the same discipline to the protocol development. That is, a protocol change should be one of these categories, never more than one.

The Change Manager

The responsibilities within the protocol development workgroup do not need to be formalised except for one position, namely the Change Manager (CM). Note that other responsibilities such as 'Editor' and 'Chair' may be formalised but this is beyond the scope of this present proposal.

The CM supervises change management process and reports to the PMC. The CM has the authority of rejecting any change proposal based on process quality criteria. For example, a change proposal that is not clearly scoped, or that does not follow the agreed process.

Automation and communications

The principal tool used for automating the change process is Jira, an issue tracking system. Jira has the advantage of collecting comments on a per-issue basis, avoiding the problem of "loose emails". Additional wikis and documents can be used to support the Jira-based documentation.

Workflow design principles

The goal of the workflow design is to keep it very simple to make changes, with a minimum of traffic by email and decisions by the PMC. At the same time, we assume that peer-review of requests and proposals will lead to quality solutions. That is, we promote clarity and communications above formality. However, this process is meant to be improved, and has probably been over-simplified to work as an initial version.

Basic workflow

1. Any developer can create a new issue, which is one of (a) a bug, (b) a feature request, (c) a refactoring request.
2. The CM accepts a new issue on behalf of PMC, if the issue meets basic quality standards for explanation, clarity, etc.
3. When an issue is accepted, Jira will send an email is sent to the dev list. At this stage other developers can comment on the issue, and challenge its validity, utility, etc.
4. The CM assigns new issues to workgroups when the responsibilities are clear. When not, the CM will hold the issue until the PMC can decide on whether a new workgroup must be started or not.
5. The workgroup has an unlimited time to answer the issue. However, all open issues will be reviewed at each PMC, and issues that are not resolved within 3-4 weeks will be reassigned, closed, or suspended.
6. When the workgroup has answered the issue, the CM will review the solution and if it meets basic quality standards for documentation and argumentation, the CM will resolve the issue.
7. When an issue is resolved, Jira will send an email to the dev list.
8. The CM will present all resolved issues to the PMC, who will vote on changes following a 2-3 week review period.
9. When the PMC accepts a change, the CM will close the issue.
10. The CM can also suspend, cancel, reopen issues as needed.

Workgroup constitution

We prefer the term "workgroup" to "sig", being more accurate. A properly constituted workgroup MUST contain developers of at least two competing AMQP implementations. The reason for this is to ensure that challenge and argumentation happens early in the process, not when solutions are presented for voting.

Quality rules

These are the basic quality rules that the CM is expected to enforce, with PMC backing:

1. Only meaningful issues are entered into the Jira.
2. Issues are properly specified as problems, not solutions.
3. Workgroups are properly constituted.
4. Workgroups make proper minutes of meetings.
5. Solution proposals are properly argued and documented.
6. Issues are handled by workgroups within a reasonable period.

Documentation

Documentation should be a workgroup, not a responsibility. That is, there should be a workgroup of "editors" who can handle documentation issues.