On Fri, 31 Oct 2008 11:36:35 -0400 Angela Byron <drupal-devel@webchick.net> wrote:
If you have better ideas on how to manage the process more efficiently, obviously we'd love to hear them.
Does anyone has some numbers about reviewers, maintainers and "patchers" behaviour? - Do most people prefer to submit/review patches to stable versions rather than development version? - Do maintainer respond quicker to patches submitted for the development version? - What is the average number of patches/review for each developer? I'm going to assume that: 1) proposed patches to stable are more than development 2) patchers are much more than reviewer 3) patches to development are committed faster Am I right? I think: 1) happens because people find easier to "live" on a stable release and they are writing a patch for a reasonably static code base that won't make their patch obsolete easily. And there is no chance that less than 20 maintainers can keep up with all the proposed patches before a new UNSTABLE hits the street. BTW I take this chances to say UNSTABLE releases are a very welcome addition. Thanks!!! 2) happens because a) it's more fun to write code than reviewing it b) it takes more responsibility to say "it works" than "it works for me". 3) It takes less responsibility to commit to a development version and... it is more fun. After all if you're a maintainer what's the fun of taking the responsibility of applying a patch to a problem that: is a feature but expose you to the risk of breaking something or is a fix to a bug you didn't experience? While a development version will always have its drawback maybe making easier to build up a development/testing environment and letting people understand where the "steering committee" and the development is going would help increasing the numbers of people getting involved in the new releases. A more detailed guide on "how to put up your testing environment for Drupal development" would help. That should take into account that development version is a moving target and suggest how to cope with it. I think learning how to cope with Drupal development branch is particularly important for a project like Drupal since it is used to make "great leap forward". That includes how to get information on what's going on. That's a place where DVCS may help... Reviewers live in limbo. Their work is important but there is no filter and there is no credit. Everybody can be a reviewer. In spite of increasing the number of reviewers I'd decrease them but give them more trust, credit and power. Patch queues frequently becomes very long democratic discussions... but very long... maybe there are too few BDFL. A voting system or just counting how many people are subscribed to an issue may give an idea to reviewers what are the hottest issues. I'd say that counting how many people are subscribed to an issue is a better thermometer. If you don't even want to be informed about what's going on for an issue I wouldn't say you're really interested. Somehow if the responsibility to commit to a stable version would be more shared across trustworthy credited people, maintainers may commit more frequently to stable. I think the project is missing "middle management". "Middle management" will also increase feedback to patcher. Even if their patch won't reach core at least there will be someone more "authoritative" explaining why. Ups this post was waiting in my draft queue... but it looks as a bad copy of what Larry just wrote... -- Ivan Sergio Borgonovo http://www.webthatworks.it