Thank you Dries for your constructive reply. more below. On Tuesday 03 July 2007 14:52, Dries Buytaert wrote:
On 02 Jul 2007, at 21:05, Augustin (Beginner) wrote:
My main point is: please do listen to people who are better known than I am, when they talk about some overdue systemic changes.
The main reason that keeps patches from getting committed faster is the lack of good reviews. The main challenge is to increase the amount and the quality of patch reviews and to reduce the number of silly "+1"s.
Yes. I appreciate all of this. I'll browse through this thread and use it to improve the documentation (http://drupal.org/node/156119) to help ensure patches landing on the Green queue are really worth your time.
We should also change the perception that RTBC means "a core committer needs to look at this". When a patch is RTBC, it still means that everyone needs to look at it, and that's part of the reason why many patches are still in the RTBC queue. I'll try to be faster to send back these to the "code needs (better) review" status, if that helps. Ultimately, this is something everyone can help with. If a patch is in RTBC for too long, it probably means it could use more quality reviews.
Ultimately, Green patches are your responsibility (the 5 Green Team members). Our job, is to make sure that patches landing on the Green queue, are better reviewed and are indeed worth your time, so that you spend less time keeping the queue in good shape (more below). See: Rename "RTBC" to "Ready for commiter review" http://drupal.org/node/156637
Maybe we need a 'decay feature' that sets a patch back to 'code needs review' after 2 weeks as RTBC?
This feature would go against what many of us were asking. I am sure you didn't think this through :) 'decay feature' for RTBC : http://drupal.org/node/156714 -> won't fix :)
During the next couple of weeks, I'll pay close attention to my workflow and usage patterns surrounding the issue queues. I'll try to gather some statistics of why patches are rejected, and how much time is spent doing what. How frequently do I revisit an issue, and how often that means something useful was added to the issue? Things like that. I'll also keep an eye open for things that would help us.
Thanks for your constructive approach. Ideally, you would never have to lower the status from RTBC to PNW. Ideally, every patch landing on the green queue would only require your final thumb up (commit). Your findings will be useful in completing the documentation: we can learn and also direct new devs to it, and make sure that we, common devs, make better reviews. So, the aims really are: 1) YOU make sure the green queue is always very short and up to date. 2a) WE make sure you don't waste too much time in doing 1 (by making better and more thorough reviews) 2b) WE try to ensure that you need less and less to lower the status from RTBC to PNW. (same as 2a, with a different wording). 3) YOU would have more time to answer people's requests for "Concept Approval" ( http://drupal.org/node/156609), ensuring that a bad concept (one you wouldn't approve of) never gets to patch level). The whole idea is that you don't offer the future hunmonk's to spend a day with them talking about the proper implementation of their concept AFTER they have coded it, but BEFORE. (http://drupal.org/node/147723#comment-267970) 4) WE, in turn, would then waste less time (on doomed patches), and we would have more time for 2) and for making Drupal even better than it would otherwise be. 3 (and 4) can only happen as it should if 1 and 2 are properly handled. We must strive to initiate this virtuous circle (1 -> 2 -> 3 -> 4 -> 1 ...). I am trying to solve a social problem with social means :) (thanks, killes!) Same aim as before, but different approach. Is the above fair and acceptable to you? yours, Augustin. -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple.