Observing a dialogue between hex and Dom yesterday on #openguides has set me thinking.
We need to get our house in order. Kake predicted this a year ago, see http://openguides.org/mail/openguides-dev/2004-October/thread.html#575
I agree with Dominic that changes to 0.50 have been coming in too fast and furious to manage them effectively.
Anyway, I have some practical suggestions and ideas:
1. Subversion has a good branching mechanism that works, let's use it!
2. The trunk is for releases. Don't check things in here unless they are ready for release. In fact, Dom or whoever is release managing, should be the only one touching the trunk.
3. For someone hosting a guide running different software from the latest release, it would be useful if this was in a branch. This would make bug reporting much easier.
4. Create separate branches for each chunk of work. The RT ticket number provides a good central reference point for this.
5. Post comments to RT indicating progress on each change. Every change should be tied back to an RT number.
6. Changes need tests. I've been as guilty as anyone for negleting this. Each RT branch should include either new tests or modifications to existing tests that would fail if run before applying the change.
7. Changes need airing. If you can either present the change on a guide you are hosting (mirrors help here :)), or if you can persuade someone else to patch a guide they are hosting, it would be desirable to expose the change to people in the OG community for rigourous exercising. We need more beta sites for this. I will be hosting such in the near future - watch this space.
8. Even if you don't have commit access to the master OpenGuides repository, you can always run a local repository. In fact, I recommend mirroring the repository even if you do have commit access. svk is your friend here :). clkao++ svk rocks! see http://svk.elixus.org/
These are my thoughts on change management; the list is probably not complete, but enough ideas to make a start.
Ivor.