I imagine that the group will decide rules on peer reviewing. For comparison, the Mozilla group has very elaborate rules for checkins, while Python has pretty much an innocent until proven guilty culture. (That is, you check something in, and if somebody complains, it gets removed.)
I don't think it is worthwhile trying to form these rules a priori.
That's fine. I just wanted to put it onto the agenda ...
We need rules like "NO FIXES BETWEEN FINAL BETA AND RELEASE" (Absolutely no fixes I mean) -- and those rules should apply to everybody.
Again, we'll let the rules come out of the group. For instance, what if an Emacs #foo.py# accidentally got checked in? Would you really require another beta release for that? Betas are a cost incurred by hundreds of people around the world.
My personal opinion is that, apart from the version number, a final beta should be exactly the same as the actual release. Accidentally checked-in stuff can cause accidents. So there is some reason for a careful release policy. But in your specific case, if the "final" beta that should lead to a release has been actually released (and tagged in the CVS), how should somebody be able to check something into it afterwards? That could only happen if there are problems with the CVS configuration and usage I guess ...
Ahh, the "it's the Wiki's fault" argument. I just checked the zip mailing list archive. 9 messages since Aug 1st. So neither email nor Wiki are good choices. Can you point to an example of a process that worked better for designing APIs?
I don't blame the Wiki in general. Wikis (together with mailing lists) are a good start. Sometimes we'd just need real meetings on real conferences I guess ... Joachim