We usually use keywords for that sorta thing..

Keywords are limited to a rather small set. Flags allow to be more flexible and can also carry a payload.

E. g. "?triage(mobile)" -> "+triage(mobile)".

(In reply to comment #2)

Keywords are limited to a rather small set. Flags allow to be more flexible
and can also carry a payload.

Flag are also limited to a small set -- how ever many we configure.

I'm not sure why you think they are more flexible.

Unlike keywords, they do have three states: ?, +, -

Still, I'm willing to set them up if you let me know which flags you want on which components. I think allowing the "canconfirm" group to request flags is reasonable. The grant group also needs to be set.

'm not sure whether it is intended to be used within MediaWiki components, but assuming this is indeed the feature described here [1] ... I think this introduces unnecessary bureaucracy. We have keywords and milestones. And users can edit as they see fit using the "wiki" culture ideal. If people disagree or if thinks become problematic, then however gets to make the call can set it put and leave an instructive comment.

We don't need to have more queues of users suggesting a change to milestone, status or keyword. Just do it :)

• Krinkle

[1] http://www.bugzilla.org/docs/2.22/html/flags-overview.html

Thehelpfulonewiki wrote:

Resetting to default per bug 37789

Created attachment 11142
Screenshots from bugzilla.mozilla.org

(Disclaimer: From past experience in several Bugzilla instances I do favor some kind of indication that a ticket misses sufficient information, in order to 1) clean up the bug database by closing such tickets after a while as RESOLVED WORKSFORME/INVALID and 2) to save developers' time by not looking at such tickets as long as they miss sufficient information.)

https://bugzilla.mozilla.org/show_bug.cgi?id=778731 offers a NEEDINFO extension for BZ >=4.2 that is flagged-based (contrary to a NEEDINFO *status*).
This went live a week ago.

Advantage compared to a NEEDINFO *status* is that you can explicitly set the flag against a specific user/account that is expected to provide information.

You can see it in production in bugzilla.mozilla.org for product=Firefox and component=Untriaged if you are member of the canconfirm group. Assuming that not everybody here is, I'll attach two screenshots (setting the flag, and how the report looks afterwards).

Potential problem with this approach is that there is no indication in buglist.cgi about a bug report's "missing enough information" status (so developers might still open a report though it's not in a useful state yet).
In order to exclude such NEEDINFO tickets, a query has to set "flags | contains all of the strings | needinfo?" under "Custom Search" on query.cgi.

I also haven't completely understood the semantics yet. Going to add a comment here once my questions have been answered by the Mozilla folks.

Attached:

My open questions have been answered:

<glob|away> andre, if you try to set needinfo to + or -, it'll change that to just clearing the flag
<andre> and I can set "needinfo?" again if provided info was insufficient?
<glob|away> andre, yes
<glob|away> using the ui near the comment box is identical to setting the flag and requestee via the normal flag controls

So I recommend considering this extension after a 4.2 upgrade.

Extension in comment 7 depends on BZ 4.2, hence adding dep on bug 33158.

Pasting the log from the Bugzilla/Bug management IRC Office hour in #wikimedia-office IRC here:

<andre> so, whoever is in the mood for discussing: Another interesting idea might be to introduce a NEEDINFO bug status, when there is information missing from the reporter. This is https://bugzilla.wikimedia.org/show_bug.cgi?id=36064
<andre> and I was told that at least the Language Engineering team would like to have a way to tag bug reports as "needs more information" or "stalled".
<andre> some Bugzilla have such a status (like GNOME and KDE), other Bugzillas (Mozilla) use a so-called "flag" (a dropdown) for that.
<andre> ...but I guess I'll need to ask some more teams to decide whether to do that or not, vs. making things more complicated by adding yet another status. (Though adding it as a status would be very easy, technically)
<sumanah> My vote: do what makes sense to you. You own this. :)
<MatmaRex> andre: wouldn't UNCONFIRMED fit?
<andre> MatmaRex, hmm, that's an interesting idea - does "unconfirmed" mean that it's not clear whether the issue exists and whether it's a real "bug" in our code / setup, or can it also mean "nobody else has seen this problem yet" or "not enough info yet or anymore to confirm it"?
<andre> lately I prefer the latter interpretation, but I'm probably a minority.
<MatmaRex> andre: i think it's a bit of both
<MatmaRex> but i rarely see it used
<andre> MatmaRex, also, "Please retest this after these changes" would mean to reset it to UNCONFIRMED?
<andre> it's an interesting idea.
<MatmaRex> i'd say it means that no one apart from the reporter confirmed it - ie, non-reproducible
<MatmaRex> (or not reproduced yet)
<MatmaRex> it might also mean that no one (yet) agreed with the reports whether the subject of the report is actually an issue
<lizzard> MatmaRex: my question is usually, well, i can reproduce it , but am still not sure if it is our bug, or someone else's bug
<MatmaRex> lizzard: i'd say that's not UNCONFIRMED, just a bug, possibly one that should get an 'upstream' keyword once it's figured out on our side

• MatmaRex 's not a bugmeister, though.

<andre> MatmaRex, on the other hand, NEEDINFO means "stalled" or "needs info from somebody before anything else can be done". That doesn't feel like UNCONFIRMED to me.
<andre> Still the question "Can UNCONFIRMED be used for what NEEDINFO is in some other bugtrackers?" is something really good to think about
<sumanah> Right now, the moment a person shows up with a new bug, it's at UNCONFIRMED. Unless we're going to switch that to something else, it's better to have something else that means WE SPECIFICALLY NEED MORE INFO FROM YOU. BLOCKED OTHERWISE.
<sumanah> YES WE LOOKED AT IT. PLEASE REVISE.
<MatmaRex> hm, good point.
<andre> (it's only UNCONFIRMED on enter_bug.cgi if you don't have editbugs permissions, otherwise the dropdown defaults to NEW)
<sankarshan_CPU> usage of Unconfirmed is "Bugs with the "Unconfirmed" keyword have been entered into Bugzilla but not yet confirmed by Development that an actual bug exists."
<sumanah> For searches, and for a skim down a list of bugs, we won't be able to tell "oh this would be NEW except the person's unprivileged"
<sankarshan_CPU> https://bugzilla.redhat.com/describekeywords.cgi
<sankarshan_CPU> (as an example)
<sumanah> so that's a keyword, over there in RedHat land. :)
<andre> sankarshan_CPU, uh, RedHat has a keyword for that, instead of a status? interesting.
<sumanah> https://bugzilla.wikimedia.org/describekeywords.cgi includes "testme - This bug needs to be re-confirmed to check if it is still present in the latest alpha version of MediaWiki."
<sankarshan_CPU> http://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow is the one from Fedora land .. andre__
<andre> yeah, but testme is a more general keyword for "old stuff that should be retested" but there's no indication that a developer couldn't pick it up and fix it - it's not necessarily asking a specific person for more information like NEEDINFO would be.
<andre> sankarshan_CPU, thanks
<sumanah> you're right andre__
<sumanah> ok, so it sounds like andre__ needs to do a little checking of other Bugzilla installations, make a decision, & implement it :)

Just to clarify: NEEDINFO status/needinfo flag doesn't mean "WE SPECIFICALLY NEED MORE INFO FROM *YOU*." Take the recent JS minify vs. licence information for example: Perhaps information may be needed from the reporter of such an issue. But it may also wait for an answer from the JavaScript team (if such exists). Or from the legal department. Or from the FSF. Etc.

So you need to be able to specify any other Bugzilla user as the blocker, and each Bugzilla user must be able to query "all issues where I'm (my department is) listed as blocker".

(In reply to comment #11)

Just to clarify: NEEDINFO status/needinfo flag doesn't mean "WE SPECIFICALLY
NEED MORE INFO FROM *YOU*."

Correct, but the addressee can be expressed in an additional comment. Setting NEEDINFO without a comment would be cryptic and not recommended anyway.

for example: Perhaps information may be needed from the reporter of such an
issue. But it may also wait for an answer from the JavaScript team (if such
exists). Or from the legal department. Or from the FSF. Etc.

Sure, you'd need guidelines. In most Bugzillas I've been active in the rule was to use a NEEDINFO status *only* against the reporter. If you wait for an answer from the JS team, you could assign the report to the JS team.

So you need to be able to specify any other Bugzilla user as the blocker, and
each Bugzilla user must be able to query "all issues where I'm (my department
is) listed as blocker".

Is the latter possible in the needinfo flag extension which is enabled on bugzilla.mozilla.org? I don't think so, and I don't plan to work on extending the functionality of that extension.

(In reply to comment #12)

(In reply to comment #11)

Just to clarify: NEEDINFO status/needinfo flag doesn't mean "WE SPECIFICALLY
NEED MORE INFO FROM *YOU*."

Correct, but the addressee can be expressed in an additional comment. Setting
NEEDINFO without a comment would be cryptic and not recommended anyway.

Hello, This would be an extremely helpful feature for the Language Engineering team. In our workflow we have to communicate with a widely distributed group of volunteers regularly about requests related to language features filed by them, which often needs cross-referencing from other contributors of the same or related languages. At present, we need to followup outside of bugzilla to get the attention of people whose feedback is a blocker for us (e.g. language related specifics) to proceed in solving the bugs. Thanks.

Playing locally with the bmo extension (not a Bugzilla upstream extension!) created to fix https://bugzilla.mozilla.org/show_bug.cgi?id=778731 :
After checking out

bzr co bzr://bzr.mozilla.org/bmo/4.2/

and copying

extensions/Needinfo

to

/usr/share/bugzilla/extensions/

one has to go to

https://localhost/bugzilla/editflagtypes.cgi

to enable the flag for specific products and components.

This (global) interface is very similar to the interface for the ComponentWatching (on a per-user level), and as with any other flag, Grant and Request Groups can be defined.

The flag is however displayed in the "usual" area for flags (upper right) without the convenient dropdown offering choices who to needinfo "against" (e.g. "reporter"), not below the comment field as on Mozilla or Redhat Bugzilla. Furthermore, "[NEEDINFO]" is not displayed behind the status in static_bug_status.

This is not as expected, not sure yet why.

<div id="needinfo_container">

should get inserted on show_bug.cgi between

<div class="knob-buttons">

and

<table id="bug_status_bottom">

but that's not the case in my local test instance. I don't understand yet where in the extension code the exact spot to insert into show_bug.cgi is defined.

Yeah, same problem on the Labs instance which can be seen on http://boogs.wmflabs.org/show_bug.cgi?id=2 when being logged in. So it's not my local machine, but maybe something with our skin customizations.

From the Wikidata side: I'd like this to be a status as when a bug needs further information there is nothing I can do about it and it is not actionable like a new or reopened bug.

Whoah, at least one thing that worked out a bit today:

After finally seriously(TM) reading (and understanding!) https://wiki.mozilla.org/Bugzilla:Writing_Extensions and the related API docs && reading the Needinfo extension code *closely* && checking the Hooks called in there and where they are in the Bugzilla core code && diff'ing related files against both bugzilla.mozilla.org-4.2 code and Bugzilla-upstream-trunk code:

The code merged into upstream 4.4 in http://bzr.mozilla.org/bugzilla/4.4/revision/8484 is also in bmo 4.2 (but not upstream 4.2).
Just backporting changes in Bugzilla/Bug.pm and Bugzilla/Hook.pm does not seem to be enough (tested on boogs.wmflabs.org), plus http://bzr.mozilla.org/bmo/4.2/changes?filter_file_id=needinfo.html.tmpl-20120917153628-850vrsl12som4lsz-9 has quite some changes, plus I don't plan to diff bmo4.2 code too much against bugzilla4.2 upstream.
So we should probably just upgrade to 4.4 (bug 49597) first.

I had no luck with a local 4.4 instance either, hence I checked for existance of hooks used (by looking at the filenames in /extensions/Needinfo/template/en/default/hook/):

$:andre\> cd ./bmo-42upstream
$:andre\> grep -r "after_comment_commit_button" .
./template/en/default/bug/edit.html.tmpl:

[% Hook.process("after_comment_commit_button", 'bug/edit.html.tmpl') %]

$:andre\> cd ../bugzilla-44upstream/
$:andre\> grep -r "after_comment_commit_button" .
$:andre\>

So that was the issue for this extension.

Adding the line
[% Hook.process("after_comment_commit_button", 'bug/edit.html.tmpl') %]
in
https://git.wikimedia.org/blob/wikimedia%2Fbugzilla%2Fmodifications.git/fa11f483cd98b49578db9924f576d65fc258a989/template%2Fen%2Fcustom%2Fbug%2Fedit.html.tmpl#L1109
finally made this work as expected.

test editing bug after deploying

https://gerrit.wikimedia.org/r/#/c/114168/

which is the hook to start making this possible

As I do not want to judge the pros and cons of a flag vs a status myself, I have created https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle/Need_more_info with pros and cons of each implementation. I'll have to bring this up to a broader audience, probably wikitech-l@.

Is this feature something we still want in Phabricator? Should we have a Whiteboard of open Bugzilla requests that should be fixed by/for Phabricator?

(In reply to Quim Gil from comment #22)

Is this feature something we still want in Phabricator? Should we have a
Whiteboard of open Bugzilla requests that should be fixed by/for Phabricator?

What's the Phabricator way to mark an issue as being blocked by the need for information from someone?

(In reply to Quim Gil from comment #22)

Is this feature something we still want in Phabricator? Should we have a
Whiteboard of open Bugzilla requests that should be fixed by/for Phabricator?

Yes on this feature request at least. (my opinion)

(In reply to Tim Landscheidt from comment #23)

What's the Phabricator way to mark an issue as being blocked by the need for
information from someone?

It doesn't have an explicit status either (ie: it's similar to Bugzilla). It might be modifiable though. But I'm not sure of how hard it is to do so.

Phabricator allows admins to define different types of statuses through the GUI at /config/edit/maniphest.statuses/

Unassigning - we're moving from Bugzilla to Phabricator and we will have a corresponding "Needs info" status there, see https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla#Bugzilla_data_migrated

In T38064#776423, @Aklapper wrote:

Wikimedia has migrated from Bugzilla to Phabricator.
Hence closing this as declined.

In Phabricator, we have a "stalled" status (see T212) so this is fixed in Phabricator terms.

I don't see how. If I edit this task, I can only set the status to "Stalled", but there is no way to specify who needs to provide information for the task to be resolved.

You can explain that in the task description and/or the last comment.

In T38064#777589, @Qgil wrote:

You can explain that in the task description and/or the last comment.

What is Phabricator's syntax for that? Also, if someone adds another comment, will that task still show up in the dashboard of the user who needs to provide information?