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,10... 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,10... 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&... 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,10... 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,10... 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&... 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&parti... 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.