On Wed, 2004-09-22 at 20:29 +0100, Mark McLoughlin wrote: > And I agree that you don't want random people taking up these tasks > without the ability to do a good job. But its no different from any of > the other responsibilities in GNOME - e.g. you don't find incapable > people taking up the maintainership of unmaintained modules. Most people > are aware of their capabilities and don't generally volunteer for tasks > unless they're pretty sure they're not going to embarrass themselves. You've forgotten about the (assistant) gnome-applets maintainer then ;) > > 5) Reviewing requests to break feature/API/ABI/code freezes More seriously, I was going to discuss this last night, but fell asleep. 1-4 are easily distributable. I fully support the idea of making these more community based. These tasks could easily be controlled by a "Release Manager" who arranged with interested volunteers who wanted to work on a part (say the release notes) and ensured that it was coordinated and sorted out. Number 5 is not something that can be handled by a single release manager, or a group of volunteers. Instead I would propose a "Technical Steering Committee" but the name sounds too much they act as the GNOME think-tank (to paraphrase Mark). The goal of this TSC would be to deal with goal #5. The TSC would consist of a small number (maybe at most 5) contributors selected by the community, who have a broad understanding of the codebase and are known to be sane in regards to release critical choices. They wouldn't have their own mailing list, instead carry their conversation out on d-d-l so that everyone could be involved. But in the end, for things like goal #5 it would be their approval you need. This doesn't sound too radically different from what we have now (little steps, little steps). However, it would allow us to choose a release manager who is free of corporate bias if that was deemed a required quality (although, I would be sad to not have JDub as release manager). The TSC would consist of people who were technically brilliant, whoever employs them. Since their focus wouldn't be on making the desktop better for redhat, or sun, or canonical, but instead making sure the desktop was a releasable product, and that 1.3k patch really did need to go in three days before the gold release. I do not propose the (assistant) gnome-applets maintainer for any position involving technical brilliance ;) --davyd (Assistant) GNOME Applets Maintainer -- http://davyd.ucc.asn.au/ PGP Fingerprint <http://davyd.ucc.asn.au/pgp> 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA
Attachment:
signature.asc
Description: This is a digitally signed message part