[development] {Short issue queues need care - 7} Why we shouldn't close all issues without proper review.

Augustin (Beginner) drupal.beginner at wechange.org
Mon Sep 4 07:40:39 UTC 2006


Hello and welcome to the seventh edition of {Short issue queues need care}.



There is a long introduction, but I think it's worth your serious 
consideration. Thank you for reading it.


This week:
1} Why we shouldn't close all issues without proper review.
  a) Why we shouldn't close all issues without proper review.
  b) Necessary change in order not to waste precious developers' time
  c) Our collective goal
  d) The good news: we ARE making progress.
2} Featured short issue queues.
3} Why this report and how to cooperate?

*******************************************
1} Why we shouldn't close all issues without proper review.
*******************************************


Recently, there has been some people talking about closing ALL outstanding 
issues without any review. There are several reasons why this is a bad idea.

It it disturbs you that there are some many issues open, use the solution that 
some people have told me: Just ignore them. Just carry on scratching your own 
itch and ignore the state of the queue. Such people may stop reading here.

Actually, I have witnessed some subtle improvements since I started writing 
this (almost) weekly report. More on that further down.

  a) Why we shouldn't close all issues without proper review.
  ===========================================================

First, closing all the issues will not make the bugs (the real ones) 
disappear. 

Second, if their feature request is closed, it will not make people stop 
wishing that the feature were implemented. 

Third, sure, the issues can be reopened, but instead of having a long list of 
open issues, some of which could be closed straight away, we would have to 
worry about a much longer list of closed issues, wondering which one should 
be open.

Fourth, doing so would be an insult to all the people who took the time to 
report issues, to code a patch, etc, just for their work and comments to be 
discarded. What will happen is not that those issues (with all the comments 
and patches attached) will be reopened, but new ones will be opened, without 
any comment and without any patch. It is such a waste of time and efforts.

Fifth, this is THE MOST IMPORTANT REASON, what is needed is not mindlessly 
closing all the issues, but a subtle change of culture within the community.
2000 issues might be closed today, but unless this change takes place, within 
a few months the new queue will start growing again. 
So, what is it that needs to change?

Closing everything and saying "let's start anew" is like the heavy smoker who 
throws his cigarettes at 11:59pm on New Year's Eve, and says he quits smoking 
(or the porn addict who deletes his collection from his hard drive, and says 
he quits w**king!- see reuniting.info). I'm sure you know as well as I do 
that New Year resolutions do not last long.
What is needed is to quit smoking every day.


  b) Necessary change in order not to waste precious developers' time
  ====================================================================


There is a tendency (we all have) to say that all that matter is to "scratch 
one's own itch". I don't like that saying one bit. Yes, we all do scratch own 
own itches, but it shouldn't prevent us from helping other people scratch 
THEIR itches (have ever tried to scratch an itch between your own shoulder 
blades? It's so much nicer when a loving partner does it for you :) ).

The point is that we are part of a community and we should help each other. We 
all have time constraints (it is understandable, and there is nothing wrong 
with that), so we have limited time to devote to this particular project. 
Some can do more, and some can do less. That's ok. But we are still part of 
the community and we should not only push forward our own patches, but also 
look around and see who needs help with their patch, and help them to have 
their patch committed. 


Here is a very concrete example.
Look at this queue:
http://drupal.org/project/issues?projects=3060&states=14
The few guys responsible to deal with it really rock!! The queue never gets 
very long, and the issues are never more than a few days old.
When they come to work on Drupal, they just have a look at the above queue to 
see what needs their attention. 
They are not only scratching their own itch, but also working on behalf of the 
whole community.

My aim with this report is to make it so that the following issue queue 
reflects the same kind of achievement: 
http://drupal.org/project/issues?projects=3060&categories=bug&states=8
As you see, it is not THAT long (102 issues only).
But behind each of those issues, there is a guy or two who took the time to 
setup a test environment and code a patch. 
And you want to throw all their efforts by the window??

How long would it take you to deal with 5 of those issues? 
1 day? 1 week? 2 weeks? more?
Take 20 developers and the whole list could be done within that period of 
time.


  c) Our collective goal
  ======================


So, when that queue:
http://drupal.org/project/issues?projects=3060&categories=bug&states=8
becomes and remains as short as that one:
http://drupal.org/project/issues?projects=3060&states=14
then the community would have won!

Then the issue queue will take care of itself.
(obviously, we can later add the feature requests to the list).


EVERY issue set as PATCH NEEDS REVIEW and that issue does not get reviewed, it 
is a waste of a developer's time. (I'm sure you all have had this 
experience).

The problem is NOT that we don't have enough man-hours. 
The problem is that we waste too much time. We waste our own time, and we 
waste our co-developers' time.


I don't want to give a personal example (I am afraid to become bitter), so 
I'll take another example.

I just noticed that webchick changed the status of the 'signature' issue from 
'needs review' to 'postponed'.
She did so with a sigh so big that I heard it half way across the world.
She worked very hard on that issue, providing patch after patch. The only ones 
to give her feedback were the core-commiters, who are already overworked.
I feel bad for her because I could have helped her. Maybe if I had taken the 
time to give the patch a proper review, I may have been able to set the patch 
as RTBC. I (or anyone else) could have made a difference for her patch.

The same scenario is repeated at each release cycle, because we, the 
community, do not take the time to review other people's patches, scratch 
other people's itches.

I am not blaming anybody. Many of you DO review patches. And I try my best to 
do my share, according to the time I have available. But you get my point.


The issues queues I highlight every week were not chosen by chance, but for a 
specific purpose. 

The 7 queues highlighted here are ALL important: either they are about 
critical issues, or they are about issues where a developer has taken the 
time to provide a patch.



  d) The good news: we ARE making progress.
  ==========================================

The good news in all that ranting is that in the few weeks I have been writing 
this report, I have witnessed a lot of positive changes. 

Already a few of the queues I featured in earlier weeks are no longer part of 
the report because all the issues within had been dealt with. This proves 
that a significant number of developers do care, and give their time 
selflessly. Thanks to those.

Also, the general trend within the last 2 months for the Patches Need Review, 
is downwards. There are already fewer of them. 

All of this shows that we DO have enough man-hours. It's ok to ignore (for a 
while) all the feature requests without any patch attached. But if we make 
sure that our co-developers do not waste time coding patches that never get 
reviewed, then the community would become more efficient.

I'll keep reporting on the achievements of the developers community in my 
weekly update. 


If you want to help, I suggest you start by the queue #7. If there is nothing 
you can help with there, then choose one of the 6 other queues. 

If you do so, you can PM me (it encourages me :)) or see part 3} to show your 
participation, and to ask for help: this way we'll see that many developers 
care.


Thanks for reading :)

and more importantly: 

Thanks for scratching other people's itches.


*******************************************
2} Featured short issue queues.
*******************************************

There are 930 subscribers to this mailing list.
Is it possible that 20-50 of those read this report and decide to work 
together to lower the number of issues on each of the 7 queues featured this 
week?

Pick one list. See at the very end if you wish to officially 'adopt' one 
queue.

The number in parenthesis designs the number of issues 2 weeks old or more 
(i.e. issues most likely forgotten and not being dealt with).


(Queue #1) DRUPAL-4-6 critical issues:
http://drupal.org/project/issues?projects=3060&versions=12052,11555,11262,10237,9739,9703,7696,7636,7578,5660,7407&priorities=1&states=1,8,13,14,2
18/06/2006 : 24 (19) issues.
25/06/2006 : 8 (5) issues.
02/07/2006 : 5 (4) issues. 
07/08/2006 : 5 (5) issues.
14/08/2006 : 5 (4) issues.
22/08/2006 : 4 (2) issues.
04/09/2006:  5 (1) issues only.
Those are really critical issues, already fixed in head and 4.7. 
A few junior developers (myself and others) have tried to help out, here, but 
we lack the knowledge to solve them, and the seniority to decide to downgrade 
those issues ('normal' issue, or 'won't fix').
A senior developer is needed to decide the fate of those issues. If they are 
indeed very critical, then a patch is needed soon: can you at least tell how 
they should be fixed.



(Queue #2) DRUPAL-4-7 critical issues:
http://drupal.org/project/issues?projects=3060&versions=12050,11551,11252,10634,10412,10302,10273,10238,10195,9902,9842,9753,9728,10696&priorities=1&states=1,8,13,14,2
18/06/2006 : 31 (19) issues.
25/06/2006 : 12 (8) issues.
02/07/2006 : 7 (5) issues. 
07/08/2006 : 19 (13) issues.
14/08/2006 : 7 (0) issues.
22/08/2006 : 7 (0) issues.
04/09/2006:  18 (0) issues  only!
New critical issues keep coming every week, because 4.7 is the most used 
version. Most are not really critical, though.
(It should get better for Killes when 5.0 comes out).


(Queue #3) CVS critical bugs: 
http://drupal.org/project/issues?projects=3060&versions=6487&categories=bug&priorities=1&states=1,8,13,14,2
18/06/2006 : 6 (1) issues.
25/06/2006 : 13 (1) issues.
02/07/2006 : 15 (1) issues. 
07/08/2006 : 16 (3) issues.
14/08/2006 : 22 (5) issues.
22/08/2006 : 21 (6) issues.
04/09/2006:  33 (8) issues  only!
The rising number of issues is an indication of the state of turmoil cvs is 
in, after so many big patches have landed. But, as you know: cleanup has 
begun.

(Queue #4) DRUPAL-4-6 Patch Needs Review bugs:
http://drupal.org/project/issues?projects=3060&versions=12052,11555,11262,10237,9739,9703,7696,7636,7578,5660,7407&categories=bug&states=8
18/06/2006 : 26 (25) issues.
25/06/2006 : 26 (25) issues.
02/07/2006 : 25 (24) issues. 
07/08/2006 : 24 (23) issues.
14/08/2006 : 24 (23) issues.
22/08/2006 : 20 (2) issues.
04/09/2006:  11 (0) issues .
Most need to be bumped to cvs, if the bug still exists in HEAD. 
If the bug hasn't been fixed yet, try to reroll the patch for head, or else 
set as "patch needs work".
Thanks again to Fernando (and maybe others) who worked a lot to bring the 
number down.

(Queue #5) DRUPAL-4-7 Patch Needs Review bugs:
http://drupal.org/project/issues?projects=3060&versions=12050,11551,11252,10634,10412,10302,10273,10238,10195,9902,9842,9753,9728,10696&categories=bug&states=8
18/06/2006 : 17 (5) issues.
25/06/2006 : 16 (7) issues.
02/07/2006 : 21 (8) issues. 
07/08/2006 : 15 (11) issues.
14/08/2006 : 15 (4) issues.
22/08/2006 : 12 (5) issues.
04/09/2006:  9 (3) issues  only.
Make sure to note if the bug has been fixed in HEAD already: it would be silly 
to have a fix in 4.7, to see the bug reappear when 5.0 comes out.

(Queue #6) CVS Patch Needs Review bugs:
http://drupal.org/project/issues?projects=3060&versions=6487&categories=bug&states=8
18/06/2006 : 72 (67) issues.
25/06/2006 : 71 (67) issues.
02/07/2006 : 77 (66) issues. 
07/08/2006 : 72 (59) issues.
14/08/2006 : 88 (59) issues.
22/08/2006 : 81 (57) issues.
04/09/2006:  82 (64) issues .
As you see, many issues are old (over 2 weeks old: 64 issues), so we have the 
choice between :
 re-rolling the patch for current head, 
 set as code needs work, 
 or set as already fixed if appropriate.

(Queue #7) Your own list of Patch Needs Review bugs:
http://drupal.org/project/issues?projects=3060&categories=bug&states=8&participated=your_drupal_user_name
1) Follow the search link above, 
2) In the URL, replace "your_drupal_user_name" with your actual user name.
3) On the result page, click at the bottom of the page on the "#" link 
(Permalink to search query). 
4) bookmark the page. 

Those are issues you have already participated in, and you should already know 
the context. Help the person preparing the patch to eventually come up with a 
patch that can be RTBC. 
Obviously, if there are many results to the query, start from those issues you 
are the most familiar with...
If everyone does this, the result will be seen in the queues #4, #5 and #6 
above.




*******************************************
3} Why this report and how to cooperate?
*******************************************

There are now over 2200 issues in the queue.
The figure sounds daunting: how can a very few volunteer developers deal with 
such a huge amount of bugs?

The point is that we don't need to worry of the whole issue queue, but by 
getting somewhat more organized, the most important of those issues can be 
definitively dealt with. 

To start with, there shouldn't be anything critical within the Drupal project 
issues. Critical bugs must be dealt as a matter of priority. But one can get 
easily discouraged when facing 4 four pages of critical issues. 
The first step is therefore to sort out what is really critical from what is 
not.
Having a shortlist of what is really critical, two or three developers can 
focus on a single issue, helping each other, so that one week later there is 
one really critical issue less. Similarly, 10-12 developers could get rid of 
3-4 critical issues and in a few weeks, the list of critical issues would be 
down to almost nothing (only 1-2 issues caused by a large patch recently 
introduced in head, for example).



If you wish to participate in tackling one of the 7 short issue queues 
featured here, please reply to the list, quoting only the issue you wish to 
'adopt', changing also the subject title of your email to reflect the queue 
you have chosen. 
Hopefully, two or three more developers will reply to you, saying they want to 
help you with the issues in that same queue.



Thank you to all the volunteers for your cooperation.

Blessings,

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.


More information about the development mailing list