We could try to have packagers put the ASSIGNED status as a means to confirm that the bug was rightly assigned, indeed (not sure if they would do it, but why not).

However, this will prevent them from differentiating bugs they are working on and bugs that are for later.

As packagers can still assign back to triage team when we're wrong (there should be an easy way to do it, by the way, currently the only way I found is put the exact e-mail adress in the Assignee field), I'm not sure that in the end this would improve the situation.

I think we'd better ping maintainers when the bugs assigned to them have been waiting for too long.

CC: (none) => stormi

Or when assigning, add a comment: "please confirm assignment was right" and put the weeknumber in the whiteboard field. At the start of week (weeknumber +2) we could start nagging those who did nor confirm, nor assign back

(In reply to comment #1)
> We could try to have packagers put the ASSIGNED status as a means to confirm
> that the bug was rightly assigned, indeed (not sure if they would do it, but
> why not).
>

Why don't we ask them?

 
> However, this will prevent them from differentiating bugs they are working on
> and bugs that are for later.
> 

Can they use the whiteboard, too?

What about introducing another state, say "ON_WORK", so when a bug is correctly assigned to the maintainer he can change it to ASSIGNED and then when he really starts to work on it can change it to ON_WORK or whatever it's named.

That way both cases are filled, right ?

CC: (none) => juan.baptiste

(In reply to comment #4)
> What about introducing another state, say "ON_WORK", so when a bug is correctly
> assigned to the maintainer he can change it to ASSIGNED and then when he really
> starts to work on it can change it to ON_WORK or whatever it's named.

Do we really need a special status to say someone is working on it ?
If the maintainer is working on it and can fix it quickly, he'll close the bug as resolved. If it cannot be fixed quickly he'll post a comment to explain why, showing that he's working on it.

CC: (none) => boklm

If it is needed Juan's idea would be nice

If it is not needed, than why do assignees wait to set the status to "ASSIGNED" until they start working on it

I think we could have the following meanings for NEW and ASSIGNED :

- NEW: it is not yet clear if the bug is valid, and who will be working on it. Triage team keep a search on NEW bugs, and try to find the right maintainer for those bugs.
- ASSIGNED: bug has been assigned to the known maintainer of the package, or there is no known maintainer but someone took the bug and plans to work on it. Triage team can forget about this bug.

I don't think we should have a status to say "I'm working on it" or "I'm not working on it", because I don't really see what would be the use of this status.

@ Nicolas

Great, if everybody agrees. I'll add D.Morgan to the cc, IIRC his point of view is different.

CC: (none) => dmorganec

(In reply to comment #7)
> I think we could have the following meanings for NEW and ASSIGNED :
> 
> - NEW: it is not yet clear if the bug is valid, and who will be working on it.
> Triage team keep a search on NEW bugs, and try to find the right maintainer for
> those bugs.
> - ASSIGNED: bug has been assigned to the known maintainer of the package, or
> there is no known maintainer but someone took the bug and plans to work on it.
> Triage team can forget about this bug.
> 

Then we don't need 2 different status, triage team already makes a difference between bugs assigned to bugsquad@mageia.org and those assigned to someone else. Changing the status to ASSIGNED would be tedious. 

I don't think triage team needs to care about the ASSIGNED status. The maintainer can choose to use it or not to show he/she is working on the problem. A simple comment can do also. 

For triage team, who cares not only about bug assignment but also about having bugs fixed, I think that the fact that many bugs assigned to a maintainer never get a "ok, I'll handle it" confirmation from the maintainer is a bigger problem, which is what the ASSIGNED status could be used for. Then triage team could ping maintainers who didn't show that they are going to handle the bug, after some time. However, we can do it without an ASSIGNED status too, provided we have a means to measure the delay since the day the bug was assigned and have reports about it in bugzilla.

(In reply to comment #9)

> 
> For triage team, who cares not only about bug assignment but also about having
> bugs fixed, I think that the fact that many bugs assigned to a maintainer never
> get a "ok, I'll handle it" confirmation from the maintainer is a bigger
> problem, which is what the ASSIGNED status could be used for. Then triage team
> could ping maintainers who didn't show that they are going to handle the bug,
> after some time. 

That's how I understood Nicolas' comment, although I admit he left a few words out ;)

> However, we can do it without an ASSIGNED status too, provided
> we have a means to measure the delay since the day the bug was assigned and
> have reports about it in bugzilla.

Don't be fooled by our long list of triagers. In fact, we are very, very short on triagers. 
A week ago, from the people on that list, only Manuel, Thierry, Remco and me were in the cc of more than 50 bugs reports.

PLease give us an easy way to know fast whether we assigned correctly or not. If it can't be the ASSIGNED status, maybe an ACCEPTED status would be OK?

(In reply to comment #10)
> 
> PLease give us an easy way to know fast whether we assigned correctly or not.
> If it can't be the ASSIGNED status, maybe an ACCEPTED status would be OK?

Maybe we can say that no answer means the bug is correctly assigned, and if you get a bug incorrectly assigned to you, you should reassign it to bugsquad (with a comment to explain).

(In reply to comment #11)

> Maybe we can say that no answer means the bug is correctly assigned, and if you
> get a bug incorrectly assigned to you, you should reassign it to bugsquad (with
> a comment to explain).

:D
No answer means it is correctly assigned, even if it isn't. 
Thanks for you pragmatism. 

Do all (new) maintainers know they can reassign?

For now, Nicolas' pragmatic solution seems the best.

I know there are maintainers who use the "ASSIGNED" status to control their own workflow. Everybody's workload is so big atm, it would not be good to take away this tool from them now.

I would like to discuss this issue again later, when workloads have decreased to a comfortable level. If it were possible, I would now set the milestone for this bug to Mageia 3, but that isn't possible yet.

If no more comments are added, I'll close this bug as WONTFIX (and maybe reopen after Mageia 2 is released :p)

I commented on IRC before reading up on this bugreport... but I'll repeat some comments I made there:


<remmy> Maybe ASSIGNED should be called SELF ASSIGNED
<remmy> Then all ambiguity is gone
<remmy> Or have TRIAGED as a status instead as a keyword that's not used

In that latter case, a bug goes from NEW to TRIAGED to possibly (SELF) ASSIGNED when the maintainer accepts being the assignee. That way bugsquad can also see what bugs have been TRIAGED and assigned to someone but to which no further action was taken since.

CC: (none) => remco

I like the idea of adding the TRIAGED status as Remmy suggests.
Then the ASSIGNED status would mean that it has been accepted, or that it is being actively worked on, depending on the preferences of the assignee.
That way, something classified as TRIAGED could be taken by someone else if it is an urgent bug.

But Nicolas' approach is ok for me.
Except I will try to make a point of responding to bugs assigned to me, to remove possible ambiguity as to whether I'm aware of the assignment.
The assignee could be temporarily unavailable for whatever reason.

CC: (none) => andre999mga

My position here will be: do nothing for now, ie keep *not* putting the ASSIGNED status when assigning to the maintainer (and let the maintainer use it if needed), and include the future decision in a broader worflow definition.

That of fedora looks good, for example: 

https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow

(In reply to comment #16)
Waiting for the moment sounds good to me.  Leaves time for reflection on the bigger picture.

The fedora policy looks really comprehensive.  They cover all the bases, even letting the maintainer(s) decide whether or not to use certain statuses.

On the french forum I have see that the 'new' status means for them, that nothing was done for the bug.

(and maybe that's why ahmad add the keyword 'triaged' but personally I don't like that)

So I am agree with comment 14, 15, 16.

(In reply to comment #18)
> On the french forum I have see that the 'new' status means for them, that
> nothing was done for the bug.

> 
> So I am agree with comment 14, 15, 16.

It would be really good, if we could have a TRIAGED status, to show we finished triaging and are now (or asap) assigning it to someone to solve the issue

Are we allowed to use the ASSIGNED status for ourselves, for the Bug Squad, to set when, at first sight of a bug, we can't dismiss it as a duplicate or user error and we think it should be further triaged by the bug squad?

Like bug 1537:
It was filed on 2011-06-03
No one ever commented on it. 
It isn't a duplicate of a bug. 
I can't (yet) try to reproduce the bug because I'm totally unfamiliar with DocBook. 

I think it looks like a genuine bug that should be further triaged. It would be nice to show that to the reporter by setting the status to ASSIGNED, so he won't feel we ignore his report.

Adding a new bug status doesn't necessarily help maintainers fix their bugs faster. :) If assignees do not use the new bug status as you wish, this just make things harder to manage. For you information, Bugzilla 4.0 renamed NEW as CONFIRMED, and ASSIGNED as IN_PROGRESS to better reflect what they mean (Mageia's Bugzilla won't be affected as these new bug statuses are only for new installations, not for those which are upgrading).

There are two things which could help the triage team:

1) Pester maintainers to triage bugs assigned to them. Bugzilla has a whining system which works as follows: whineatnews.pl can be run as a cron job (e.g. once a week) and it will send an email to all assignees who didn't touch their bugs in the last X days, where X is configurable from the Parameters page. Only bugs left with status NEW and REOPENED are concerned. If assignees complain about these weekly emails, tell them to either reassign their bugs to squad, or change the bug status to ASSIGNED (the whining system doesn't pester about bugs with the status set to ASSIGNED). This is a nice way to force them to triage bugs assigned to them.

2) You can query for bugs which haven't been touched by their assignee in the last Y days. For instance, to get all open bugs in the Mageia product where the assignee didn't do anything in the last 15 days:

https://bugs.mageia.org/buglist.cgi?emailassigned_to1=1&query_format=advanced&field0-0-0=owner_idle_time&email1=bugsquad%40mageia.org&type0-0-0=greaterthan&value0-0-0=15&resolution=---&product=Mageia&emailtype1=notequals

If you are curious to see how I did it, simply click the "Edit Search" link at the bottom of the list, and you will see which fields I filed. This is another good way to keep track of inactive bugs.

CC: (none) => LpSolit

@ Frédéric

Thanks for your comment and for the search example (I wouldn't have managed to figure out how to do that)

I like your proposal, but I know there are maintainers who use the "ASSIGNED" status to control there workflow, that is, they don't set a bug to that status before they actually start working on it. They would panic when they were forced to set the status to ASSIGNED as soon as they have triaged that the bug was assigned to them correctly

I'm confident you have something better for them to control their workflow :)

Closing, because Stormi's new workflow will take care of this.

(And it can of course be reopened if that takes too long ;) )

Status: NEW => RESOLVED
Resolution: (none) => OLD