jdforrester wrote on 2014-05-30 18:34:42 (UTC)

[Updated] proposed set:

• OPEN
• RESOLVED
• DECLINED (rather than WONTFIX)
• NOTABUG (rather than INVALID, also replacing WORKSFORME)
• NEEDSINFO (consistent with not using "_"s, INCOMPLETE sounds like it's about the task, not the request)

Will validate these with other Product people.

(Do we want to represent PATCH_FOR_REVIEW or DEPLOYED states somehow?)

qgil wrote on 2014-05-30 19:04:51 (UTC)

What you are saying is that we can keep the current behavior, just changing the strings:

• Open --> Open
• Resolved --> Resolved
• Wontfix --> Not a Bug
• Invalid --> Needs Info

Boy do I wish we could have separate statuses per project per task (eg: Fixed in master but open in 1.23.0)

Remove the task from "MediaWiki" but keep it in "MediaWiki 1.23.0"?

swalling wrote on 2014-05-30 19:19:46 (UTC)

We should strive for absolutely simplicity and as small a number of states as possible. The more choices we provide the more confusing things are for all users. My thoughts, also replicated on the Product list are thus...

[Updated] proposed set from @jdforrester:

OPEN
RESOLVED
DECLINED (rather than WONTFIX)
NOTABUG (rather than INVALID, also replacing WORKSFORME)
NEEDSINFO (consistent with not using "_"s, INCOMPLETE sounds like it's about the task, not the request)

I don't think we need INVALID/NOTABUG or NEEDSINFO.

INVALID is required when Bugzilla has a "Resolved fixed" status. (If something is not a bug, you can't mark it as fixed.) We just have a resolved state now, and an issue is resolved whether we fix it with a patch or if we investigate and it was never an issue to begin with.

NEEDSINFO is just adding additional state complexity to Needs Triage. Either leave something in Needs Triage, or triage is as lowest possible priority, while requesting more info. If someone can't provide more info, then mark it as Resolved.

Declined is definitely better than WONTFIX. I will keep thinking on options there, but would be comfortable using that language.

qgil wrote on 2014-05-30 19:25:02 (UTC)

The problem with making "Needs Info" equivalent to "Needs triage" is that it is difficult to know who to blame. While "Needs triage" means that the ball is in the field of the triagers / maintainers, "Needs Info" shows that it is he reporter who need to do some homework.

swalling wrote on 2014-05-30 19:31:31 (UTC)

The problem with making "Needs Info" equivalent to "Needs triage" is that it is difficult to know who to blame. While >"Needs triage" means that the ball is in the field of the triagers / maintainers, "Needs Info" shows that it is he reporter >who need to do some homework

Someone needs to be responsible for shepherding a task forward. Adding complexity to the state of tasks doesn't really help. They need to just step up and manage the state of the task. This is why we have maintainers, product managers, bugmeister, and other people in these roles.

jdforrester wrote on 2014-05-30 21:02:13 (UTC)

Steven – Please warn if you're forking the conversation so I don't have to respond in two places! :-)

I agree with Quim and disagree with Steven re. the appropriacy of not having a NEEDSINFO state in terms of user interaction.

I also disagree with Steven re. polluting the "RESOLVED" status space with bugs that are not resolved but instead weren't appropriate bugs for whatever reason (like problems with gadgets, configuration mistakes, or issues with a localisation string or whatever else is a problem not tracked in Phabricator).

swalling wrote on 2014-05-30 21:18:28 (UTC)

Think about the best, most beloved issue trackers currently in use (Trello, for instance). Then compare to Bugzilla, which everyone except random volunteers, Platform, and VisualEditor have pretty much abandoned as their canonical issue tracker.

Trello and most other good trackers: only two states: archived/resolved or open.
Bugzilla: too many status, priority, target and other state options to bother counting.

This should be indicative how you're overcomplicating things.

scfc wrote on 2014-05-31 02:25:24 (UTC)

In T359#16, @Qgil wrote:

The problem with making "Needs Info" equivalent to "Needs triage" is that it is difficult to know who to blame. While "Needs triage" means that the ball is in the field of the triagers / maintainers, "Needs Info" shows that it is he reporter who need to do some homework.

"Need(s) info" (as a concept) isn't necessarily limited to the reporter. It can also be used to indicate that input from ops, legal, design, etc. is needed. In general, it should move a bug from the dashboard of the assignee to that of the designated person.

In T359#12, @Qgil wrote:

What you are saying is that we can keep the current behavior, just changing the strings:

• Open --> Open
• Resolved --> Resolved
• Wontfix --> Not a Bug
• Invalid --> Needs Info

[...]

This doesn't make sense to me. In Bugzilla, INVALID is used when someone complains that "expr 2 + 2" doesn't output 5 (and it shouldn't), WORKSFORME when the complaint is that it doesn't output 4, but for the triager it does, and WONTFIX if someone wants "expr 2.1 + 1.9" to work, but the developers consider this outside the scope of expr.

Also, IMHO in general if Phabricator has a different (default) set of statuses, I would be very hesitant to change them without a very good reason as it will introduce another little unnecessary hurdle for contributors.

avive wrote on 2014-05-31 20:40:59 (UTC)

In T359#8, @greg wrote:

Boy do I wish we could have separate statuses per project per task (eg: Fixed in master but open in 1.23.0)

Workboards kinda-sorta-coulda support this:

aklapper wrote on 2014-06-02 18:30:11 (UTC)

CC'ing those top 10 bug closers listed on http://korma.wmflabs.org/browser/its.html who have an account here:

Are any specific thoughts on task/ticket statuses in Phabricator, based on your experience in Bugzilla?

greg wrote on 2014-06-02 20:25:20 (UTC)

[removing not useful part of this comment]

Bugzilla is still officially canonical, for the record.

greg wrote on 2014-06-02 20:26:02 (UTC)

In T359#22, @avive wrote:

In T359#8, @greg wrote:

Boy do I wish we could have separate statuses per project per task (eg: Fixed in master but open in 1.23.0)

Workboards kinda-sorta-coulda support this:

Interesting.... That's a hack, but yeah, that could do it.

parent5446 wrote on 2014-07-10 17:35:20 (UTC)

In T359#21, @scfc wrote:

This doesn't make sense to me. In Bugzilla, INVALID is used when someone complains that "expr 2 + 2" doesn't output 5 (and it shouldn't), WORKSFORME when the complaint is that it doesn't output 4, but for the triager it does, and WONTFIX if someone wants "expr 2.1 + 1.9" to work, but the developers consider this outside the scope of expr.

Agreed with this. WONTFIX, WORKSFORME, and INVALID are all three different, distinct resolutions, each representing a different community consensus concerning the bug reported.

Also, keep in mind that in Bugzilla, all of those (as well as FIXED and DUPLICATE) are not separate statuses, but rather all kept under the umbrella of RESOLVED. In reality, Bugzilla only has five statuses: UNCONFIRMED, NEW, ASSIGNED, PATCH_TO_REVIEW, and RESOLVED (we don't really use VERIFIED, so I left it out). With that in mind, ASSIGNED is really unnecessary in both Bugzilla and Phabricator, and PATCH_TO_REVIEW also is not necessary in Phabricator.

That brings us down to just three statuses: UNCONFIRMED, NEW, and RESOLVED. If there was a way to sub-categorize statuses in Phabricator, that would make things a lot simpler. In the end, though, I think it is necessary to keep the various sub-categories of RESOLVED (there names could be changed; I don't care about the naming).

qgil wrote on 2014-07-11 13:44:43 (UTC)

Revisiting this topic, I think we can use better the possibilities of Phabricator that were limitations in Bugzilla, requiring all these different types of statuses.

What about this:

• Open
• Needs Info
• Resolved
• Declined + optional tag project

"Open" means that a task is actionable. The rest is defined by its current priority and details like having someone assigned to it, or visible activity in the form of mockups, patches...

"Needs Info" deserves an own status to raise attention. These tasks may be declined (automagically?) if no info is received after some period.

"Resolved" means that the task is considered completed.

"Declined" means that the maintainers are removing the task from the plate. Reasons will differ, but the end result is the same: reporters and other contributors must do some homework if they want to reactivate them. Project tags can be used optionally to catalog tasks that might interest someone. Think of projects like "Non Reproducible" or "Out Of Scope".

Bugzilla-Phabricator mapping:

parent5446 wrote on 2014-07-11 14:19:18 (UTC)

@Qgil, that looks pretty good. There's just a small error in your mapping table. UNCONFIRMED should map to "Needs Info", since, like you mentioned earlier, triage has more to do with the maintainers deciding the priority rather than the bug needing more information.

aklapper wrote on 2014-07-14 11:30:27 (UTC)

@Qgil: Thanks, this looks really really good indeed (though I wonder a little bit with regard to workflow how tedious it'll be to change task status to Declined plus also add a "Out Of Scope" / "Non reproducible" project to that task). I guess that "Out of scope" would also cover "should be fixed in upstream" as it's "not our bug".

qgil wrote on 2014-07-14 12:43:56 (UTC)

@Parent5446, if I'm not mistaken, in Bugzilla reports are by default UNCONFIRMED until some action makes them NEW. The equivalent default status in Phabricator is Open + Needs Triage. "Needs Info" is a status that must be set manually, therefore it cannot be the default for all new tasks.

@Aklapper, adding projects to declined tasks should be optional, and done when such projects help the task and the reporter somehow. Also, adding one tag-project can save you the work of typing a manual comment.

If "should be fixed in upstream" means "we won't work on it", then it can be Declined + project Upstream, and additionally we could even add a project for the specific upstream e.g. "Elasticsearch" if that helps us tracking tasks. We can also have tasks that must be fixed upstream, but our maintainers are planning to work on them, as it is the case already now here with certain Phabricator tasks.

aklapper wrote on 2014-07-14 14:16:53 (UTC)

VERIFIED status in Bugzilla is being used by the Wikidata team - wondering how important it is to them in their development workflow, and if they could live without it for the sake of keeping it simple and stupid. I've pinged Lydia on IRC as I couldn't find an account here.

aklapper wrote on 2014-07-14 14:26:09 (UTC)

Hmm, same VERIFIED question goes to the VE team, actually (@jdforrester).

<Lydia_WMDE> we do use it for basically acceptance confirmation. ie ideally dev sets it to resolved fixed and then i go and set it to verified. doesn't entirely work atm though
<andre> the question is probably "what would you lose if it wasn't available anymore". Plus VE and Wikidata seem to be the only teams using VERIFIED.
<Lydia_WMDE> we would lose a second stage of review/confirmation.
<Lydia_WMDE> so i can live without it but i think we should have it
<andre> does anybody ever query for VERIFIED specifically (or excluding that from RESOLVED tickets)? What if this was just added as a comment instead?
<Lydia_WMDE> i query for all resolved fixed ones to go through them and verify
<andre> so if you could query for resolved tickets and exclude those which have a "has been verified" comment, would that also work? :D
<Lydia_WMDE> doesn't feel very nice/clean
<andre__> I'm wondering if adding a "Wikidata verified" (or so) project instead might work. Need to think about it.

Rush wrote on 2014-07-14 15:03:38 (UTC)

could verified be a workboard status rather than a full on issue status?

some of the team specific workflow can be handled at the alternative abstraction layer I think

qgil wrote on 2014-07-14 15:13:43 (UTC)

@Rush was faster than me. I was also about to say that workboards offer all the degrees you need between Open and Resolved.

Rush wrote on 2014-07-14 16:00:34 (UTC)

Bugzilla-Phabricator mapping:

Bugzilla	Phabricator
UNCONFIRMED (default)	Open + Needs Triage (default)
NEW	Open
ASSIGNED	Open + Assigned To
PATCH_TO_REVIEW	Open + Code Revisions
NEED_INFO	Needs Info
RESOLVED FIXED	Resolved
RESOLVED INVALID	Declined
RESOLVED WONTFIX	Declined + project "Out Of Scope"
RESOLVED WORKSFORME	Declined + project "Non Reproducible"
RESOLVED DUPLICATE	(merged)

I think this is a stupid question on my part, but are you suggesting a literal "out of scope" project that tasks are added to for this? or that there is a ticket state for which the option would be "declined - out of project scope'. The first I don't think will work across the gamut just because it's too big of a bucket to be meaningful across all the projects / teams / workflows, etc,. The second seems like a very specific category of declined?

Declined does seems more diplomatic than won't fix :)

Work-for-me is a terrible state for a ticket to be in as it doesn't mean anything. It just means two people had different experiences. It doesn't mean something needs more work, and it doesn't mean something _doesn't_ need more work. It's not a task or issue state so much as it could be the genesis of an open/closed state, yet is neither. It doesn't seem meaningful, and could literally be a less valuable version of NEEDS_INFO.

INVALID = this cannot be done.

And, dear god please forgive me for even bikeshedding to this degree, but resolved fixed is less good than resolved closed (phab default). Closed is wide enough to include hey we talked about it and decided it's a no, but good question. Fixed implies changes...maybe only to me...whereas an issue can definitely be moved out of an open state without anything being modified other than a requesters state of mind :)

I think in some cases for resolved subtypes we are trying to cram a lot of information into this basic ticket state that doesn't necessarily fit there. We could conceivably make a separate ticket field to indicate the resolved reasoning as in.

Resolved....

RATIONALE...wonfix/invalid/fixed/foo/bar/whatever/

The only thing I feel is a strong point is that invalid is a distinct state for a ticket to be in outside of normal resolution, and it is important to distinguish between this isn't possible and we are not doing this

qgil wrote on 2014-07-14 17:01:42 (UTC)

In T359#40, @Rush wrote:

are you suggesting a literal "out of scope" project that tasks are added to for this? or that there is a ticket state for which the option would be "declined - out of project scope'.

The former, but using the project just as a tag. Those tasks will be declined. We can forget about them. No team, sprint, dashboard, etc, will be assigned to those. You can always make elaborate queries if you need them: which tasks were "Declined" (Status) as "Out Of Scope" (tag-project) in "Visual Editor" (project-project)?

Work-for-me is a terrible state for a ticket to be in as it doesn't mean anything.

Following the proposal above, the migration script should convert Bugzilla's WORKSFORME reports in Declined + project "Non Reproducible" tasks. In Bugzilla WORKSFORME sometimes is used as "what you see as a bug is correct behavior in my eyes", which is different than "Non Reproducible". I would still apply the same rule and leave the old bugs Rest In Peace.

resolved fixed is less good than resolved closed

For the sake of the migration skip, I would treat both as equal.

The only thing I feel is a strong point is that invalid is a distinct state for a ticket to be in outside of normal resolution, and it is important to distinguish between this isn't possible and we are not doing this

Declined + project "Invalid" for the migration? No matter what, they are still declined tasks. I just want to avoid if possible to have an option in the Status that will not be used in the 92% of cases (if we have to trust Bugzilla stats). Besides, if we dig deeper in the current INVALID reports we will find different reasons to reach to that resolution, including out of scope, spam, poorly written, and more.

Having one "Declined" resolution and specific tag projects allow us to be (optionally) more precise without cluttering the Status field.

aklapper wrote on 2014-07-15 17:09:46 (UTC)

Generally speaking: It's all about "keep it simple and stupid" vs "I want to categorize everything" and finding a good compromise. Before commenting, everybody should question themselves whether they do care a lot about expressing a reason via task status and if they really query for tickets and differentiate on that status, or if they can also survive having the reason in a project workboard column or comment only which is harder to search for.

Regarding the proposal to set projects in addition to the "Declined" status, I've in the meantime gotten afraid that people won't do that. I cannot exactly prove it and the quote refers to fixed issues, but: "Of course, the developer could change the issue category after resolution---but this happens rarely. In many cases there exists no real motivation to change the issue category once the cause for a problem is found and fixed." from http://www.st.cs.uni-saarland.de/softevo/bugclassify/paper/icse2013-bugclassify.pdf page 396.

A status called "Invalid": There are opinions in Mozilla ( http://eaves.ca/2011/07/27/lessons-for-open-source-communities-an-example-for-bug-tracking-more-efficient/ and https://bugzilla.mozilla.org/show_bug.cgi?id=592533 ) that average users who incorrectly filed a support request (configuration, on-wiki gadget issues) as a task/bug report and who are not used to dev workflows/terms, that "invalid" can feel derogative, but I really cannot come up with a better term after looking at other issue trackers and their terms, so I naively call it "Invalid here" instead of "Invalid".

I am probably less afraid of cluttering the status field if people really want to differentiate reasons for closing. The ~dozen of Bugzillas I sometimes interact with have 5-9 statuses and 6-13 resolutions. Combining that in one field in Phab, I think we're not too bad if we ended up with 7 or 8 task statuses.

Summary:

• Needs Triage
• Open
• Needs Info
• Resolved
• Invalid Here (resembling "Invalid", "Nothing for a Phab task", "Spam", "Support request", "On-Wiki issue", "Upstream it", "Works as intended" etc.)
• Declined (resembling "Wontfix", "Out of scope", "Actively against fixing this", "Overcome by events" etc.)
• Unreproducible (resembling "Works for me", "Insufficient data", "Feedback Timeout", "Your computer got hacked by an interwebs virus that displays ads on Wikipedia" etc.)

and

• "Verified" as an optional workboard column per $project if $project wants it.

Rush wrote on 2014-07-15 20:01:46 (UTC)

andre as usual you come up with good stuff.

@qgil...I really liked your thoughts, over the evening yesterday tho I became less convinced people would actually do it :) I think it's a really cool idea within domains for people to utilize, ops could do this for their own stuff, andre could do it too. Anyone who can ensure their own consistency it would work out for, but I don't feel like the
workflow of a task lends itself to the status+project combo being a good default mindset sort for the big 3 or 4 or even 5 cases.

I think the real difference tho is I don't view invalid as a subset of declined. I do look at declined tasks as having value in a historical sense, and invalid tasks are really waiting to be purged out when they become cumbersome enough.

I don't see a difference between unreproducible and declined. Do we not decline as unreproducible? But in general, if it's a broad enough brush to be it's own bucket. Fine with me.

I also think, unreproducible could be a form of needs_info. that probably makes the most sense to me.

Needs triage is a priority right? Not a status.

needs_info seems kind of odd, why not the suggested [incomplete]

That means the status's would be something like:

->

invalid and declined here are also taking the place of reject which exists in rt. we do get spam there as well.

Also, really liking andre's 'resembling' identities for the categories.

qgil wrote on 2014-07-16 10:38:30 (UTC)

Ok, we can forget about tag-projects for Day one (and therefore the migration). They can always be added to the process at a later stage if somebody misses them or has a better idea of what to do with them.

I agree that Unreproducible is a variant of Needs Info.

In T359#43, @Rush wrote:

I agree with these statuses; descriptions to be fine tuned.

aklapper wrote on 2014-07-16 13:28:23 (UTC)

Assuming that "Declined" covers both "sorry but we really could not reproduce" and "we are against fixing it", this is probably the smallest set of statuses one could come up with. Thank you Quim. :)

One aspect left: Gerrit patch notifications in Phab in T277 (as long as we have not killed Gerrit in T42): I have no idea yet if or how we want to implement the behavior of the "Patch to review" status in Bugzilla. Another status, temporarily until we've fixed T42? (as I have a hard time to imagine notifications triggering changes to a column in a project's workboard, as the naming scheme of columns in per project)

qgil wrote on 2014-07-16 15:01:29 (UTC)

Since those Gerrit patch notifications are created by a bot, here we could apply the idea of Open + project "Patches For Review".

The same bot could remove that project if the patch is merged/abandoned.

Rush wrote on 2014-07-16 15:25:24 (UTC)

@Aklapper can you help me understand more about what you mean by gerrit patch notifications?

I know there is some interaction between bugzilla and gerrit, but haven't used it myself.

greg wrote on 2014-07-16 16:53:22 (UTC)

In T359#48, @Rush wrote:

@Aklapper can you help me understand more about what you mean by gerrit patch notifications?

I know there is some interaction between bugzilla and gerrit, but haven't used it myself.

Basically, since there is no tight integration between Gerrit and BZ, all we have is a bot that comments on BZ bugs when there's a new related patch, eg https://bugzilla.wikimedia.org/show_bug.cgi?id=67270#c26 and when said patch is merged eg https://bugzilla.wikimedia.org/show_bug.cgi?id=67270#c27 (and similar message for abandoned). When it comments that there's a related patch, it also changes the STATUS to PATCH_TO_REVIEW.

You get the fancy behavior by including "Bug: 12345" at the bottom of the change commit message (right before the change-id gerrit needs at the very bottom).

I personally think there should be an "in-progress" or whatever status as well, that says "someone is actively working on this, check the assignee field for who". The Gerrit bot could set that status when it has a related patch. (We basically use "ASSIGNED" in BZ for that now.)

The PATCH_TO_REVIEW status in BZ is a hack, I believe, because BZ doesn't have a nice way of querying bugs that have linked Gerrit commits associated with a bug. ie: the issue that will be solved when we also transition code review to Phab from Gerrit.

aklapper wrote on 2014-07-16 17:13:05 (UTC)

The PATCH_TO_REVIEW status in BZ is a hack, I believe,

Yes, it's done by https://gerrit-review.googlesource.com/#/admin/projects/plugins/its-bugzilla set up by qchris and setting up a status looked like the most visible way (in additional to the comment created by that plugin). See http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065046.html and https://gerrit.wikimedia.org/r/#/c/69843/ for historical data.

"someone is actively working on this, check the assignee field for who"

That's what workboards are for, IMHO?

greg wrote on 2014-07-16 17:24:13 (UTC)

In T359#50, @Aklapper wrote:

"someone is actively working on this, check the assignee field for who"

That's what workboards are for, IMHO?

If the task is in one and only one project, and that project uses workboards (not all will), sure. But if there's any deviation from that, no, not really.

qgil wrote on 2014-07-16 18:46:35 (UTC)

Bugzilla has so many ASSIGNED reports where it is not true that "someone is actively working on this, check the assignee field for who".

I'd rather have us rely on Open + Assigned To + workboard OR the assignee commenting about their intentions (so nobody else steps on their toes).

Rush wrote on 2014-07-16 18:53:44 (UTC)

so seems like we can mimic this gerrit bot that notifies bugzilla with phab, but without a PATCH_TO_REVIEW status that step would be replaced by another comment linking to the merged patch?

greg wrote on 2014-07-16 23:33:21 (UTC)

In T359#52, @Qgil wrote:

Bugzilla has so many ASSIGNED reports where it is not true that "someone is actively working on this, check the assignee field for who".

fwiw: I actively use that as a means to track work my team is doing. Some other projects/components don't have people tending the garden actively.

Rush wrote on 2014-07-17 14:48:37 (UTC)

@greg, would it work for you if there was an automated tag for issues in this state for now instead?

so you could go do phab.wm.com/tag/patch_to_review and see all tasks in this status.

That way we don't end up with an unused ticket status in the future, and since it's automated we can ensure consistency.

greg wrote on 2014-07-17 16:31:00 (UTC)

In T359#55, @Rush wrote:

@greg, would it work for you if there was an automated tag for issues in this state for now instead?

so you could go do phab.wm.com/tag/patch_to_review and see all tasks in this status.

That way we don't end up with an unused ticket status in the future, and since it's automated we can ensure consistency.

For me, yeah, probably. How are tags added/removed? I can't seem to find it in "Edit task"

Rush wrote on 2014-07-17 17:01:14 (UTC)

@greg...I will forgo my speech on projects and organization :D

But really it's that all projects function as tags at the basic level. So we make a patch_to_review project and add and remove as appropriate for filtering.

scfc wrote on 2014-07-17 22:55:59 (UTC)

A recurring problem in Bugzilla with PATCH_TO_REVIEW as a status is that, as it is used as a flag, when a patch is merged/abandoned, one has to go through all the comments to see if this was the only patch to have triggered setting the flag in the first place (and if it previously was UNCONFIRMED, NEW or ASSIGNED). A Phabricator replacement should take into account that there is a n:m relationship between bugs and patches and ensure that the UI provides a clear picture of the existence of open patches.

greg wrote on 2014-07-17 23:13:16 (UTC)

In T359#58, @scfc wrote:

A recurring problem in Bugzilla with PATCH_TO_REVIEW as a status is that, as it is used as a flag, when a patch is merged/abandoned, one has to go through all the comments to see if this was the only patch to have triggered setting the flag in the first place (and if it previously was UNCONFIRMED, NEW or ASSIGNED). A Phabricator replacement should take into account that there is a n:m relationship between bugs and patches and ensure that the UI provides a clear picture of the existence of open patches.

In phase 1 (ie: after we've only transitioned Bugzilla to Phab, not Gerrit), that's out of scope.

For phase 2 (ie: after we've also transitioned Gerrit), that will be implicit in that fact that we use Phabricator :)

You can see a good example of what that looks like on the upstream Phabricator instance where a Task has many Diffs associated with it, and you can quickly see how many are merged/open: https://secure.phabricator.com/T2772

jdforrester wrote on 2014-07-23 16:14:19 (UTC)

In T359#45, @Qgil wrote:

invalid	no historical value will be purged eventually (spam, etc)

This is a pretty big change in semantics – right now, INVALID and WONTFIX are used to distinguish between different shades of declines. I'd roughly categorise them as:

• "truly invalid" – spam reports
• "misplaced" – things filed in Bugzilla which aren't dealt with in Bugzilla
• "overtaken by changes" – things asking for changes that made sense at the time but don't now
• "mistaken" – things which are this way by design (more often labelled WONTFIX).

We'll need to make sure people are careful not to use "invalid" the way they've been using INVALID. Maybe purging isn't the best idea

Nemo_bis wrote on 2014-07-24 01:02:24 (UTC)

(marked as duplicate)

Can this status be searched?

qgil wrote on 2014-07-24 10:37:59 (UTC)

The status that appears at the top of merged tasks is "Closed, Duplicate", so it should be as searchable (or not, see below) as the rest of statuses.

As far as I can see, users can only search tasks by status Open/Closed. At least I can't see a checkbox for the different Closed statuses at the Advanced Search. Querying "Merged into" will get you pretty close (I hope this URL works).

aklapper wrote on 2014-07-24 11:14:45 (UTC)

In T359#67, @Nemo_bis wrote:

(marked as duplicate)

Can this status be searched?

See "Status" section on http://fab.wmflabs.org/maniphest/query/advanced/ - there is an explicit "Duplicate" checkbox.

qgil wrote on 2014-07-24 11:17:36 (UTC)

True! I was looking at the general advanced search instead of Maniphests' advanced search. Problem solved, then.

qgil wrote on 2014-07-24 11:32:59 (UTC)

James, I think the statuses and their descriptions listed at the top of this task satisfy your concerns. I agree that we cannot just delete all what is marked Invalid. In fact, Phabricator doesn't bring any need to change the current policy for deleting reports in Bugzilla.

In T359#63, @jdforrester wrote:

• "truly invalid" – spam reports

These will indeed be unpublished/deleted as soon as they are detected. Maybe we can have a "Spam" project in order to allow users to report spam. Then the right team with the right permissions can unpublish them.

• "misplaced" – things filed in Bugzilla which aren't dealt with in Bugzilla
• "overtaken by changes" – things asking for changes that made sense at the time but don't now

"This is not a task, or it is out of scope in Wikimedia Phabricator." Clearly "Invalid". Will stay.

• "mistaken" – things which are this way by design (more often labelled WONTFIX).

"Bad idea, cannot be reproduced, missing information has not been provided, or an acceptable alternative exists." Clearly Declined. Will stay.

aklapper wrote on 2014-07-24 12:31:01 (UTC)

I assume good faith when editing the description, but I'd STILL appreciate if no wrong data was entered. ;) Fixed.

Nemo_bis wrote on 2014-07-25 19:01:48 (UTC)

In T359#73, @Aklapper wrote:

I'd STILL appreciate if no wrong data was entered. ;) Fixed.

After http://fab.wmflabs.org/transactions/detail/PHID-XACT-TASK-xukns75c3p24el7/ it's ok; I have merely copied the official descriptions from mediawiki.org, UNCONFIRMED and REOPENED are practically equivalent now so they should be in the same group.

Rush wrote on 2014-08-13 20:12:41 (UTC)

ran into a problem here:

needs_info is a not a valid possible status

[Core Exception/Exception] Key "needs_info" is not a valid status constant. Status constants must be 1-12 characters long and contain only lowercase letters (a-z) and digits (0-9). For example, "open" or "closed" are reasonable choices.

Rush wrote on 2014-08-13 20:13:01 (UTC)

trying just "stalled" as a needs info alternative

qgil wrote on 2014-08-14 12:00:11 (UTC)

Maybe this refers to the value, being different to the string shown in the UI? This instance is showing "Resolved", "Wontfix", "Invalid" in upper case.

If this is the case, we could have "needsinfo" as value and "Needs Info" as UI string.

qgil wrote on 2014-08-14 12:00:39 (UTC)

Ooops, sorry for resolving accidentally.

Rush wrote on 2014-08-14 19:57:33 (UTC)

tinker...tinker...tinker...I got it to work I think.

I updated the values on this install to match what i have for prod. this install is kinda of a pain since everthing is a one-off and I can't just use the same config.

anyhoo -- check it out.

qgil wrote on 2014-08-15 11:45:56 (UTC)

Great!

Task completed? I volunteer documenting this in https://www.mediawiki.org/wiki/Phabricator/Help

qgil wrote on 2014-08-18 21:16:06 (UTC)

Currently we can see messages talking about tasks moving from "Unknown Status" to "Declined". See for instance at the end of T432. What is this "Unknown Status"? Looks like it's "Open", although maybe there is another factor in play.

aklapper wrote on 2014-08-18 21:20:42 (UTC)

Re last comment: We renamed some statuses in this fab.wmflabs.org instance to "implement"/reflect the decisions made in T359, and we realized that when a status (in this case the previously existing WONTFIX) goes away, Phab resets a task's status to unknown. Next time we know better, and I fixed that manually now to not run into inconsistencies for T336.

importing issue status

In RT we actually use "Stalled" sometimes, with meaning which is quite different from "Needs Info". Needs Info implies we're waiting on someone to provide info to be able to make progress with a bug.

"Stalled" for us can mean things like:

• Waiting on a 3rd party to do/implement/deliver something (vendor or whatever)

It's not really "needs info", it's also not blocked on a task we can resolve ourselves, but we can't make progress on this task either

or

• We're going to do this, we keep track of it, but the right time (or some other precondition) for it hasn't come yet

For example, "decommission server X at date Y." Of course, in some such cases, being able to list the precondition (such as a defer date) in ticket metadata would be even better.

Since "Stalled" is more generic than "Info" and can be used for a wider variety of things, we'd still like to have this status available for our projects...

Have you considered using column workboards for these specific conditions? Then the label of the column appears in the description of the task. Like here, above, you can see "(Need Discussion)" now, you would have al the flexibility to decide other conditions your tasks are stuck on i.e. "Stalled".

Also for what is worth, I have been thinking about proposing tags like "2015-03" to denote tasks that need to be acted upon at a certain point in the future, but not now.

Hmm, maybe, we can experiment with it.

I do think that "Needs Info" is a rather specific case of a status for a ticket which can't progress, wouldn't it be better to use something more generic (like stalled)?

I agree that "Needs Info" can be renamed to something more generic. Also, we put a lot of effort trying to reduce the number of options for Status and other selectors compared to Bugzilla, and this is why you can feel my resistance to add a new status. Nothing against RT practices personally.

So what about "Waiting". This would mark tasks as "Open, Waiting", showing clearly that even if the task is assigned and has "Unbreak Now!" priority (hypothetical extreme case", the owner explicitly cannot do anything but wait for another event. Then we can define the reason for the wait via tags or workboard columns, tbd and in the ways that works better for every team.

@Aklapper, does this work for you?

In my brain "Needs info" vaguely translates to "blocked on somebody or something" which is close enough to "Stalled" or "Waiting". Both works for me.

We need to document that well, otherwise people might come up with interpretations like "I'm waiting for a developer to take a look at this and fix this!!!" or such. ;)

The (small) problem I see with "Stalled" is that it is a bit of an idiom that might confuse our international and/or non-tech userbase.

A synonym of Stalled that would rhyme with Resolved, and Declined is "Paused". The more I see it, the better I prefer it over "Waiting". What do you think?

Whatever it is, will be decided latest by our meeting on Monday. :)

"Paused" is an alternative, sometimes appropriate, other times it's not: "Paused" feels more voluntarily put in waiting than "Stalled" does. But sometimes that's exactly what we want/mean.

I don't particularly care that much, and I don't want to get into bikeshedding over this. All of this is better than the more specific "Needs info" IMHO.

FWIW I would just go w/ stalled. We already use it in one of the originating import system cases, and if it is truly an issue we can revisit at a later date.

Stalled, then. Moving on. Thanks!