Add a confirmation step when setting the bug status if the user is not a bug contributor

[Eleanor Berger]

When a user who isn't a bug contributor tries to set the status of a bug, they should be prompted to confirm their choice. This will hopefully help reduce the frequency of users setting the wrong status by mistake.

[Martin Pool (mbp)]

How is 'bug contributor' defined? Is the reporter (or dupe reporters) included or not?

I think for users who are active bug filers but not members of the project team this could get annoying after the first 20 instances and they will want a 'Don't ask me again' tickbox.

> you can cancel and instead contact the project team
.. but it's not obvious from this page how they can contact the project team. Perhaps they should be invited instead to post a comment?

This dialog doesn't really help people understand whether they're doing the right thing, just saying a bit generically "be careful." Perhaps eventually it would be better to explain the meaning of the transition, eg "I've provided the requested information": incomplete->confirmed.

[Eleanor Berger (intellectronica)]

> This dialog doesn't really help people understand whether they're doing the right thing,
> just saying a bit generically "be careful."

True, but that's pretty much what we wanted to achieve. Project teams started complaining, after the introduction of the inline status editor, that users are not careful enough and tend to change the status inappropriately more often now that it doesn't require the extra submission step.

I agree that this could be refined, but I also feel that this really does exactly what we wanted to achieve - make it a bit harder to change the status if you're not bug supervisor or owner.

[Deryck Hodge (deryck)]

Like Tom, I agree this could be refined, but I also think it's a good first step.

Martin, 'bug contributor' is defined as anyone who has ever been assigned a bug in the project. So it does not take into account any triaging work. Do you have active bug triaggers who don't ever assign themselves bugs, too? i.e. do you think this will become a problem in practice?

[Martin Pool (mbp)]

I don't want to get in the way of taking a good first step, especially if it's been specifically requested by users.

> Martin, 'bug contributor' is defined as anyone who has ever been assigned a bug in the project. So it does not take into account any triaging work. Do you have active bug triaggers who don't ever assign themselves bugs, too? i.e. do you think this will become a problem in practice?

Yes, we do, and I'm also often in that role myself on Ubuntu or other projects. It seems like just a very normal thing on Launchpad that you will eg change a bug from incomplete to confirmed when you provide the requested information, without ever being assigned bugs on that project.

Also some projects may just not use assignment.

I think we need a model of what is going wrong here:

0- people are trying to make a valid change, and simply clicking the wrong menu item
1- users are intentionally misbehaving, like insisting on reopening a bug that the developers have said they wontfix -- this may not help much
2- users are well-intentioned but clueless: they do mean to change the status but they don't know how they should change it -- this may make them think twice but some will steam ahead; those who are not overconfident probably aren't clicking it already
3- people are just accidentally clicking that control while trying to do something else, then randomly clicking around to escape
... more

Case 1 and 2 do happen, but won't have been particularly exacerbated by the ajax status chooser, except in that by making it faster we might have made impulsive actions easier.

I do think 0 is a problem, because I misclick on the status chooser fairly often myself. This can affect real developers as much as it does novice users, except that experienced users might learn to be more careful. Adding a confirmation step seems like a bit of a kludge if this is the main problem - you might as well just turn off the popup and let people use the fold-out form.

If this is in fact the problem there are several things you could do to address it. For example in that menu, the current item is always disabled (???) which is inconsistent with normal popup menus, and means that if someone unintentionally opened that menu, it's a bit harder for them to escape from it without making a change. The fact that the label doesn't update for several seconds after you make a choice may cause confusion. Also it looks like (?) every change causes mail to be sent, with no batching, which may make misclicks appear more noisy.

[Ursula Junque (ursinha)]

Fixed in stable r10577 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/10577>

[Martin Pool (mbp)]

I saw bug 164196 touched recently and basically that's one thing I
would suggest fixing instead of this, to see if it alleviates
developer pain.

You probably know there's a lot of research showing that confirmation
dialogs aren't very good at preventing mistakes, especially if they're
always present on common actions.

--
Martin <http://launchpad.net/~mbp/>

[Deryck Hodge (deryck)]

Martin, I agree if we don't spam people about the toggled state, it's probably not as much of an issue. And maybe at that point we can remove the confirmation dialog. I think we could also implement a gmail-like "undo" action link.

I also do realize research exists (and personal experience suggests) that people just blindly click through. We should know soon if this doesn't help, and if so, we can remove the pop up.

Cheers,
deryck

[Scott Kitterman (kitterman)]

The original request was to revert the ajax status change. If confirmation isn't going to solve the problem, then that should get considered.

[Martin Pool (mbp)]

See bug 549323 for objections to this.

--
Martin <http://launchpad.net/~mbp/>

[Deryck Hodge (deryck)]

We have discovered some issues with the implementation of this confirmation dialog, which is forcing us to revert the branch. I still want us to move ahead with some form of a confirmation dialog, which we will land week 1 of the next cycle to have plenty of time on edge to make sure it works in a way that is right for both Ubuntu devs and others.

The main problems forcing this to be reverted are that the confirmation dialog didn't consult isBugContributorInTarget effectively meaning everyone gets the confirmation dialog regardless of their involvement with a project. This needs to happen before the change can land again, and I also think we should have a bit more than this, too. If a user has over X amount karma (500?) we should allow them to change a bug status. Perhaps, too, we should consider what status is being requested, i.e. if the user is toggling to in progress.

We should discuss pros and cons of any extra constraints here before settling on an implementation. I realize this adds complexity, but I think some additional checks are required. We want to make new users think carefully about what they're doing, without getting in the way of experienced users of LP.

Also, ScottK, your request to remove the AJAX widget has been noted and considered, but this is one of those cases where the needs of all LP users has to be considered. While there are "many" who dislike the new status change, there are just as "many" who like the convenience it provides (for some unquantifiable definition of "many") :-) I am also confident we can find a way to prevent needless status toggling without removing the widget.

Cheers,
deryck

[Martin Pool (mbp)]

On 30 March 2010 00:18, Deryck Hodge <email address hidden> wrote:
> We should discuss pros and cons of any extra constraints here before
> settling on an implementation.  I realize this adds complexity, but I
> think some additional checks are required.  We want to make new users
> think carefully about what they're doing, without getting in the way of
> experienced users of LP.

Perhaps it would be good to do a LEP about this, then we can be clear
about the actual requirements, proposed solutions, tradeoffs, etc,
before getting code?

--
Martin <http://launchpad.net/~mbp/>

[Deryck Hodge (deryck)]

Sorry it took some time for me to get back to this.

I talked to Steve Langasek who reported the original bug 412925 today. While there are still some occasions when a status is changed and has to be reverted, the situation has improved now. We should consider ways to make this experience better when we work on improving UI/usability issues around the bug page. Steve notes that, in general, Ubuntu developers would prefer a solution that encourages commenting when changing statuses, which we can certainly consider again at a later date. I don't think the problem is so severe that we need to resort to confirmation dialogs at this point.

I realize some will be disappointed in this decision, but I think it's the best use of Launchpad bugs team developer time at this point. I'm marking this bug won't fix, which means we are abandoning work on adding this status-change confirmation dialog.

Cheers,
deryck

[Martin Pool (mbp)]

another related bug 561231 - the currently selected state is disabled
in the menu (again inconsistently with a regular pulldown menu.)