| [tools-pmc] Re: tools-pmc Digest, Vol 19, Issue 13 |
Ed,Eclipse has a whole heck of a lot of rulesActually, I don't think it has very many rules (committers must be voted in, new projects must be announced to the community, IP must be cleared before release, ...), so perhaps the problem is that we (we, the EMO, and we, the PMCs, and we, the Architecture Council) have not done a good job of explaining them to the committer community. I'd like to fix that, but how? Perhaps I should re-write the development process guidelines again but this time work on a simple one pager version? Based on your experience with EMF and Modeling and all the sub-projects and the various Bjorn-as-a-policeman issues you've dealt with, what would you suggest I put in that one-pager? Could you suggest an outline? I disagree. They change once a year when the Board approves a new version of the rules. Seriously, look at the CVS history around the development process documents and you'll see that they just don't change frequently (unless you consider once a year frequently)...that tend to change rather frequently. However, you believe they do change often, so I'm guessing that what's happening is that each time you find something that you didn't know, you make the assumption that the rules have changed when in fact the rules have been the same but that nobody noticed the incorrect situations before. So what's really happening is that the EMO is becoming more efficient and thus has more time to spend making sure the constraints that we (collectively, the Board, including the committers) set are being followed. - Bjorn --
[end of message] |