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

[Angela Byron]

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