[development] ideal workflow - Re: Listen
drupal.beginner at wechange.org
Wed Jul 4 12:41:51 UTC 2007
Thank you Dries for your constructive reply.
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"
> 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
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?
Because we and the world need to change.
Intimate Relationships, peace and harmony in the couple.
More information about the development