i run into issues all the time that are crying for a status like this -- somebody asserts something is broken, but i can't reproduce the behavior.

would be great to have this as an available status for drupal.org issues.

CommentFileSizeAuthor
#127 issue_statuses.png8.1 KBPasqualle
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

RobRoy’s picture

I think active (needs more info) is good for that. Then those should get closed after a while, but maybe another status is in order.

kbahey’s picture

+1 from me. I am surprised it took us so long without having it.

Perhaps the wording should be "Cannot reproduce" for brevity.

Gerhard Killesreiter’s picture

-1

we have "active (needs more info)" and "won't fix".

hunmonk’s picture

we have "active (needs more info)" and "won't fix".

neither of which means that you're unable to reproduce the issue.

with your argument, we could get rid of 'by design' and just use "won't fix" for that, but obviously people thought that was a worthwhile distinction, as i think this suggestion is as well.

moshe weitzman@drupal.org’s picture

@hunmonk - what you say is true but look at it this way. 'unable to reproduce' (UTR) is doesn't communicate the maintainers intentions very well. compare to 'active - needs more info'. that means that you intend to pay attention on this should requester provide more detail. won't fix communicates intentions as well. UTR does not.

merlinofchaos’s picture

I disagree. It says that the maintainer is done with the issue, and why. That is very clear.

Won't fix is actually less information, as is active (needs more info), IMO, because there's no reason communicated at all. I often get stuck setting things to "won't fix" which annoys the crap out of me, because it's saying that it's broken and I don't care. Active (needs more info) says it's still active, which is often not the case if I can't reproduce something.

moshe weitzman’s picture

Now we are getting somewhere. I think our closed statuses should should communicate reason as well. So I propose

Closed - cannot reproduce
Closed - needs more info
Closed - by design
Closed - won't fix
Closed - duplicate

Note that this adds two new statuses: 'closed - cannot reproduce' and 'closed - needs more info' status. The others are renames of existing statuses.

I think postponed can stay the way it is.

kbahey’s picture

@moshe

So "Closed - needs more info" is IN ADDITION TO "Active - need more info"?

David Strauss’s picture

I think "won't fix" is a poor wording of intentions. It implies there's a problem, but we refuse to deal with it. "By design" is more accurate. In the Drupal spirit of abandoning backward compatibility to progress faster and have a cleaner design, we should never have a true "won't fix" issue.

moshe weitzman’s picture

yes. 'closed - needs more info' is a way to put an issue to rest when submitter has not responsed for a while. it comunicates that the issue will become active once more info is provided. i don't feel strongly about it. the man pont is renaming the close statuses with reasons.

kbahey’s picture

@moshe

I see, so it transitions from active NMI to Closed NMI. Makes sense, and is satisfactory to both parties (communicates intent of addressing it once info is made available).

I like the addition of "Closed -" suffix then. Clearer that way.

Michelle’s picture

re: #9

We need something along the lines of "won't fix" for feature requests. I agree that fix is the wrong word because there isn't necessarily something broken. Perhaps a "Closed - won't implement"? Otherwise what do you do with a feature request that you have no interest in fufilling?

Michelle

hunmonk’s picture

i like the direction this is heading. excellent suggestion, moshe :)

while "won't fix" could be interpreted as off-putting, it's also a short, accurate description of the resolution. note that Mantis also uses that same wording, so we're not alone.

chx’s picture

A NMI -> C NMI needs to be automatic after, dunno, two weeks? We have a state transition script already for F->C.

On another note, won't fix is often appropriate -- when clueless n00bs are asking for features against core that really should be in contrib or should not exist in the first place.

Gerhard Killesreiter’s picture

Status: Active » Closed (won't fix)

Yet another status idea.

moshe weitzman’s picture

Status: Closed (won't fix) » Needs review

We made good progress here, killes. Please be respectful of that and don't unilaterally make webmaster decisions.

Gerhard Killesreiter’s picture

Progress that stopped 1 year ago?

moshe weitzman’s picture

Yes - because drupal.org has no webmaster who makes these sorts of decisions. Thus good ideas get stuck at the final phase. This is a major deficiency with the Association.

killes@www.drop.org’s picture

Project: Drupal.org infrastructure » Drupal.org site moderators
Component: Other » Redesign

moving where it might generate interest.

alexanderpas’s picture

alexanderpas’s picture

let's look back...

I personally think we need the following statussus:
- active
- active (needs more info)
- active (reproducible) <== NEW
- patch (code needs review)
- patch (code needs work)
- patch (reviewed & tested by the community)
- patch (to be ported)
- fixed
- duplicate
- postponed
- won't fix (not a bug) <== previously won't fix
- won't fix (by design) <== previously by design
- closed (duplicate) <== NEW
- closed (needs more info) <== NEW
- closed (fixed) <== previously closed

and the following automatic state changes:
- active (needs more info) ==> closed (needs more info)
- duplicate ==> closed (duplicate)
- fixed ==> closed (fixed)

in my opinion, this communicates our intention better.

Also, i've taken the liberty to add the closed (duplicate) status, as there were previously some issues, where duplication was not agreed on.

Also, instead of active (unable to reproduce), i've added the active (reproducible) status as active (needs more info) seems good enough for unable to reproduce. (reproducable is similar to triaged for ubuntu)

Michelle’s picture

I like the statuses but I don't like the addition of the automated ones. Personally, I don't like the auto fixed -> closed but I can live with that. Active (NMI) to closed (NMI) I don't like because I prefer to make that decision myself. Duplicate to closed I don't like because I want people to see when an issue has already been duplicated several times hopefully to deter them.

Michelle

alexanderpas’s picture

automatic fixed -> closed is already here... nothing changed here... happens when there is no response on a fixed issue for two weeks.

Active (NMI) -> closed (NMI) only occurs under the same circumstances... no reponse for over two weeks...

duplicate -> closed (duplicate) is actually an addition, as it enables us to keep duplicate on to the default list, so you don't have the, "hey, where did my issue go?" moments, when you have a duplicate issue.
It gives duplicate issues more visibility! (thereby giving the original issue more visibility.)

The i think the new defaults list should be
show - active
show - active (needs more info)
show - active (reproducible)
show - patch (code needs review)
show - patch (code needs work)
show - patch (reviewed & tested by the community)
show - patch (to be ported)
show - fixed
show - duplicate <== changed to show
show - postponed
hide - won't fix (not a bug)
hide - won't fix (by design)
hide - closed (duplicate)
hide - closed (needs more info)
hide - closed (fixed)

everything else is unchanged or new.

Michelle’s picture

I realize the auto close is already there. I'm saying I don't like it but I'll live with it since it's already in use. I just don't like the idea of adding even more of the annoying things, especially the NMI closer. Just because something is waiting on more info does not mean it needs closing. You lost me on how closing duplicate issues gives them more visibility.

Michelle

alexanderpas’s picture

remember, that while it's closed, it still can be re-opened, if desired.
secondly, remember that those auto-changes only happen when there is not a single comment for two weeks!
also, remember that closed now get's the reason of closure with it.

but let's address the issues you're having with the auto-changes.

fixed => closed (fixed)
actually the only thing this does, is hiding it from the issue list, which is in my opinion, a blessing for those that have already 300 issues on their list. (like webchick, or dries, etc...)

active (needs more info) => closed (needs more info)
the reasoning behing this change, is that when no new information has been added for over two weeks, the issue isn't active anymore, but still can be re-activated when the information has been supplied.

duplicate => closed (duplicate)
currently, when an issue get's marked duplicate, it dissapears from the issue queue, however, with this change, it's still visible for two weeks, and get's hidden afterwards, serving as a pointer to the original issue, thereby giving the original issue more attention.

Michelle’s picture

Yes, I am familiar with how the issue queue works. As I said, I'm not going to argue against the existing auto closer; I just don't want to add more to it. I am, however, very much against auto closing NMI issues. Issues can be NMI for various reasons and it should be up to the maintainer to decide when they close. Closing an issue tends to drop it off the radar and that is not a good thing to happen automatically to an issue that needs more information. Duplicate issues only disappear on some views and not the default view from the project page anymore due to recent changes. I see this addition as an annoyance but it's at least not as destructive as the NMI one.

Michelle

Michelle’s picture

Status: Needs review » Active

Not sure why this is marked as a patch... There is no patch here that I can find.

Michelle

alexanderpas’s picture

Status: Active » Needs review

need another reviewer to shed its light on this issue.

alexanderpas’s picture

crosspost :D

but it's marked that way since it's the best status we have... it will get RTBC when all issues are cleared. (see possible solutions as a "patch".)

catch’s picture

Title: Add 'unable to reproduce' status for project issues » Re-organise issue statuses

re-titling and subscribing.

I'm very much in favour of of a 'reproducible' or 'confirmed' status, to indicate the opposite of 'needs more info' - to promote those issues which have good bug reports more prominently, haven't read through everything else yet.

Damien Tournoud’s picture

Title: Re-organise issue statuses » Add 'unable to reproduce' status for project issues

Here is a proposal that we may be able to agree upon:

Current status                                  Proposed new status
---------------------------------               ---------------------------------

active                                          new
active (needs more info)                        needs more info from submitter
                                                confirmed
patch (code needs review)                       patch (code needs review)
patch (code needs work)                         patch (code needs work)
patch (reviewed & tested by the community)      patch (reviewed & tested by the community)
patch (to be ported)                            patch (to be ported)
                                                patch (doesn't apply) // Could be magically set by the test bot.
fixed                                           fixed
                                                fixed (needs documentation)
duplicate                                       duplicate
postponed                                       postponed
won't fix                                       refused (won't fix)
by design                                       works as designed (won't fix)
closed                                          closed
catch’s picture

I agree 100% with Damien's proposal. Some of the ideas Alexander came up with are good, but the two extra statuses + one rename here could be added without any additional overhead.

stella’s picture

+1 for Damien's proposal in #31.

I disagree with the addition of more auto-close features proposed in earlier comments, especially with the auto-close for 'needs more info' states.

catch’s picture

Title: Add 'unable to reproduce' status for project issues » Reorganise project issue statuses
Michelle’s picture

+1 for #31 from me as well. I would love to have a "confirmed" state for bugs that I managed to reproduce but not fix, yet. Tiny nit. I think "works as designed" might be just a bit more clear than "by design".

Michelle

Damien Tournoud’s picture

I slightly updated the proposal in #31 with:
- renaming "won't fix (by design)" to "won't fix (works as designed)"
- adding a "patch (needs reroll)" state: this could be automatically set by the testing bot when the patch doesn't apply

catch, stella: do you agreement still stand?

stella’s picture

Those changes are fine by me, though maybe "reroll" should be "re-roll".

Damien Tournoud’s picture

@stella: ok for re-roll, changed in #31

catch’s picture

We discussed this a bit more in irc, and came up with patch (doesn't apply) instead - since some patches aren't just old, they're rolled incorrectly, or against the wrong Drupal version etc. I updated #31 with that change. Doesn't apply is a bit nicer than having your patch set to 'needs work' if it simply doesn't apply rather than breaking tests or whatever - and it's also nice to have a list of patches which need re-rolling.

apaderno’s picture

patch (needs re-roll), and patch (code needs work) are too similar; it's enough to change the status to patch (code needs work), and add a comment saying that the patch needs to be re-rolled.

I don't see the need to have two different statuses, in this case; code needs work is generic enough to make the author of the patch understand that he needs to work on the patch.

apaderno’s picture

I would rather add a status like active (needs feedback) which could be useful also in this report; the patch (code needs review) status is a little forced, as there isn't a patch in this report.

Damien Tournoud’s picture

patch (needs re-roll), and patch (code needs work) are too similar; it's enough to change the status to patch (code needs work), and add a comment saying that the patch needs to be re-rolled.

This is now "Patch (doesn't apply)". This will allow our testing bot to set the correct status for patches. Patch (code needs work) is just too broad.

I would rather add a status like active (needs feedback).

This is the already existing "Active (needs more info)".

catch’s picture

Active (needs feedback) is more like chx's idea for Active (needs architectural review) - i.e. a proposal that either doesn't involve any code, or which needs high level discussion before code is written. I think that could be a good idea, but it could also potentially be a tag instead.

apaderno’s picture

In that case, also active (needs more info), and all the statuses starting with patch should be tags.

catch’s picture

Project module does automatic filtering of default listings and search results using these statuses, that's currently not available with tags and this issue is only about configuration issues on Drupal.org rather than feature requests to project module. (needs more info) takes a patch out of rotation until it's updated back to active for example.

Also removing needs review/needs work/rtbc would have a massive disruption on many thousands of issues without a full upgrade path. I'm not opposed to adding 'needs architectural review', but it seems a bit less urgent than 'confirmed' and 'fixed - needs documentation' - which are quick improvements for current workflow issues in core and/or contrib.

merlinofchaos’s picture

If we're going to change these let's address the fact that users think active (needs more info) applies to the user. i.e, they need more info.

active (needs more info from submitter)

chx’s picture

I am content with #31. We could hand out doesn't apply issues to anyone who wants to help with core but has little knowledge -- rerolls are easy quick tasks.

sun’s picture

Instead of "active" and "active (confirmed)", I would prefer to just use "new" and "confirmed" for clarity. Since the user is able to assign the confirmed state for new issues either way, the "active" part in both states makes no sense (some other states mean that the issue is active as well).

catch’s picture

I've updated #31 again to reflect discussion so far.

apaderno’s picture

active is added because there is the need of a default status. new means something else, and when I read a report for a second time, it will not be new anymore; plus, new already appears in the issue queue with another meaning, and that could be confusing.

I think that new is not neutral enough.

sun’s picture

Sorry, just realized why I was really pointed to this issue.

In *large* issue queues, like Views, Panels, Image, and others, one often needs to mark support requests as "won't fix" to indicate that the request is either too specific or simply cannot be answered in the issue queue (users are pointed to usual support resources instead). I'm also using it when the user does not reply anymore. For such cases, one does not want to use "closed", because support requests that *have been* fixed are automatically marked as closed after 2 weeks. This means that users having a specific support question will look at all issues in the queue and try to find answers in all "fixed" or "closed" issues.

The two new won't fix states

won't fix (not a bug)
won't fix (works as designed)

do not really work for support requests. Either we make "not a bug" more generic, or we add a new "won't fix (too specific)" or "won't fix (out of scope)" - which both do not cover the case where we forever wait for further information from the submitter...

apaderno’s picture

Personally, when somebody submits a report for a bug but what is described is not a bug (or it's a bug of something else), I change the category to support request.
If there would be a won't fix (not a bug), I could change the report status to that; it would be the submitter who would change the category to support request if he really needs some kind of support.

stella’s picture

I'd be wary of adding too many issue states. I agree with sun that "won't fix (not a bug)" and "won't fix (works as designed)" don't cover instances where the user never responds, which is what I use "won't fix" for at the mo.

So I'd prefer if retained the old "won't fix" and "by design" states, and also the "active" one - as Kiam says "new" isn't broad enough.

+1 for "active (confirmed)"
+1 for "active (needs more info from submitter)" - I've also had users use "needs more info" incorrectly. Not sure about "submitter", maybe "poster" instead, as some times it's not the original issue creator that I need more details from.

catch’s picture

There's been a lot of comments since #31, so here's a new version since we don't have revisions for comments:

Current status                                  Proposed new status
---------------------------------               ---------------------------------

active                                          new
active (needs more info)                        needs more info from poster
                                                confirmed
patch (code needs review)                       patch (code needs review)
patch (code needs work)                         patch (code needs work)
patch (reviewed & tested by the community)      patch (reviewed & tested by the community)
patch (to be ported)                            patch (to be ported)
                                                patch (doesn't apply) // Could be magically set by the test bot.
fixed                                           fixed
                                                fixed (needs documentation)
duplicate                                       duplicate
postponed                                       postponed
won't fix                                       won't fix
by design                                       works as designed
closed                                          closed
stella’s picture

looks good to me!

Damien Tournoud’s picture

I like it as is.

sun’s picture

Status: Needs review » Reviewed & tested by the community

Very good.

babbage’s picture

Status: Reviewed & tested by the community » Needs review

-1 for "New" replacing "Active".

I agree with #51—"New" feels like a big backwards step from "Active"... case in point the recent thread #8: Let users cancel their accounts that has been committed after eight years of activity... it would have been ludicrous to have this tagged as "New" at any point in the last, oh, 7.5 years...

babbage’s picture

To elaborate on this further, changing "active" to "new" would assume that every issue would relatively quickly move from "new" to one of the other statuses, and that at every point after that one of the other statuses would be suitable. In the event that you have an active issue that does not meet one of the other points, there is nothing generic to go back to if "new" appears inappropriate. Does the maintainer set every issue to "needs more info from poster" each time they have responded? What does the poster then set the issue back to? (new?) If it is a back-and-forwards discussion, "Active" seems like a much more sensible description.

I also think "active (needs more info)" is better than "needs more info from poster". What if the outcome of an interchange between the maintainer and the original poster is that the issue now needs more info from other users? (Is that what "confirmed" means?)

I would prefer to see:
active
active (needs more info)
active (issue confirmed)

chx’s picture

Status: Needs review » Reviewed & tested by the community

Refusing new just because some issues might not be solved quickly is not really a good idea IMO. If we want to discuss connotations, then active is much worse as it indicates that there is an activity on the issue which is often not the case... indeed, even node/8 saw several months of inactivity from time to time.

babbage’s picture

In my opinion, there has not been a cogent argument given for why there would be a change to "new"... surely that should at least be required before deciding to make a change from what we already have?

If the problem is that issues may be marked as Active without actually having any activity, that would be better solved by having the following automatic stage changes after two weeks of inactivity (or any other X weeks we decide):

- active ==> inactive
- active (needs more info) ==> inactive (needs more info)
- active (issue confirmed) ==> inactive (issue confirmed)

I see now #25 proposes something similar in "closed (needs more info)". I guess it depends whether we feel adding a set of "inactive" classes is better than automatically closing issues. I think inactive provides a balance between maintainer choice as to when to close issues vs. being clear about the status.

babbage’s picture

This post collects together the various opinions on whether to change "active" to "new", which are otherwise rather scattered through the thread above:

The proposed table of changed statuses #31 introduces a change from "Active" to "New" though at that point there had been no prior discussion in the thread of this.

#48: Instead of "active" and "active (confirmed)", I would prefer to just use "new" and "confirmed" for clarity. Since the user is able to assign the confirmed state for new issues either way, the "active" part in both states makes no sense (some other states mean that the issue is active as well).

#50: active is added because there is the need of a default status. new means something else, and when I read a report for a second time, it will not be new anymore; plus, new already appears in the issue queue with another meaning, and that could be confusing.

I think that new is not neutral enough.

#53: So I'd prefer if retained the old "won't fix" and "by design" states, and also the "active" one - as Kiam says "new" isn't broad enough.

The revised table of proposed changes in #54 again includes "new" instead of "active".

Then there are my comments in #58 and #59 which I won't reproduce here because they are directly above, and it would be a bit gratuitous to do so. :)

#60: Refusing new just because some issues might not be solved quickly is not really a good idea IMO. If we want to discuss connotations, then active is much worse as it indicates that there is an activity on the issue which is often not the case... indeed, even node/8 saw several months of inactivity from time to time.

Then there is my final comment in #61, proposing that the issue of whether something is "active" could therefore be better resolved by adding an automatic change to "inactive" rather than changing "active" to "new".

In my view, the discussion is hardly clearly resolved, and the weight of opinion certainly doesn't seem to be squarely on the side of moving to new. Be good to have some further discussion and views.

catch’s picture

Bugs can either be confirmed quickly, or moved to active (needs more info) quickly - so the idea would be we have much less 'active' issues than we do currently. Having said that, I think it's the least important of these proposed changes, and something we could discuss separately once the rest are in.

merlinofchaos’s picture

I would still like to see the addition of "won't fix (not a bug)" and if we did that, then "won't fix (by design)" or just leaving it "by design". "works as designed" does not feel like a value add change to me.

webchick’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Bikeshed

Using catch's helpful table from http://drupal.org/node/171350#comment-1200762:

"new" should be "unconfirmed" since that's basically the opposite of "confirmed," and that's what you're trying to say here.

"needs more info from poster" is not clear, especially to non-native speakers: http://dictionary.reference.com/browse/poster. I'm not really sure what to suggest as an alternative. "Author" could be ambiguous with "module author" and "submitter" is very awkward.

IMO though we already have way too many issue statuses, thus leading to confusion, and adding more is only going to make the problems we're trying to solve here worse, because people will get too lazy to read the list and just pick whatever one they see first that looks kind of close.

webchick’s picture

A radical idea might be to have far *fewer* issue statuses and use our spanky new issue tags to summarize the finer points of what exactly those statuses mean.

Statuses:
unconfirmed
confirmed
patch (code needs review)
patch (code needs work)
patch (reviewed and tested by community)
fixed
duplicate
closed

Issue tags:
needs more info
works as designed
not a bug
patch fails to apply
...

Just a thought.

merlinofchaos’s picture

While I would generally be in favor of status/substatus, trying to pretend with status/tags strikes me as being unwieldy and would be far, far worse.

apaderno’s picture

#66 seems reasonable.
I like unconfirmed/confirmed better than new/confirmed.
The only thing that is negative for the tags is that they are not visible from the issue queue.

@#66: new is being refused because it's not the right word.

apaderno’s picture

If we are going to use the tags, then it would better to have also confirmed like tag, and use active like issue status.
Whenever a report is confirmed or not, the issue is still active until somebody fixes it, or until the maintainer changes the status to by design when the issue cannot be fixed because that is the normal behavior of the module (and not a bug), or the maintainer sets the status to won't fix.

Still, I have not seen anybody suggesting an alternative to patch (needs work) that is being used for this report when it doesn't have any meaning. If somebody would see this report in the issue queue, maybe he would not understand that the report needs feedback from people before somebody does anything; if there is somebody who is not able to make a patch, probably he will not even check out the report.

webchick’s picture

Well, in my mind we are talking about two different things here:

  1. The current "workflow state" during an issue's lifecycle.
  2. The reason why it's currently in that state.

The proposed issue statuses are trying to blend the two of them, it seems, which is going to eventually lead to us essentially doubling the number of choices (or possibly more than double). If we're trying to stem user confusion and make it easier for them to select a status that makes sense, we are working against ourselves here.

IMO, the issue's current workflow state is a very useful thing to communicate in the issue queue listing (active, needs review, needs work, fixed, closed, etc.) so you can see at a glance the "state of the queue." However, the particular reason why it's in that state (patch didn't apply, works as designed, rtfm, whatever) isn't really important until you decide you want to click into it and read more about it. And the nice thing about putting reasons as tags is that they're immediately in your face in the very first reply:

Only local images are allowed.

So, yep. That would be my vote. Eliminate all but the "lifecycle" statuses and use tags to communicate the finer details.

Michelle’s picture

How hard would it be to get a second, non freetagging vocab added for this? That would make the second set of choices a consistant set and seperate it from the rest of the tagging.

Michelle

webchick’s picture

Technically-speaking, it's very easy. comment_alter_taxonomy.module was designed to support any number of any kind of vocabulary.

Now, getting drupal.org webmasters to agree and getting the community to come to consensus on what those terms in it should be... ;D

catch’s picture

Even more discussion in irc got us to this:

Current status                                  Proposed new status
---------------------------------               ---------------------------------

active                                          active
active (needs more info)                        active (needs more info)
                                                confirmed
patch (code needs review)                       patch (code needs review)
patch (code needs work)                         patch (code needs work)
patch (reviewed & tested by the community)      patch (reviewed & tested by the community)
patch (to be ported)                            patch (to be ported)
                                                patch (doesn't apply) // Could be magically set by the test bot.
                                                committed (needs documentation)
fixed                                           fixed
duplicate                                       duplicate
postponed                                       postponed
won't fix                                       won't fix
by design                                       works as designed
closed                                          closed
catch’s picture

Quick summary of why I (and tha_sun, Damz, stella, chx, merlinofchaos and some other people in #drupal) want the new status, as opposed to tags:

confirmed makes it obvious whether someone else has already looked at the patch and reproduced/verified the issue when glancing over an issue queue - like any other status it could be set incorrectly, but we don't get all that many issues posted as fixed or RTBC straight off now. Also, once these new statuses settle down, people wanting to do some farming and piracy can get a lot of mileage out of just confirming whether bugs are valid or not - whereas minefields like node/8 would already be 'confirmed'.

committed (needs documentation), means that when you're working on a big core patch which will need handbook documentation once committed, your blood pressure doesn't go up seeing it marked as 'needs work' any more times than necessary. It also gives us a rock solid list of release blockers, which won't be mixed in with active patches which also 'need documentation'.

patch (doesn't apply) will be really handy to know that something has just failed the testbot quickly due to commits to HEAD rather than having been subject to an in depth review and marked as needs work. It's also a great place to point people who want to start contributing to core but don't know where to start - since re-rolling patches is easy, fun and rewarding. Additionally, new users are sometimes put off by having their patches marked to 'needs work' simply because it had windows line endings, or wasn't rolled from root, or a commit happened after they posted it, this is a bit nicer.

webchick’s picture

Status: Needs work » Reviewed & tested by the community

Cool with me.

Promoting so killes can take a look.

Anonymous’s picture

If i may make an observation from a users point of view, relating to "Active" . My coments may be slightly tangental, but hopefully it helps explain my thoughts

"Active" can cover many stages of an Issue, but there is only one "Initial Report". And until it is responded to, its could be considered not really active, other than by the originator.

When you look at the queues you will find hundreds of issues that never get past the Initial Report stage. But there is no way of knowing which have been looked at, as they are all active.

For a user when they search an Issue queue there is no indication as to how many posts have been made against an issue, hence people spend a lot of time opening and closing looking at Issues with titles similar to what they are thinking, trying to find ones with possible answers/clues, before resorting to opening their own issue. Ideally the user would prefer to look at an Issue with comment before those without, and this may help that situation. Part of the solution may be to add the number of posts to the list, but having the status as "Initial Report" would also allow

A. People with a spare 5 minutes wanting to do a good deed for the day to maybe move an issue forward
B. A maintainer to filter to see which issues have never been acted upon

killes@www.drop.org’s picture

I am ok with this, but I'd like to hear Dries' opinion.

babbage’s picture

One further observation—though I don't think it need slow down the proposed change—is that most of the statuses are focussed on bugs, with only a few being appropriate in other categories such as support requests (active, active-needs more info, duplicate, fixed and closed).

If at some point we move to another generic status rather than "active" we need to make sure it makes sense for tasks, feature requests and support requests (none of which need to be "confirmed") as well as for bug reports.

(ETA: OK, though feature requests may well go through patches etc.)

sun’s picture

The "confirmed" status equally applies nicely for tasks, feature requests and support requests.

Tasks can be confirmed by other developers, meaning "yes, this task makes absolutely sense."

Feature requests can be confirmed by other users, meaning "I'd like to see this feature as well."

Support requests can be confirmed by other users, meaning "Yes, I'm struggling with this, too."

babbage’s picture

Hmm, I guess it may be used in that way—though I struggle to see it being of particular value in terms of support requests for instance—the user confirmed they were having a support request by posting it in the first place, so it doesn't add much.

Note I'm not at all arguing against adding "confirmed"—I think it should definitely be there, for bugs regardless of any other uses.

Anonymous’s picture

I know there is a status of "Postponed", but is this a Status really suitable to feature requests where it is "Under Consideration" ie , the request has been taken on board, and will be considered in conjunction with other plans. Its not rejected, its not postponed sort of Active(Under Consideration)

Something that sort of inter-relates is the Category for the user there is a fine line between "Bug Reports" and Support Reports" depending on personality some will err on support, though genuinely thinking there is a bug, but wary it may be finger trouble. Whilst other will use bug report to push what is really a support request. Its almost as though there needs a compromise "Support/Bug Report" - though would that also get abused. I mention it as it may affect the appropriateness of the choices for Status

And as a side note, which probaby will need a request elsewhere The basic layout of issues search is Project, Status, Category, Priority. Would it be more logical to have Project Category Status Priority

Once all this is decided it would be nice to see a Documentation page showing valid combinations of Category to Status,

catch’s picture

midkemia, support requests, bug reports, feature requests and tasks all get switched between each other quite regularly - i.e. a support request turning into a documentation task.

apaderno’s picture

I would opt for won't fix (not a bug), and won't fix (works like designed).
I like better a status that explains why it will not fix; saying simply that it will not fix seems that the maintainer doesn't want to make a change for the code that is causing an issue to somebody else.

David Strauss’s picture

@Kiam The string "works like designed" does not sound like native English to me. I prefer "works as designed" as an alternative.

Pasqualle’s picture

Oh, I missed this issue :)

"Postponed" can't be changed to "Under Consideration", because this state is mostly used for issues which are approved but there are more important issues in the queue, or the issue depends on other issues which must be solved first. The "active" (or "new") is a perfect status for issues under consideration.

"Won't fix" can't be changed to "won't fix (not a bug)", as it is already used for tasks, support requests and feature request also.

Off topic: I prefer closing support issues when the user does not reply within a month. (I am the auto-close script) And I leave a comment that the issue can be reopened.. I think support issues should not be set to won't fix, because it feels like that the developer does not want to help.

apaderno’s picture

@David Strauss: works like designed is not acceptable in formal English.
The New Oxford American Dictionary reports that the use of like as a conjunction meaning 'as' or 'as if' is considered by many to be incorrect (it doesn't say it's incorrect), and then in more precise use, like is a preposition, used before nouns and pronouns.

But it also reports that info is an informal word for information. If that is the point, also active (needs more info) should be corrected.

My point was to have two statuses instead of the current won't fix.
The description used for the status is not so important to me; I would rather use a description that starts with won't fix, but that is not mandatory.

merlinofchaos’s picture

From a purely "English as a first language" perspective, "Works like designed" simply doesn't sound right.

webchick’s picture

active (needs more info) -> active (needs more details)
by design -> won't fix (works as designed)

Everyone happy now? ;)

Michelle’s picture

#88 +1 :)

Michelle

apaderno’s picture

+1 for #88.

JohnFilipstad’s picture

marked #358684: Add a "Fixed (needs documentation)" status as duplicate as that issue is being addressed here already.

Damien Tournoud’s picture

Issue tags: -Bikeshed

So here is the accepted proposal:

Current status                                  Proposed new status
---------------------------------               ---------------------------------

active                                          active
active (needs more info)                        active (needs more details)
                                                confirmed
patch (code needs review)                       patch (code needs review)
patch (code needs work)                         patch (code needs work)
patch (reviewed & tested by the community)      patch (reviewed & tested by the community)
patch (to be ported)                            patch (to be ported)
                                                patch (doesn't apply) // Could be magically set by the test bot.
                                                committed (needs documentation)
fixed                                           fixed
duplicate                                       duplicate
postponed                                       postponed
won't fix                                       won't fix
by design                                       won't fix (works as designed)
closed                                          closed

Now we could stop bikesheding, and go back to work, couldn't we?

Michelle’s picture

#92 Looks good to me.

Michelle

fgm’s picture

Problem looming ahead: two "won't fix" statuses, only one of which has an explanation. Although Pasqualle's comment #comment-1207587 explains why, it makes for a logical inconsistency which will in all likelihood cause more problems in the future, since no one who didn't follow this thread will be able to understand when to use either of these.

This could be alleviated by adding the complementary description where it is missing. Maybe like "incorrect issue" ?

apaderno’s picture

incorrect issue seems too generic to me.
Still, I agree that if we are going to use won't fix (works as designed) then we cannot simply use won't fix; if that is the case, then won't fix (incorrect issue) like suggested by fgm is much better.

Anonymous’s picture

If part of the issue is to allow for the legacy "wont fix" as it is unknown if the term relates to "wont fix (works as designed)" or some other meaning of the maintainer, then "wont fix (obsolete term)" or something similar may help

Pasqualle’s picture

"wont fix (obsolete term)" is absolutely wrong, as I do not support making any status obsolete. (Making a status obsolete is more work than a simple rename of the status. You need to remove it from the status field when you create or edit an issue, but you need to show it in the issue filter. You have to specify on which places it must be hidden and on which places to be shown. That simply is not acceptable for this issue now..)

Problem looming ahead: two "won't fix" statuses, only one of which has an explanation.

I don't understand what is the problem with that. I can clearly distinguish between them.. We have two active statuses also where only one has an explanation..

webchick’s picture

Issue tags: +Bikeshed

Bah! I knew that was too easy! ;)

Michelle’s picture

If people want to know why it was won't fixed, they can read the issue. Assuming people actually provide explanations and don't just run thru setting all their issues to won't fix. I can see the "works as designed" but the rest can just be "won't fix" with an implied "won't fix (read the issue if you want to know why)".

Michelle

babbage’s picture

I agree with #97 and #99. There is no problem with having two won't fix status options, one of which is more specific than another. If you only have tightly specified options, you leave out anything that hasn't been anticipated.

I don't see though why we actually need the "won't fix" in won't fix (works as designed) actually—the previous by design was a little ambiguous, but why not just make it works as designed? The won't fix doesn't actually even make sense entirely, given you are actually saying ain't broke.

catch’s picture

Just a straight 'works as designed' suits me - here's the updated chart.

Stick!

Current status                                  Proposed new status
---------------------------------               ---------------------------------

active                                          active
active (needs more info)                        active (needs more details)
                                                confirmed
patch (code needs review)                       patch (code needs review)
patch (code needs work)                         patch (code needs work)
patch (reviewed & tested by the community)      patch (reviewed & tested by the community)
patch (to be ported)                            patch (to be ported)
                                                patch (doesn't apply) // Could be magically set by the test bot.
                                                committed (needs documentation)
fixed                                           fixed
duplicate                                       duplicate
postponed                                       postponed
won't fix                                       won't fix
by design                                       works as designed
closed                                          closed
apaderno’s picture

+1 for #101.

webchick’s picture

Issue tags: -Bikeshed

Tentatively removing Bikeshed tag again. ;)

Anonymous’s picture

I know its a bit late now, and i am only a user, but something has been nagging me about "works as designed" it just doesn't sound right, "works as intended" sounds better,

Though in reality, I personally prefer the original term of "by design" , which has been used in Manufacturing and Engineering for at least 30 years that I know of, so well established globally for that exact meaning.

apaderno’s picture

Status: Postponed » Reviewed & tested by the community

The problem is that by design has been misused many times, when a report status has been set to by design to simply stop any further commenting on the report. works as designed is clearer, IMHO, also because not all people work in manufacturing and engineering, nor all people live in English-speaking countries.

dww’s picture

Status: Reviewed & tested by the community » Postponed

I'd like to have a chance to skim through this discussion before anyone actually implements any changes on d.o. I'm going to be busy with the d.o redesign all next week, but perhaps I'll read this while I'm on the plane or something. ;) My initial reaction from looking at #101 is that we've already got too many status values, and it's already confusing, and I'm not convinced adding more choices with slightly different wording is going to make it any easier. But, I haven't read all the justifications, so please don't jump all over this comment and re-hash anything. Also, please don't "commit" this until I've had a chance to reply for real (which, if not in the next few days, will be sometime the first week of Feb). Thanks.

alexanderpas’s picture

Status: Reviewed & tested by the community » Postponed

how about dropping the active part from active (needs more details) leaving just needs more details

+1 for "works as intended" instead of "by design"

"committed (needs documentation)" why not simply "needs documentation"

-1 for "patch (doesn't apply)" we already have "patch (code needs work)", this information can also be conveyed in the message from the testbot
"the last patch failed testing."
"the last patch failed to apply."
(but that's another issue)

Anonymous’s picture

I didn't see any mention of a radical idea of adding another field for ``(code needs review)''. So I see something like the following:

  STATUS
  active
  closed
  patch
  postponed
  project defined
  GROUP
  needs more info
  code needs review
  code needs work
  reviewed and tested by community
  to be ported
  fixed
  works as intended
  will not consider
  pending another issue

The ``works as intended'' is a replacement for ``by design'' and the ``will not consider'' is a replacement for ``won't fix''.

As you can see adding a new field is more visually appealing than trying to add lengthy status fields that has the group data inline. However, we might also want to tie the GROUP information to the STATUS information so such that active->fixed isn't possible. And the ``project defined'' status would be for allowing the project owner to add a GROUP of his own.

David Strauss’s picture

@earnie We'd have to build a system to ensure coherency between status and group.

hass’s picture

+1 for #101.

sun’s picture

christefano’s picture

#101 is nice but it doesn't distinguish whether it's the submitter or the maintainer who needs more details. It would be significant step forward, I think, if "active (needs more info)" was changed to "active (maintainers need more info)".

dww’s picture

Status: Postponed » Needs review

@sun #111: Not really. Just because people subscribe to an issue doesn't mean we know it's a real bug or not. However, I think we don't need a "confirmed" status for other reasons... see below. ;)

@#101: I still fundamentally believe we need less status values, not more.

I especially don't like "patch (doesn't apply)" There are so many shades of grey for "needs work", why is this one promoted to a whole new first-class status? We should use "needs work" as the status of the issue, and use tags to specify what needs work about it. Vastly more flexible that way, and doesn't add yet more confusion for end users trying to report a bug in the first place, faced with an overwhelming list of options. We can obviously teach the the test bot how to specify an issue tag when it marks something as needs work (in fact, it already knows the difference between "fails to apply", "PHP syntax error", and "tests fail" -- all of which would be useful to see as a tag).

"committed (needs documentation)" is another one. Just use "needs work" as the status and "needs documentation" as the tag. A tiny % of users "getting high blood pressure from seeing their issue back in needs work after finally getting a mammoth patch in core" is not a sufficient justification for adding more options for the 99.999% of other users. ;)

And, now that we've got issue tags, I think "patch (to be ported)" should die. That's just another shade of "needs work" -- let's use a tag for that, too.

I still like aspects of #7 from moshe. The "closed" status values should explicitly say they're closed. Why is this different from "needs work" you ask? First of all, because there are a finite set of reasons an issue is closed: fixed, duplicate, won't fix, by design. However, "needs work" could be a nearly infinite number of reasons ("needs code style", "needs benchmarks", "needs documentation", "doesn't apply", "needs a clue", etc). Secondly, the "why is this dead?" data has important meaning for everyone participating in the issue. The shades of grey about what "needs work" are only relevant to people planning to do more work. Finally, it's useful for historical reasons to see the final status of issues for data mining ("wow, we've got a lot of duplicate issues, we should work on tools to avoid that", or "wow, I get a lot of issues I have to mark 'works as designed', maybe my UI and/or documentation suck", etc). I think keeping the status values distinct is important for the different kinds of closed...

Side note: I think for both postponed and duplicate, someday it'd be cool to have a nodereference field that points to the other issue(s) involved, and we could potentially do slick things with automatic state changes in that case -- I think that'd be easier with separate status values instead of tags. See #44162: Relationships between issues: support for parent issue and related issues for more.

That said, I'll admit the distinction between the "needs work" reason and the "closed" reason is a little hazy, so if there was a strong outcry for collapsing all the closed states into one and using tags to specify the closed reason, I might cave in on that argument. We don't necessarily have to decide this part right now.

I still don't think "active (needs more details)" is the right approach for that. The idea of that status is a good one, but it's hard to word it in a way that's concise and yet communicates the intentions for everyone effectively. It should really be more like: "Postponed: needs more information from the submitter". Maybe just "Postponed: Needs more information" would help discourage end users from submitting their issues in that status, and it does communicate the intentions of the maintainer more effectively: "I'm not looking at this again until you answer my questions". p.s. just saw #112 -- sure, we can stick "maintainers" in there, that'd help even more.

I'm not in favor of "confirmed" as a separate status. First of all, I fear end users will just submit things as "confirmed" all the time if we do it this way. Secondly, a bug can be both "confirmed" and "postponed", for example. "Confirmed" isn't really a state an issue passes through, it's an attribute of an issue that can be true (or not) in any state its in. Plus, my general resistance to adding more status names applies. I'm not sold it buys us real value in our workflow, we could use a tag for this in cases where we want it, and I think it'll just add confusion, not help better communicate our intentions.

I don't personally care much about the whole "patch" and "code" terminology on d.o for queues where that makes no sense. I think most people get it that you can abuse "patch (code needs review)" for an infrastructure proposal that doesn't actually have a patch. However, I don't think we lose anything by moving to just "needs review", "needs work" and "reviewed and tested...". Using "patch" in the status name doesn't really tell us anything special.

So, here's my current proposal:

Current status                                  Proposed new status
---------------------------------               ---------------------------------
active                                          active
active (needs more info)                        postponed (maintainers need more info)
patch (code needs review)                       needs review
patch (code needs work)                         needs work
patch (reviewed & tested by the community)      reviewed & tested by the community
patch (to be ported)                            -- none -- {use "needs work" + "to be ported" tag}
fixed                                           fixed
duplicate                                       closed (duplicate)
postponed                                       postponed
won't fix                                       closed (won't fix)
by design                                       closed (works as designed)
closed                                          closed (fixed)

I'm aware that my proposal requires making more heavy use of issue tags for some power users. That's why I think #389096: Instead of duplicating (incomplete) views, just add an "Issue tags" filter to advanced search needs to happen ASAP to make tags more useful in the issue queue UI. That's just blocked on someone writing some linkrot preventing menu items to redirect to the new URLs, since the existing views were hastily deployed without the blessings of the project* maintainers, but now lots of people are using those URLs.

sun’s picture

dww at least completely convinced me with this proposal. +1 especially for "postponed" for "needs more info"; removal of "patch"; complete removal of "to be ported".

Not really sure whether stuffing "closed" in front of all those statuses helps anyone. If we remove "patch", I'd also remove the "closed" prefix (except for "closed" itself).

dww’s picture

To clarify: we ditch "patch" because it's not always true. We add "closed" because it's what we actually mean, but that's not necessarily clear right now.

Michelle’s picture

+1 from me to dww's suggestion, especially changing the "needs more info". My workflow is typically to answer the question and mark it fixed if I can or ask for more information and mark it so. But then people don't change the status when they provide more info and it sits on that setting. I think they'd be more likely to set it active if they see it's marked postponed.

Michelle

webchick’s picture

I'm fine with damn near anything as long as this issue finally gets marked 'fixed' and people quit getting their attention sucked by it. ;)

But with that said, Derek's suggestions make sense to me. Go for it.

catch’s picture

Derek's suggestions + issue tag filtering works great for me.

Anonymous’s picture

I think they'd be more likely to set it active if they see it's marked postponed.

Michelle, you must be joking. :o People who don't change the status now, will not change the status regardless of what it says. If an automated step that changes the setting back to active when the OP comments it would be a great thing. I would suggest PENDING as the status for this automated step. If the OP doesn't comment in X time then the status becomes closed automatically.

Damien Tournoud’s picture

I'm fine with whatever, as long as we have proper issue filtering.

Plus, there is a strong feature request to be able to refer to tags by name in the URL, like http://drupal.org/project/issues/tag/drupal-org-redesign

Michelle’s picture

@earnie: No, I'm not joking. Issues I mark fixed/closed get set back to active far more than ones marked NMI. Seeing your issue marked as "postponed" is a lot more incentive than a variation of "active".

Michelle

merlinofchaos’s picture

Michelle is absolutely right. People are very very quick to transition from fixed or won't fix or by design back to active if they believe that the module maintainer is wrong or misunderstood the problem.

dww’s picture

Assigned: Unassigned » dww

Hearing no major objections, I'm going to implement this in the following phases:

A) Immediately:
s/active (needs more info)/postponed (maintainers need more info)/
s/patch (codes needs work)/needs work/
s/patch (codes needs review)/needs review/
s/patch (reviewed & tested by the community)/reviewed & tested by the community/
(I still think that last one is a wonky name, and maybe we should just return to "ready to be committed", but that's a question for a different bikeshed^H^H^H^H^H^H^H^H issue).
These are trivial, and uncontested at this point, so I'll just do it.

B) Once the dust settles a bit:
s/duplicate/closed (duplicate)/
s/won't fix/closed (won't fix)/
s/by design/closed (works as designed)/
s/closed/closed (fixed)/
Also trivial, but I'm willing to let this sink in a bit more before I pull the trigger... Doesn't fundamentally change anything, IMHO a nice change in communicating intentions, but not urgent.

C) Soon:
Ugh, I forgot about "closed (cannot reproduce)" which was the original point of this dreaded issue. ;) I think that's more useful and communicates intentions more clearly than "confirmed", and given everything I said in #113, I think this is another reasonable resting place for issues, and we should add it.

D) Later:
s/patch (to be ported)/needs work + "to be ported" tag/
This isn't critical, and I need to write an upgrade path for it...

Any other feature requests like having the status default back to "active" whenever someone replies to a "postponed (maintainer needs more info)" issue, or the stuff about filtering/displaying issue tags belong in other issues.

In the end, we'll have the exact same number of possible status values. Alas. But, at least they'll be more self documenting, and we all understand the distinction between status values and issue tags better. Phew.

hunmonk’s picture

Status: Needs review » Reviewed & tested by the community

i'm on board with all of these changes -- minimally it's a definite step in the right direction, and we can tweak further later if necessary.

Dave Reid’s picture

Is someone changing the issues statuses now? We've lost "code needs review" and "code needs work"

dww’s picture

Dave Reid: we didn't lose anything. Read comment #123.

Pasqualle’s picture

FileSize
8.1 KB

The new statuses are not visible in the dropdown.

stella’s picture

I can confirm that 'needs work' and 'needs review' don't exist in the status list, in any form.

I see just:
active
'reviewed & tested by the community'
patch (to be ported)
fixed
duplicate
postponed
won't fix
by design
closed

dww’s picture

oh, tee hee. stupid project issue status permissions. :( now fixed. sorry about that.

wretched sinner - saved by grace’s picture

As a comment, should the CSS of the postponed (maintainer needs info) be the same as the standard postponed option?

dww’s picture

Turns out merlinofchaos and quicksketch object to removing "patch" from those 3 issue status values, after all. :(

#430504: the 'needs review' status is confusing and people regularly misclassify issues

I might change those back in a day or so. I'll probably make the changes I outlined in #123 B and C at the same time (assuming there are no objections to any of that). ;)

webchick’s picture

The one nice thing about needs work / needs review without "patch" in the name is for the docs queue, where the word "patch" makes absolutely no sense in 99.999% of the cases.

But I suppose we could do some kind of fancy hook_form_alter() magic for that one queue (which we might want to do anyway to like remove the "version" field and such).

dww’s picture

@webchick: The doc queue no longer has a version field. See #452382: Move documentation releases to a new drupaldocs project. Furthermore, it's not so easy as hook_form_alter() magic -- we'd also have to change the views somehow. That'd be even worse when viewing issues across multiple projects. Ugh. I think we just have to compromise. There are only 3 possible options:

1) we include "patch" to keep merlinofchaos and others happy by avoiding newbies marking their brand new bug reports as "needs review", and we have to live with the fact that something like 3 of our issue queues (docs, infra, and webmaster) have to abuse "patch (needs review)" when there normally aren't any patches.

2) we leave things generic, and continue to piss off people like merlinofchaos.

3) we have both (UGH!). this wouldn't be so bad if I ever got around to implementing my concept on letting the site admin define the global status settings, but letting each project select the subset of those that are considered valid for any given project (sort of like how project owners can specify their own components). We can't just let each project define their own status values because it gets really messy, but restricting to a subset of the global status values would work. I just briefly searched, and didn't find an issue about this, which is rather shocking. ;) I'll look again when it's not 2am, and if I really never wrote this up as an issue, I'll submit one and link it here. But, that's not going to be a trivial fix, so I think this option is off the table at this point... We just have to decide which of (1) or (2) is the lesser evil. :(

webchick’s picture

Hrm. Could maybe be done in the theme with a pretty nasty hack. But yeah, I see what you mean.

I don't think you have any choice other than to do #1. It's just too bad because that was actually a 'feature' as far as the docs team was concerned. But it'd be neat if we could think of other ways we could help keep the docs team's barrier of entry as low as possible while we're making things more convenient for developers.

I don't have any objections to various "Closed" statuses.

apaderno’s picture

People will keep selecting the wrong issue status whichever issue statuses they can choose from. There is nothing that stops the users from selecting a not correct status, and there will always be somebody who doesn't understand the meaning of a status (especially because users on Drupal.org come from all around the world).

I find needs review more useful of patch (needs review), especially when there is no patch. Then, making a issue status more generic is not in any way related to the wrong use of the issue statuses some people do.

It could useful to have something that filter the statuses a user can select. Most of the times, a user that is not the maintainer of a project should not be allowed to set a report as duplicate of another one; it would be better if the decision of marking an issue as duplicate would be left to the maintainer (or co-maintainers) of the project. Also won't fix should not be used from who is not the (co-)maintainer of a project.

Michelle’s picture

@Kiam: Restricting who can set would complicate matters if you go help out in someone else's queue. Marking duplicates is actually something you can do to help out and make it easier for the maintainer to focus on the issue. I don't think limiting "won't fix" is too much of an issue, but I'd rather see it not being able to be changed from that. Most people don't set their own issues "won't fix" :)

Michelle

apaderno’s picture

Status: Needs review » Reviewed & tested by the community

If i remember well, the Project issues project has settings for the statuses that can be set, and that can be set from who opened the issue report.

What I was suggesting is based on the experience I had. Once I was not seeing an issue report because I was looking in the issue queue, and somebody else set the issue to won't fix; I then set it to active until I resolved the issue. I was almost missing a issue report because somebody else set the status to won't fix.

merlinofchaos’s picture

kiam: "People will always make mistakes" is a poor argument against clarity. You could slippery slope that one down to a pit pretty quickly. Yes, people will always make mistakes. However, we *can* and *should* do what we can to minimize those mistakes where it is feasible. A lack of clarity is exactly the reason this issue started, and I support its intent.

I'd be willing to explore alternates to the word patch that would work for both patches and new/changed documentation that isn't strictly a patch?

webchick’s picture

"solution needs review"
"solution needs work"

?

webchick’s picture

Actually, here's what we should do. ;)

Contact a few of the users who mis-used this status and ask THEM directly to chime in here on what would've helped them pick the right choice.

Michelle’s picture

To me, it's easier for maintainers and other folks on the helping end rather than the asking for help end to get their head around the fact that "patch" means anything from an actual .patch to a snippit to fix something to better worded docs than it is for a random newbie to understand that "needs review" means there has to be a solution that needs reviewing. So I'd vote for putting it back to patch, unless another word is found. Maybe "Potential solution (needs review)"?

Edit: Aww, here I thought I came up with something and I see webchick beat me to it while I was writing. LOL

Michelle

apaderno’s picture

we *can* and *should* do what we can to minimize those mistakes where it is feasible

Will changing the issue from needs review to patch (needs review) stop the users from not using it when it's not needed? No, it will not. That is because in the past the patch (needs review) has been already used to simply mean needs review, and people started to use it even when there were not any patched attached to review.

If I remember well, that is started on issue queues related to Drupal.org; people got used to see patch (needs review) used when it would mean needs review, and now we are supposing it will be used correctly.

Pasqualle’s picture

"solution needs review"
I many times accept solutions without patches in my queues.. And I many times explain patch as "solution to the problem" when I am talking with people who never heard a term "patch"..

but then probably will need an additional status later, something like: "ok the solution is good, but someone have to create a patch now as there isn't any" or just use a tag something like "solution without a patch"

apaderno’s picture

"solution needs review"
"solution needs work"

It seems good, for me; as far as the word patch is not included in the status name all is good for me.

dww’s picture

Status: Reviewed & tested by the community » Needs review

s/patch/solution/ sounds really good to me. Hopefully that'll communicate the intentions clearly for everyone involved, and still be useful in cases there aren't actual patches. I'm OK with giving this a try and seeing how it goes, since I have high hopes it will work. ;) That said, this proposed solution still "needs review". ;)

p.s. Last chance to complain about #123 B + C. Speak now or forever think those are a good move, too. ;)

merlinofchaos’s picture

Will changing the issue from needs review to patch (needs review) stop the users from not using it when it's not needed? No, it will not.

This flies in the face of evidence. That is, the evidence that in two major issue queues, the number of misuses of 'needs review' went way, way up when the word 'patch' was removed from it. Sure, some people still misused it before, but at least an order of magnitude fewer.

I'm a little uncomfortable with just 'solution needs review', has solution (needs review) might work a touch better, as I can see people thinking "solution needs review" means "needs a review for a solution". I'm not set on this one, as it's just a guess on how people I don't know will interpret it.

Anonymous’s picture

solution is more general than patch and fits better with managing issues without patches.

Re #146: The extra parenthesis in the wording is needless. Your inference of what you "see people thinking" is, IMO, not real.

dww’s picture

@Pasqualle, re #143:

"ok the solution is good, but someone have to create a patch now as there isn't any" == "solution needs work" status + "needs patch" tag. It's just another flavor of needs work, like needs documentation, needs benchmarks, etc. In fact, there's already a needs code tag, but I think "needs patch" would be more clear to standardize around.

@merlinofchaos, re: #146:

I'm fine with "solution (needs review)" etc. That's consistent with our other status values where the primary status is followed by a qualifier in parens.

We could also do "has solution (needs review)" to be even more explicit, but that's getting pretty darn wordy + long (although it's only 2 chars longer than the original "patch (code needs review)", so maybe it's fine).

apaderno’s picture

I can see people thinking "solution needs review" means "needs a review for a solution"

If we are going to think what people incorrectly think, then any proposal should not be accepted because for any proposed status there would be people who interpret it in their way.

I don't see, anyway, how solution needs review could be interpreted as needs a review for a solution; there could be people who don't speak English as first language who would give a wrong interpretation, but if they don't know well English grammar, or all the English words used on Drupal.org that is a users problem.

Just to make an example, there are people who could not understand what project ownership means for Drupal.org. Are we going to change that as well, then?

dww’s picture

Status: Reviewed & tested by the community » Needs review

@all: remember, this is all wild speculation based on anecdotes and personal feelings + interpretations. There's no one right answer here. This is a classic bikeshed moment. Everyone has strong opinions, but no one actually has any solid data (and gathering that data is not worth the effort).

I'm still with merlinofchaos: "However, we *can* and *should* do what we can to minimize those mistakes where it is feasible". If we can come up with something that we think is going to be more self-documenting and pretty hard to misinterpret, without being insanely unwieldy, we should use that over something that we think is more likely to be misunderstood. There's no exact science here, but we can do the best we can by trying to put ourselves in many different shoes, based on our (in many cases, substantial) experience of dealing with the users in our issue queues.

sun’s picture

"has solution (needs review)" is more in line with other statuses. Why? Because it's not a noun.

That said, I could as well understand that as: "solved (needs review)" - I wonder whether that is right.

In all "(has )?sol(ution|ved)" cases however, "solved (needs work)" makes little sense to me - though it could work, because it's in line with "solved (needs review)", and in both cases, "solved" means that there is 'something', a patch or proposed solution.

But then again, a proposed solution is what "active" is for.

Meh. I tend to prefer 3) in #133, i.e. add more statuses and allow to disable some for projects.

dww’s picture

Just for clarity, here are the three actively considered proposals for what used to be "patch (code needs review)" and what's now just "needs review":

A) solution needs review

B) solution (needs review)

C) has solution (needs review)

Obviously, "needs work" and "reviewed & tested by the community" will get the same treatment. If you have another suggestion, please use the next available letter with your proposal, but hopefully we can converge on one of these three in the near future. We all have better things to do than spend hours on this.

dww’s picture

Ugh, cross-post with sun. But, I don't think "solved" is viable for any of this, so I'm ok leaving those out of the currently identified proposals. ;) #3 in comment #133 is completely off the table for now. It's an idea I've had for a long time, but it's not going to be implemented anytime in the near future, and we need to do something here. Plus, it's going to have its own UX problems, so I think it's worth it for us to come up with really clear, self-documenting status options that work across all projects if at all possible.

sun’s picture

"needs work" getting the same treatment, I agree with. But -1 for changing "reviewed & tested by the community" - I have not seen any abuse or misuse of that status since we changed it, so I don't see a need to rename it (also, it's quite lengthy already).

apaderno’s picture

I agree with #154; reviewed & tested by the community is fine as it is now, and I don't see any reason to change it.

Anonymous’s picture

I am not a module maintainer but a user, but i see an issue that has been in process for almost 2 years

With no disrespect intend to any of you as you all provide a lot of time effort and skill, I have to say you can go on debating this for years with no progress. And the rest of the community will go its merry way.

The way I see it is Module maintainers, and the like will probably interpret most of the terms in a similar way, though still with a few differences. Users see the otherside of the coin, and sometimes struggle with the conepts, whether its down to imperfect language, or other reason, it exists.

Might i suggest that as there are many good ideas here, that you ask the people?

Possibly the best way would be using something like the quiz module, Giving the various Terms and asking the users to select an answer as to what it means? From this you should get an idea of what is more effective from a user standpoint, and if you add a question as to skill level , i.e Maintainer to User, you can see how different groups interpret the terms too. On top of this you could possibly analyse the results by how many years the question taker has been on Drupal. In theory experience will improve their resonse.

Even after you have the best set of terms, their will be people using incorrect choices, some deliberately, others through various reasons, this is a fact, and unfortunately the only way they will learn is by educating them, but that is something potentially the whole community an contribute with.

catch’s picture

With 'solution- needs review' I could see it being used for things like 'turn off update status module', so I'd prefer we just went back to patch.

But anything which keeps merlinofchaos and quicksketch happy is fine with me.

babbage’s picture

+1 for 152 B).
+1 for 123 B).
+1 for 123 C).

dww’s picture

Oh right, "patch" is still in the running. we're up to:

A) solution needs review

B) solution (needs review)

C) has solution (needs review)

D) patch (needs review)

I really don't care that much. (D) sort of sucks for the doc queue, and most of the issues in infra and webmasters. I don't care about infra and web -- it's almost entirely power-users in those, and they're low enough traffic that a little misclassification can be easily corrected. It's really a question of the doc queue -- I don't follow that, so I don't know how much of a problem it really was when we were using (D) originally. There are also times, even for code-centric projects, when a proposed solution that doesn't involve a patch at all.

If I had to order these choices, I currently lean towards: (B), (C), (A), (D).

That said, I don't understand what's wrong with "turn off update status module" as a "solution" that "needs review" to a support request or something. @catch, I don't follow your objection...

Anonymous’s picture

Not only those queues. (A) works best for contrib issues without a patch attached but a patch embedded or a suggestion for a solution.

apaderno’s picture

That patch (needs review) is the wrong status to keep is shown from this report, which should use it, if needs review would not exist.

catch’s picture

dww: that was just used in the core issue queue as a solution to admin/build/modules being slow, on an issue which was marked duplicate of a patch which actually fixes it. I'm not sure 'solution' would stop mis-use of that. Also I generally don't like the word solution, sounds like 'IT solution'. I probably shouldn't be posting at this hour.

dww’s picture

@catch: No matter what the status values are, there will be outliers that don't use the issue queues, status workflow, tags, titles, etc, as "we" intend. Just because a small fraction does unexpected things doesn't carry any weight for my decision process on this -- again, we should make the best compromise we can (without investing the vast resources into researching this I mentioned in #150 and which was re-proposed in #156) and move on. There's real evidence that the current "needs review" is actively harming maintainer issue workflow, so that needs to change.

Anyway, I'm going to be busy most of the weekend (it's San Francisco Carnival -- I have a bunch of gigs), so I'm going to stop replying here. If anyone has any miraculously good suggestions in the meanwhile, let's hear them. Otherwise, I'm probably going to go ahead and implement #152 (B) (along with #123 (B) and (C)) on Monday.

webchick’s picture

So. Seriously, can one of the people advocating for this change not do #140 (or get someone else to do it)? It seems absolutely pointless to arbitrarily change the title of these in the hopes that it will solve the problem. We'll just be back here again in another 2 months. Let's quit trying to be psychic and just ask the sources directly.

Until actual confused users are asked to chime in here, I'm not really +1 to any change.

Pasqualle’s picture

don't forget that "patch (code needs review)" state is used by the testing bot. so maybe it should not be used for anything else..

apaderno’s picture

We'll just be back here again in another 2 months.

That is what I meant; people would keep to use the wrong issue status whichever set of choices they have, and there would be a new proposal for changing the issue statuses after this one.

Nobody seems to be able to provide statistics about the decrease of cases of wrong issue statuses used adopting the issue statuses they are pushing; in that case, what is the right reason to change? It should not be I push this issue because I like it better.

NancyDru’s picture

subscribing, but I don't know why. It's clear that this issue needs one person to make a decision and go with it.

Anonymous’s picture

Its now been 8 months since I first commented on this issue, and 2 years since it started.

If i were in business i would have sacked the lot of you :)

Ok simple facts

1/ No matter what choices you make here, there will still be users who chose an incorrect option, either through wanting to be akward or being new to the "Drupal Way". There is also the situation where a user may not be sure which of more than one category an issue may fit. Gut feeling may say its a bug, but they ask for support, others may mark it as a bug when its a support issue.

There is only one way to deal with this and that is education, unfortunately Drupal has an un-ending supply of students, so it becomes an un-ending task.

2/ It may need better documentation on the terms, or just make the statement from under the selectors

"Descriptions of the Priority and Status values can be found in the Issue queue handbook."

more noticable, possibly placing it above the selectors rather than after.

i.e tell people what you want them to do before they do it, rather than ask them to change it after they did it.

Maybe there is a way of using the advanced Help module to place a "?" next to each box, that then pops up a quick reference if selected by the user.

The present sytem of when you select priority and Status link is poor to say the least. For many users they will type the comment, then add the Category, Priority etc. But if they are unsure they select the link and wave goodbye to all their hard work as the new page opens in the same window, A simple tweak to open in a new window, but very effective, as its unlikely the user will type as detailed a report the second time, if they even bother at all

3/ Many of the existing options, are terms used outside of Drupal , so for some , an existing familiarity so use it to your advantage, don't try and re-invent the wheel.

I have over 25 years in Quality Assurance and developing systems and procedures. And even though a system is designed to give the management what they want, interpretation of the system will often give different results to what's expected, so you try and close the loopholes. A thought for you. do you know the difference between "Should" and "Shall", most people I have encountered when writing procedures do not.

I would recomend take a best guess at the options you want and ask Dreis to say yes or no, and impliment it, then monitor it or re-assess it in 6 months. Keep doin this till you get to an acceptable level of inaccuracy

sun’s picture

I kindly request to quickly add a new status

needs documentation

I know we have an issue tag for that, but all of those issues are marked "needs work", and the testbot also marks as "needs work", and maintainers also mark issues as "needs work".

So, I'm looking at issue queues + issue tag lists like http://drupal.org/project/issues/search/drupal?issue_tags=FilterSystemRe... and trying to figure out what exactly needs to be done now -- and I have to remember which of those issues marked as "needs work" need my immediate attention (because the next phase of freeze is right in front of us). That horribly sucks. ;)

Likewise, it's vice-versa - we have some awesome folks writing module/theme upgrade guides, but they can't distinguish between "needs work" due to "needs documentation" or whether an issue needed documentation, but was kinda re-opened to fix a regression or whatever.

Dave Reid’s picture

We really, really should have a needs documentation status for post-fixed issues. +1

ksenzee’s picture

+1 to adding a "needs documentation" status. Not sure what that's going to do to the documentation queue, so would like to hear someone who spends time there chime in. But we do need a solution for sun's use case. It's too hard to weed through this stuff.

sun’s picture

dww’s picture

Please (re)read #171350-113: Reorganise project issue statuses for why separate status values for each possible reason something needs work is a really, really bad idea. #582402: Allow to filter by issues NOT having a certain issue tag took a few swift clicks to implement, and is generally useful outside of this particular use-case. That's a vastly better solution to this "problem". ;)

drumm’s picture

Component: Redesign » Textual improvements
klonos’s picture

This issue is too long and dates way back for me to waste/spend time reading through. Instead, I'll simply propose something and let me apologize beforehand if it has already been suggested before. If it has, simply ignore me.

@dww: Derek, this mostly goes to you since you are the person this issue is assigned to.

On the other hand, I see no activity here since like a year ago, so thoughts are welcomed from everyone...

Has anyone given some consideration in using Hierarchical Select for issue statuses? This would solve the issue of not being able to add a refined issue status a lot of people seem to be reporting. I am aware of only one alternative solution to this and that is by simply using only a few 'generic' statuses and then adding some tags in order to further define status details. For example, people propose to use the 'needs work' status and then add tags like 'coding standards' or 'needs tests' etc.

These two features of Hierarchical Select stroke me as most relevant to this issue and lead me to post my suggestion here:

- the ability to save the entire lineage of a selection or only the "deepest" selection.
- force the user to make a selection as deep as possible in the tree.

This way we'll be able to have status hierarchies like so:

active (some action needs to be taken)
- patch available
-- needs work (this item's children might be placed as a 'workflow' in successive levels)
--- needs tests
--- needs documentation
--- codding standards
--- ...
-- needs review
-- RBTC
-- to be ported
--- ...
--- to 6.x
--- to 5.x
--- ...
-- postponed
--- needs confirmation by others
--- needs more information
--- future plans
-- reopened
--- regression
--- extra details provided
closed (done with - describe solution/reason)
- invalid
-- works for me
-- posted by mistake
-- duplicate
- never confirmed
- inactive for a long period
- won't fix
-- by design
-- feature offered by other project(s)
- fixed
-- workaround provided
-- committed
--- confirmed fixed by the community

The above is some sort of an updated version of my suggestion here. I believe that the two main parent-statuses 'active' & 'closed' in the above proposed hierarchy cover #735592: 'fixed' issues should not be automatically set to 'closed' - perhaps 'postponed' ones as well and mostly everything discussed in that issue.

I am really interested to hear what others have to say to that.

PS: The hierarchical menu just a draft proposal - the main suggestion here is to use Hierarchical Select for the status menu.

webchick’s picture

This actually seems more like a "won't fix" to me. Issue tags seem to have nicely taken care of adding any additional issue metadata we need to take care of, without bloating the status form to something horrifying that takes 20+ minutes to reach a decision on where something is in a workflow.

klonos: Just as a cultural FYI, it's incredibly disrespectful to simply skip over others' well-reasoned comments and simply chime in with your own. It implies that you think your time is more valuable than all of ours.

NancyDru’s picture

+1 for webchick (on both parts of her post).

Frankly, I think any issue that reaches 100 comments should automatically be "won't fix." Too much discussion means that it is not readily solvable and needs to re-thought and possibly sub-divided into smaller points. This is much like standard project management practice where it is a rule-of-thumb that any task that requires more than 80 hours should be divided up into smaller tasks.

klonos’s picture

How does one reply to such comments? ...especially when they come from two of the most respected members of the community! Well, let me start by re-apologizing for not reading through the whole issue posts. But...

@webchick: Angie, respect of one's own free time (and possible lack of it) surely doesn't imply anything else other than that. It's like stating that if one claims to be smart, they are actually calling everyone else stupid. Allow me to say at this point that I personally believe that the phrase 'free time' is a joke for most of us when it comes to real life (at least for me it is). The rest of the people are simply lucky. Doing something in your free time renders that time ...well the opposite of free.

As for my post, I did search for any mention of the term 'Hierarchical Select' before posting and all I did was think to myself: 'Hey this issue is stuck in NR for more than a year now! Why don't I just make a quick question if anyone thought of this idea or not? Perhaps this will get things going'. My intention was to help and not to disrespect every single member of the community as you suggest. I am not like that at all, but thanx for making me feel like sh**t (excuse my french) because of an idea of mine I dared to post. I'll try my best to prevent this from happening in the future.

Leaving aside the way your 'cultural FYI' made me feel, let me say that IMHO 'wontfixing' issues is the easy way to run away from an actual problem. The fact that so many people spent their free time to post their opinions on this matter proves how important it is to us. Ignoring us is 'incredibly disrespectful'. In fact I think there shouldn't even be a 'won't fix' status at all because it is way to selfish. If people simply don't have the time or interest to fix something, they should set it to 'postponed' till someone comes along to pick up the task. Don't you agree that this is more 'graceful'?

I have to give some credit to the way things work now with tags taking care of issue metadata, but if it was 'nicely taken care of' as you say, then people wouldn't have started this issue in the first place. Nor would they continue to suggest better ways if they didn't have any real-life issues with the way it's done right now. When it comes to my use case, I have almost completely given up on trying to follow up on 'closed' issues, simply because there is no way to filter them in order to separate the ones that were actually fixed (and then auto-closed) from those that were simply 'manually' set to 'closed' by someone. If you have any insight on how to achieve that, then please share.

@Nancy: I see you are in the project management business, so you know what you are talking about and your suggestion seems to make sense (I wouldn't know though). Still, as I said above, 'wontfixing' issues is not the way to go. Can you please help break this up in smaller issues then?

PS: I am sorry if I came a bit to hard to the things I've said above, but I did need to stress some of my points of view. It's not the way I say things, but the things I say that should matter the most.

PPS: ...that was quite long, so thanx for taking the time to read it.

webchick’s picture

My "won't fix" suggestion wasn't in response to your suggestion. It was in reference to the fact that this issue is so old, in fact so much that it pre-dates the addition of the issue tagging feature, which we as a community have long since settled on as our means of further describing the state of issues beyond their basic workflow state. It's pretty unclear what problem(s) we're even trying to solve here anymore.

And my "FYI" was simply that; an FYI. Regardless of your intentions, when you say things like "This issue is too long and dates way back for me to waste/spend time reading through." it makes it sound like you feel your time is more important than everyone else's, and this is generally not received well when everyone else on the issue has spent a great deal of their own time thinking through all the possible angles. I appreciate that your intention is to move issues forward, but you'll have better results if you do so in a way that supports the work of others who've already gone before you.

dww’s picture

Yeah, I'm -1 on Hierarchical select. This should be relatively simple, and that makes it even more complicated.

That said, thanks for bumping this issue, since I had forgotten about it. There's still some easy fixes to make that I think will help implicitly communicate intentions and help people navigate the queues. Namely:

#123 (B):
s/duplicate/closed (duplicate)/
s/won't fix/closed (won't fix)/
s/by design/closed (works as designed)/
s/closed/closed (fixed)/

#123 (C):
+ closed (cannot reproduce)

I hope that helps with things like people continuing to reply to "duplicate" issues, etc. None of the colors or behaviors would change. The only thing I'm talking about are the text labels.

I know I said this over a year ago, but, I mean it this time:

Unless there's a compelling reason *not* to make these changes, I'm going to go ahead and implement them on Wednesday 2010-08-18.

;)

Michelle’s picture

I have to -1 HS as well. It's a module with great intentions but a lot of problems. I recently removed it from my site because it crashed too often. :(

+1 to #181. Making it clear that those are closed will hopefully help some. Though I don't think there's any hope for people who subscribe to issues that are already marked closed. LOL!

Michelle

klonos’s picture

@webchick: Fair enough.

@dww: Thanx Derek, this all sounds good to me. Let's see if that'll actually solve my issue filtering problems.

@Michelle: talking about the way people subscribe to issues ...it is really sad that the only way to subscribe to an issue is having to post a comment (usually a simple 'subscribing') that simply adds to the list of posts without being of any actual use. Coming from a long time of using the Bugzilla bug tracking system this does feel awkward.

dww’s picture

klonos’s picture

Thanx Derek. Good to know something is actually being done about it ;)

NancyDru’s picture

Thanks, Derek and Angie.

The only "issue" I had was the way I used "won't fix" and now that we have tags, even that's fixed. I use "won't fix" more as "revisit occasionally" to see if I've changed my mind; now I can add "revisit" as a tag.

@klonos: I think Derek is doing the right thing and that is that. As a maintainer, I think tags suit my purpose well enough.

dww’s picture

Status: Needs review » Fixed

Finally! ;)

For example:

http://drupal.org/project/issues/search/drupal
http://drupal.org/project/issues/search/views
http://drupal.org/project/issues/search/project
...

I also added "closed (cannot reproduce)" to solve the *original* problem reported in this issue.

I almost renamed "fixed" to "recently fixed" while I was at it, but let's use a new issue for this (#886924: Rename "fixed" issue status to "recently fixed") so this one can finally be put to rest. ;)

Michelle’s picture

Yay dww!

Thanks. :)

Michelle

webchick’s picture

Status: Fixed » Needs work
Issue tags: +Needs documentation

Bzzt. Not fixed. Need to document this change at least here http://drupal.org/node/156119, possibly other places.

webchick’s picture

And from reports on IRC, it looks like we're missing permissions on these new statuses as well.

webchick’s picture

I fixed the permissions stuff, still needs docs.

It would be nice for one of the people who were advocating for this change to take this on.

dww’s picture

Status: Needs work » Fixed

Docs are fixed:
http://drupal.org/node/156119/revisions/view/1029566/1120896

Sorry about the friggin' permissions. I keep forgetting those are tied to the human-readable labels, not the underlying status ints (none of which changed). Thanks for fixing that, webchick!

If anyone else wants to further edit my doc changes, knock yourselves out. ;)

Thanks,
-Derek

NancyDru’s picture

Thanks, Derek.

klonos’s picture

Perfect! Thanx ;)

Status: Fixed » Closed (fixed)
Issue tags: -Needs documentation

Automatically closed -- issue fixed for 2 weeks with no activity.