[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