This is a brain dump of the conversation Jaroslav and I had about a new changes process application at FUDCon Beijing. The application will aim to replace the current change process which is spread out over the wiki, bugzilla and the fesco etc. trac instances.
The current change process, as documented here uses the wiki, bugzilla and fesco trac. In short, this is the process:
- Fill out a new feature proposal wiki page using the existing template and add wiki page categories to it
- The wrangler periodically checks the category page for any new proposals that may have been added
- The wrangler will then:
- announce on the mailing lists
- open a bug to track the change
- open a ticket on the fesco trac
- The wrangler will inform the change owner if the change is accepted etc. and again make the required announcements
- The wrangler is responsible for periodically checking the status of the proposal - its completion
The workflow, while step by step and clear has many areas where the most minuscule of errors can cause confusion. For example, if the reporter doesn't use both the required wiki page categories, the wrangler may not know that a new change has been proposed.
Another issue is that the wiki is difficult to query. For example, when the wrangler needs to send out e-mails to the change owners to check on the status of the proposed changes, the wrangler needs to individually visit each change page to get the e-mail address of the owner, and then send out e-mails manually. While some scripting is used to make these tasks easier, it's a work around, and not the best way this can be done.
A third major issue is the visibility of changes. It needs to be easy for a community member to look up the list of changes for a particular release cycle - preferably a single report.