> 1/ Committers > > For example, I would > propose a consensus policy requiring any committer to relinquish his > rights before unsubscribing from the dev mailing list -- if we ever > suspect someone has "disappeared" from the project, we can ping him on > the list. If we do this, we will know how many active committers there > are, and we can react if it gets below a certain threshold.
Let's distinguish between literally unsubscribing from the group and ceasing to monitor the group. For example, I sometimes unsubscribe from a mailing list, because the list's messages overwhelm my "work" messages. Meanwhile, I monitor the archive. If the removal of my CVS rights were directly tied to the "unsubscribe" message to the mailing list software, I'd be upset. I agree with Michael Stover that we need to keep the numbers of committers manageable. To me, it looks like the group is close to the right size now. Fortunately, I think the level of interest of potential developers is roughly equal to the project's needs. > 2/ Contributions > > Even sloppy indenting contributes to the difficulties. Maybe we can tie a configurable "pretty-printer" to the check-in process. I've experimented with a free one called "jacobe." IMO, it needs a couple of minor improvements before I'd commit a project to using it. Perhaps somebody else knows of an alternative. > 3/ Long-term development plan > > At the very least, we need to agree on a > loose high-level end-user requirement list [I think I already have a > document of this kind somewhere -- the one I used to select JMeter among > other tools quite a few months ago]. A high-level plan is a good idea. However, since this is open source, it would amount to a suggestion. Any committer could still introduce code regardless of whether it were in the plan. Also, there is no way to force anybody to work on something that is in the plan (nor should there be). -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
