From Fedora Project Wiki

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 problem

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.

The app would maintain the current workflow, but make it simpler to execute. It will also automate tasks, decreasing the chances of human errors occuring.

The idea

This is what we've thought of at the moment. We haven't checked how easy the implementation bit will be:

  • FAS integration - easy to see details of each change owner, their contact details etc. can be easily queried
  • A template similar to the wiki template
  • The app can make semi automatic notifications to the mailing lists
  • The app will notify the wrangler of new changes - new proposals, new status changes; rather than him regularly doing it manually
  • Integration with rhbz and trac
    • Query bugzilla for status changes
    • Query trac for ticket status changes
    • Carry out simple tasks like opening the initial rhbz tracker bug and fesco trac ticket on behalf of the wrangler
    • Send out regular reminders to change owners and mailing lists etc.
  • Reporting:
    • One page reports - lists of proposed changes, wip changes, etc. - different views
  • Administrative levels of the app:
    • Wrangler - admin
    • Change owners (usually more than one) - edit/update privileges on their own tickets + add new ones
    • Public - read only access to generated reports
  • It'll be amazing to be able to record the history/time line of each change - the wiki permits this, at the moment