{Short issue queues need care - 7} Why we shouldn't close all issues without proper review.
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.
On 04 Sep 2006, at 09:40, Augustin (Beginner) wrote:
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 agree. I often spend 2+ hours a day reviewing patches, and when I post an occasional patch myself, it doesn't always get the quality reviews it deserves. (I understand that my position is exceptional.) If people spent time reviewing your patches, try to return the favor, and review other people's patches. Of course, you're free to do what you want, but it sounds like a good, social guideline. Not getting a decent review for your patch turns people off, and we should avoid letting this happen. Quite the contrary, we should provide them with constructive reviews and help them get on board. Some of them will 'stick' and help review patches too. Now we're in code freeze mode, this is particularly important. Let's do our best to make new people stick and to review an insane amount of patches together. :) -- Dries Buytaert :: http://www.buytaert.net/
In the last few weeks I was able to review a few hundred (about 400) issues that were inserted in the issue tracker. These are some thoughts: 1. People have the habit to request features for the Drupal version they use, instead of requesting them in the HEAD. We could have a way to stop users from adding these requests to versions other than HEAD 2. Support requests stay months without a single response! In my opinion there is no gain in putting support requests in the issue tracker. A forum is the right place to discuss support, and if in some cases these requests generate a feature or a bug report then they would be inserted in the right place. OTOH, if we continue to have support requests in the tracker, we should had them a "valid for" date.(e.g. close automatically all suport requests older than 4 weeks) 3. Patches (and bugs) stay in older queues for too long. It seems that no one has interest in working and reviewing older patches. I think that to have a good issue flow, we need to be more responsable in solving ASAP older bugs and not let them increase as it happens today. Regards, Fernando Silva On 9/5/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
On 04 Sep 2006, at 09:40, Augustin (Beginner) wrote:
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 agree. I often spend 2+ hours a day reviewing patches, and when I post an occasional patch myself, it doesn't always get the quality reviews it deserves. (I understand that my position is exceptional.)
If people spent time reviewing your patches, try to return the favor, and review other people's patches. Of course, you're free to do what you want, but it sounds like a good, social guideline.
Not getting a decent review for your patch turns people off, and we should avoid letting this happen. Quite the contrary, we should provide them with constructive reviews and help them get on board. Some of them will 'stick' and help review patches too.
Now we're in code freeze mode, this is particularly important. Let's do our best to make new people stick and to review an insane amount of patches together. :)
-- Dries Buytaert :: http://www.buytaert.net/
I think ideas #1 and #2 are definitely very welcome. Regards, introfini ________________________________ From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Fernando Silva Sent: Tuesday, September 05, 2006 4:13 PM To: development@drupal.org Subject: Re: [development] {Short issue queues need care - 7} Why we shouldn'tclose all issues without proper review. In the last few weeks I was able to review a few hundred (about 400) issues that were inserted in the issue tracker. These are some thoughts: 1. People have the habit to request features for the Drupal version they use, instead of requesting them in the HEAD. We could have a way to stop users from adding these requests to versions other than HEAD 2. Support requests stay months without a single response! In my opinion there is no gain in putting support requests in the issue tracker. A forum is the right place to discuss support, and if in some cases these requests generate a feature or a bug report then they would be inserted in the right place. OTOH, if we continue to have support requests in the tracker, we should had them a "valid for" date.(e.g. close automatically all suport requests older than 4 weeks) 3. Patches (and bugs) stay in older queues for too long. It seems that no one has interest in working and reviewing older patches. I think that to have a good issue flow, we need to be more responsable in solving ASAP older bugs and not let them increase as it happens today. Regards, Fernando Silva On 9/5/06, Dries Buytaert <dries.buytaert@gmail.com> wrote: On 04 Sep 2006, at 09:40, Augustin (Beginner) wrote: > 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 agree. I often spend 2+ hours a day reviewing patches, and when I post an occasional patch myself, it doesn't always get the quality reviews it deserves. (I understand that my position is exceptional.) If people spent time reviewing your patches, try to return the favor, and review other people's patches. Of course, you're free to do what you want, but it sounds like a good, social guideline. Not getting a decent review for your patch turns people off, and we should avoid letting this happen. Quite the contrary, we should provide them with constructive reviews and help them get on board. Some of them will 'stick' and help review patches too. Now we're in code freeze mode, this is particularly important. Let's do our best to make new people stick and to review an insane amount of patches together. :) -- Dries Buytaert :: http://www.buytaert.net/
Feature requests that's not gonna make it into core should also be an own category. Also I don't think we should have a "valid date", since then people will have to bump their issues over and over again... introfini wrote:
I think ideas #1 and #2 are definitely very welcome.
Regards, introfini
________________________________
From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Fernando Silva Sent: Tuesday, September 05, 2006 4:13 PM To: development@drupal.org Subject: Re: [development] {Short issue queues need care - 7} Why we shouldn'tclose all issues without proper review.
In the last few weeks I was able to review a few hundred (about 400) issues that were inserted in the issue tracker.
These are some thoughts: 1. People have the habit to request features for the Drupal version they use, instead of requesting them in the HEAD. We could have a way to stop users from adding these requests to versions other than HEAD
2. Support requests stay months without a single response! In my opinion there is no gain in putting support requests in the issue tracker. A forum is the right place to discuss support, and if in some cases these requests generate a feature or a bug report then they would be inserted in the right place. OTOH, if we continue to have support requests in the tracker, we should had them a "valid for" date.(e.g. close automatically all suport requests older than 4 weeks)
3. Patches (and bugs) stay in older queues for too long. It seems that no one has interest in working and reviewing older patches. I think that to have a good issue flow, we need to be more responsable in solving ASAP older bugs and not let them increase as it happens today.
Regards, Fernando Silva
On 9/5/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
On 04 Sep 2006, at 09:40, Augustin (Beginner) wrote:
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 agree. I often spend 2+ hours a day reviewing patches, and when I post an occasional patch myself, it doesn't always get the quality reviews it deserves. (I understand that my position is exceptional.)
If people spent time reviewing your patches, try to return the favor, and review other people's patches. Of course, you're free to do what you want, but it sounds like a good, social guideline.
Not getting a decent review for your patch turns people off, and we should avoid letting this happen. Quite the contrary, we should provide them with constructive reviews and help them get on board. Some of them will 'stick' and help review patches too.
Now we're in code freeze mode, this is particularly important. Let's do our best to make new people stick and to review an insane amount of patches together. :)
-- Dries Buytaert :: http://www.buytaert.net/
On 5-Sep-06, at 11:13 AM, Fernando Silva wrote:
In the last few weeks I was able to review a few hundred (about 400) issues that were inserted in the issue tracker.
These are some thoughts: 1. People have the habit to request features for the Drupal version they use, instead of requesting them in the HEAD. We could have a way to stop users from adding these requests to versions other than HEAD
Sure. This option should be added as a patch to Project module: http://drupal.org/project/issues/project
2. Support requests stay months without a single response! In my opinion there is no gain in putting support requests in the issue tracker. A forum is the right place to discuss support, and if in some cases these requests generate a feature or a bug report then they would be inserted in the right place. OTOH, if we continue to have support requests in the tracker, we should had them a "valid for" date.(e.g. close automatically all suport requests older than 4 weeks)
I actually disagree on this point. While many support requests may go unanswered, that is by far not the rule. Support posts in the forums can go unanswered, too. A lot of it has to do with how the request is phrased, how much detail is given to help people track down the problem, and so on. And for contrib authors, the 'support request' status is a god-send. It saves us having to patrol the forums looking for people who have problems with our modules, and provides one centralized place for all issues related to them.
3. Patches (and bugs) stay in older queues for too long. It seems that no one has interest in working and reviewing older patches. I think that to have a good issue flow, we need to be more responsable in solving ASAP older bugs and not let them increase as it happens today.
People tend to go after patches and bugs that they either come across the need for themselves through building sites, or that clients ask them to fix; i.e. once they have "an itch." It's very difficult to force volunteers to look after things that fit neither of these criteria. Realistically, a fair portion of this responsibility is on the bug reporter/patch creator themselves. The best thing a one can do to try and prevent this "staleness" from happening to them is to create high- quality issues in the first place that clearly state what the problem is, why it's broken, how it should work, how the attached patch fixes the problem (if appropriate, annotated with a screenshot), and/or exact steps on how to reproduce the bug in question. I've also been advocating for people new to the Drupal community (such as the SoC students) who are looking for a way to get their feet wet and get involved, to play patch and bug bingo, which is another way to get these old patches and issues looked at. -Angie
On Sep 5, 2006, at 9:02 AM, Angela Byron wrote:
1. People have the habit to request features for the Drupal version they use, instead of requesting them in the HEAD. We could have a way to stop users from adding these requests to versions other than HEAD
Sure. This option should be added as a patch to Project module: http://drupal.org/project/issues/project
not to nit pick, but this should really be a feature request for the Project issue tracking module, instead: http://drupal.org/project/issues/project_issue ;) that said, it's going to be a little tricky to do this in a way that's not entirely specific to drupal.org's use of project issue tracking. we'd have to somehow provide a way for project owners to specify what categories are valid for each version of their project. keep in mind that in the new world order of releases, there could be N branches where new features are valid requests... the drupal core project itself won't have this problem, but i'm not interested in hard-coding this behavior into the project_issue codebase and having a special-case hack for the drupal core project... so, if you're going to post the feature request about this and work on a patch, please keep this in mind. ;) back to the original point of this thread: i strongly agree w/ Augustin's position that we should *not* just blindly close all the issues older than a certain date relative to a certain version, etc. issue queues are sorted by most-recently-touched by default, and you can easily ignore pages 2-N if you don't want to worry about the old stuff. but, by automatically closing issues, we definitely lose a lot of info, and make it harder for the people (like augustin, myself, and others) who have whatever bizzare disease it is that makes us anal about cleaning up old issue queues. ;) there's been a lot of progress on this cleanup work already (thanks in large part to augustin's efforts) -- let's just keep that going and see where we are in 3-6 months. thanks, -dww
A bug is a bug, untill it is squashed. The fact that no-one looked at an issue for a while, nor the fact that few people seem to encounter the bug changes that fact! A feature request remains a valid request untill the feature is either introdiuced, or solved in a similar way, or else proven to be inapropriate. "being very long in a queue" has nothing to do with fixing a feature request. Closing bugs, or feature requests because our searching and organising methods suck is not a solution to the real problem! If we are swamped in bug reports that means we either have a system that is severely broken (more bugs come in then get fixed), or that we lack the infrastructure to keep the bug reports up to date. I am certain it is the latter :) Project module is being actively maintained again. So lets focus on a real solution. Not on some half-witted "abuse issue states because we cannot mange the issues right now" solution". We might need alternative States, or else additional metadata to enhance maintainability. But "closed" is a state! It tells us that an issue is closed (doh). "has been open for too long" could be a flag on an issue, it might even lead to closing at some point (the issue is for 80% fixed in Drupal 4.7, please update your 3.2 version to 4.7) but is never the same as "closed". Bèr
I thoroughly agree. Remember, these are just rows in a database, they are not Bird Flu cases. Closing old threads is not changing anything, it is just fudging the data so that your report (ie. the queue) looks nicer. So, I'm not sure how this coversation started, but I sure hope this is how it ends. Bèr Kessels wrote:
A bug is a bug, untill it is squashed. The fact that no-one looked at an issue for a while, nor the fact that few people seem to encounter the bug changes that fact! A feature request remains a valid request untill the feature is either introdiuced, or solved in a similar way, or else proven to be inapropriate. "being very long in a queue" has nothing to do with fixing a feature request.
Closing bugs, or feature requests because our searching and organising methods suck is not a solution to the real problem!
If we are swamped in bug reports that means we either have a system that is severely broken (more bugs come in then get fixed), or that we lack the infrastructure to keep the bug reports up to date. I am certain it is the latter :)
Project module is being actively maintained again. So lets focus on a real solution. Not on some half-witted "abuse issue states because we cannot mange the issues right now" solution".
We might need alternative States, or else additional metadata to enhance maintainability. But "closed" is a state! It tells us that an issue is closed (doh). "has been open for too long" could be a flag on an issue, it might even lead to closing at some point (the issue is for 80% fixed in Drupal 4.7, please update your 3.2 version to 4.7) but is never the same as "closed".
Bèr
Bèr Kessels wrote:
We might need alternative States, or else additional metadata to enhance maintainability. But "closed" is a state! It tells us that an issue is closed (doh). "has been open for too long" could be a flag on an issue, it might even lead to closing at some point (the issue is for 80% fixed in Drupal 4.7, please update your 3.2 version to 4.7) but is never the same as "closed".
"Deferred" and "Won't Fix" are commonly used issue states. Others achieve the same effect by having a priority of "trivial" or similar, with the understanding that issues below a certain priority almost never get fixed. But it strikes me that an obvious first thing to do is to add a "search by date" to the issue tracker. Specifically being able to search by the creation date, last update date, and last state change date, with both earliest and latest fields possible. I've never looked at the tracker's data schema, but I'd expect the first two to be relatively straightforward while the last could require an additional field. Once you have the ability to filter by dates, there's less need to close old issues arbitrarily. Gary
On 05 Sep 2006, at 18:02, Angela Byron wrote:
2. Support requests stay months without a single response! In my opinion there is no gain in putting support requests in the issue tracker. A forum is the right place to discuss support, and if in some cases these requests generate a feature or a bug report then they would be inserted in the right place. OTOH, if we continue to have support requests in the tracker, we should had them a "valid for" date.(e.g. close automatically all suport requests older than 4 weeks)
I actually disagree on this point. While many support requests may go unanswered, that is by far not the rule. Support posts in the forums can go unanswered, too. A lot of it has to do with how the request is phrased, how much detail is given to help people track down the problem, and so on.
And for contrib authors, the 'support request' status is a god- send. It saves us having to patrol the forums looking for people who have problems with our modules, and provides one centralized place for all issues related to them.
What I'd like to see happen is this: - Make the project module automatically maintain a system vocabulary called 'project' where each project name corresponds with a 'term'. Then allow people to categorize forum topics using the project vocabulary. - Extend the project pages with a link: 'show all forum topics about $project'. This would provide a mechanism to categorize content per project, and to filter the forum topics by project. -- Dries Buytaert :: http://www.buytaert.net/
On 9/6/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
What I'd like to see happen is this:
- Make the project module automatically maintain a system vocabulary called 'project' where each project name corresponds with a 'term'. Then allow people to categorize forum topics using the project vocabulary.
- Extend the project pages with a link: 'show all forum topics about $project'.
This would provide a mechanism to categorize content per project, and to filter the forum topics by project.
Sounds like a good idea. Ideally, we would remove all the 'support' forum areas, and we would instruct users to submit all support requests as issues. But that, of course, is completely unrealistic: people are always going to post support requests in the forums. So the best solution is to allow us to easily find support forum topics related to particular modules. Perhaps we could even use views to show a page that lists all the support issues and all the support forum topics for a particular module, together on one page? Or maybe we don't even need views for this - I guess we could just do it using taxonomy (but views would be better - e.g. for sorting by date, for showing last updated date, etc). Cheers, Jaza..
On 06 Sep 2006, at 09:23, Jeremy Epstein wrote:
Sounds like a good idea. Ideally, we would remove all the 'support' forum areas, and we would instruct users to submit all support requests as issues. But that, of course, is completely unrealistic: people are always going to post support requests in the forums.
I think we should do the opposite, and use the forums exclusively for support. Combined with the categorization, that should give us the required tools to make this feasible. -- Dries Buytaert :: http://www.buytaert.net/
I'm on your side in this option. Forums are the right place to discuss support! Any user can give support to others without having to go through an issue tracker that seems more connected to development. On 9/6/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
On 06 Sep 2006, at 09:23, Jeremy Epstein wrote:
Sounds like a good idea. Ideally, we would remove all the 'support' forum areas, and we would instruct users to submit all support requests as issues. But that, of course, is completely unrealistic: people are always going to post support requests in the forums.
I think we should do the opposite, and use the forums exclusively for support.
Combined with the categorization, that should give us the required tools to make this feasible.
-- Dries Buytaert :: http://www.buytaert.net/
Jeremy Epstein wrote:
Sounds like a good idea. Ideally, we would remove all the 'support' forum areas, and we would instruct users to submit all support requests as issues. But that, of course, is completely unrealistic: people are always going to post support requests in the forums. People are always going to post support requests in the forums. People are always going to post bug reports in the forums. People are always going to post support requests in the issue tracker. People are always going to post bug reports in the issue tracker.
People are notoriously bad at figuring out whether something is a bug or a support request. The same question is often both (i.e., yes it's a bug, here's a workaround). There are no perfect solutions, short of eliminating one or the other submission mechanisms entirely. The best that can be hoped for is to make it easy to convert from one to the other, and that's not trivial. Personally, I believe that new open source projects should sidestep the problem by picking exactly one mechanism, but once several mechanisms have become entrenched, it's difficult to remove them. In the meantime, there are lots of ways to improve forum search, starting with the categorization already mentioned. Gary
On Sep 5, 2006, at 11:35 PM, Dries Buytaert wrote:
- Make the project module automatically maintain a system vocabulary called 'project' where each project name corresponds with a 'term'. Then allow people to categorize forum topics using the project vocabulary.
- Extend the project pages with a link: 'show all forum topics about $project'.
sounds nice. the only problem is a namespace collision. project already creates a system volcabulary called "project" which is the (rather wonky, all things considered) module categorization system. i think this new proposal for the system-wide "project" taxonomy makes more sense to be called "project". what's currently called "project" should probably be renamed "project types" (or something). otherwise, this seems like a nice addition. unless there are major objections in the next day or so, someone should submit this as a feature request (this time against project.module *grin*) http:// drupal.org/node/add/project_issue/project/feature thanks, -derek (dww)
On Wed, 6 Sep 2006, Dries Buytaert wrote:
On 05 Sep 2006, at 18:02, Angela Byron wrote:
And for contrib authors, the 'support request' status is a god-send. It saves us having to patrol the forums looking for people who have problems with our modules, and provides one centralized place for all issues related to them.
What I'd like to see happen is this:
- Make the project module automatically maintain a system vocabulary called 'project' where each project name corresponds with a 'term'. Then allow people to categorize forum topics using the project vocabulary.
- Extend the project pages with a link: 'show all forum topics about $project'.
This would provide a mechanism to categorize content per project, and to filter the forum topics by project.
Damn good idea! It would also allow to recategorize previous forum topics by project (with some regepx based automatism and/or by hand). Gabor
- Make the project module automatically maintain a system vocabulary called 'project' where each project name corresponds with a 'term'.
already done. see NAT.module (node associated term) at http://drupal.org/node/59096
FWIW, I've got a pretty trivial termreference.module/patch up at http://drupal.org/node/82366 for CCK. I had the same need as Moshe's NAT, to link a node to a related forum/term listing page, but felt like getting into CCK a bit. Rob Roy Barreca Founder and COO Electronic Insight Corporation http://www.electronicinsight.com rob@electronicinsight.com Moshe Weitzman wrote:
- Make the project module automatically maintain a system vocabulary called 'project' where each project name corresponds with a 'term'.
already done. see NAT.module (node associated term) at http://drupal.org/node/59096
Erm, except mine doesn't auto-create terms yet, just links to existing terms. Rob Roy Barreca Founder and COO Electronic Insight Corporation http://www.electronicinsight.com rob@electronicinsight.com Rob Barreca wrote:
FWIW, I've got a pretty trivial termreference.module/patch up at http://drupal.org/node/82366 for CCK. I had the same need as Moshe's NAT, to link a node to a related forum/term listing page, but felt like getting into CCK a bit.
Rob Roy Barreca Founder and COO Electronic Insight Corporation http://www.electronicinsight.com rob@electronicinsight.com
Moshe Weitzman wrote:
- Make the project module automatically maintain a system vocabulary called 'project' where each project name corresponds with a 'term'.
already done. see NAT.module (node associated term) at http://drupal.org/node/59096
On 9/6/06, Rob Barreca <rob@electronicinsight.com> wrote:
Erm, except mine doesn't auto-create terms yet, just links to existing terms.
In the spirit of combining efforts, any way this could become a NATfield? Might make sense... -- Boris
In the spirit of combining efforts, any way this could become a NATfield? Might make sense... Sure thing. I just found out about the NAT module right now and will definitely look into it for round 2.
Rob Roy Barreca Founder and COO Electronic Insight Corporation http://www.electronicinsight.com rob@electronicinsight.com Boris Mann wrote:
On 9/6/06, Rob Barreca <rob@electronicinsight.com> wrote:
Erm, except mine doesn't auto-create terms yet, just links to existing terms.
In the spirit of combining efforts, any way this could become a NATfield? Might make sense...
-- Boris
Augustin (Beginner) wrote:
(Queue #3) CVS critical bugs:
Every time I even think about searching these lists, looking for something within my ability to tackle, I stumble right here. Why is Drupal concerned with bugs in the CVS project? :-) Does this really mean trunk? (Not HEAD, either, since HEAD is a tag, not a branch.) If so, can it be changed? If not, then what does it mean? Thanks, Gary
On Wed, 6 Sep 2006, Gary Feldman wrote:
Augustin (Beginner) wrote:
(Queue #3) CVS critical bugs:
Every time I even think about searching these lists, looking for something within my ability to tackle, I stumble right here. Why is Drupal concerned with bugs in the CVS project? :-)
Does this really mean trunk? (Not HEAD, either, since HEAD is a tag, not a branch.) If so, can it be changed? If not, then what does it mean?
Gary, "CVS" and "HEAD" versions generally refer to what other projects call "trunk", the very latest development version. But it seems you don't need to be told. What is your request? To clear up the terminology? Gabor
Gabor Hojtsy wrote:
On Wed, 6 Sep 2006, Gary Feldman wrote:
Augustin (Beginner) wrote:
(Queue #3) CVS critical bugs: Every time I even think about searching these lists, looking for something within my ability to tackle, I stumble right here. Why is Drupal concerned with bugs in the CVS project? :-)
Does this really mean trunk? (Not HEAD, either, since HEAD is a tag, not a branch.) If so, can it be changed? If not, then what does it mean?
Gary, "CVS" and "HEAD" versions generally refer to what other projects call "trunk", the very latest development version. But it seems you don't need to be told. What is your request? To clear up the terminology? Yes, that's precisely my request.
I used CVS for years before switching to Subversion, and have never before seen "CVS" used to refer to the main (trunk) branch. I have seen it used in the sense of "get the version from CVS instead of downloading a particular release tarball," which is only meaningful if no branching is being done. But as long as development is being done on multiple branches, they're all in CVS. It's a similar story for HEAD, except that Subversion usage adds some more twists. I suppose that if I did nothing else but Drupal, I'd get used to it and wouldn't mind the usage, but I do lots of other stuff. So every time I see this, I have to go back to the earlier listings in the note before I realize what I think is meant. I wasn't 100% positive - it could just as easily and reasonably be bugs detected in 4.6, 4.7, or the CVS trunk respectively, with the intent of only fixing in the trunk. Now if I trip over it, being experienced with CVS, what happens to people who want to get involved but have never used any source control system? I'll admit to being a bit of a curmudgeon around terminology and usability, and I'm assuming the actual work in changing the term is trivial. If it isn't, then that's a fair response, but if it is, then yes, I'd like to see a less ambiguous term used here. Gary
participants (15)
-
Angela Byron -
Augustin (Beginner) -
Boris Mann -
Bèr Kessels -
Derek Wright -
Dries Buytaert -
Fernando Silva -
Gabor Hojtsy -
Gary Feldman -
introfini -
Jeremy Epstein -
Johan Forngren -
Moshe Weitzman -
Rob Barreca -
sime