new ajax interface for changing bug statuses is too easy

[Steve Langasek]

Over the past month, I've noticed a large number of bug reports getting their status changed to random values by people with no reason to touch the status at all, often resulting in the status of "fix released" bugs being reset. Discussing with folks on IRC brought to my attention that this coincides with the roll-out of a new ajax feature that I hadn't noticed up to now, which lets users change bug status with two clicks.

This is too easy of an interface.

Previously, users were always at least encouraged to comment when changing bug statuses, by virtue of the comment field above the 'submit' button. Now, with two clicks users can change a status and scarcely realize they've changed anything.

Colin Watson suggested on IRC that having an ajax 'comment on this change' box following the status change, and before submitting, would be enough to curb this problem. If that's not suitable, I think it would be better to disallow these new ajax status changes altogether.

[Eleanor Berger (intellectronica)]

We do indeed plan to add the option of commenting on the change after it's made, but it probably won't be compulsory. I don't think that the solution to this problem is making the interface harder to use. Instead, we should consider how to:

1. Discourage people who don't have the required information from changing the status of a bug.
2. Discourage people from clicking randomly (this might happen with time anyway, if the reason people are changing the status is that they wanted to try the new UI).

I'm marking this bug WONTFIX for now, but by all means, let's continue the discussion so that we can improve the interface.

[Steve Langasek (vorlon)]

On Fri, Aug 14, 2009 at 12:12:09AM -0000, Tom Berger wrote:
> I don't think that the solution to this problem is making the interface
> harder to use.

Why not? The net effect of the latest change has been to create busywork
for developers, having to undo the random changes made by random people. I
don't think the previous interface was hard to use, and clearly the new
interface is far too easy to use unthinkingly. Frankly, I think this was a
case of a solution in search of a problem.

> Instead, we should consider how to:

> 1. Discourage people who don't have the required information from
> changing the status of a bug.

If you can find a way to do this, I'm certainly in favor, but I don't have
any insights on how this can be done short of making it harder to get to
that interface by accident. In the meantime, I've had to reset statuses on
probably 10 or so bugs in the past month that were changed without
explanation, vs. maybe one a month on average before that.

> 2. Discourage people from clicking randomly (this might happen with time
> anyway, if the reason people are changing the status is that they wanted
> to try the new UI).

I don't think this has much to do with wanting to try the new UI. Most of
the status changes come from people with zero karma in Launchpad, which I
don't think correlates with folks who are tracking the LP release
announcements closely, nor is it a set we're likely to exhaust any time soon
:(

> I'm marking this bug WONTFIX for now, but by all means, let's continue
> the discussion so that we can improve the interface.

I'm unhappy at having an issue marked 'wontfix' that is actively causing
more work for me (and, I assume, others) in trying to keep bad data out of
the bug database. I have no particular preference on *how* it's addressed,
but I do think it needs to be addressed.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Steve Langasek (vorlon)]

I've reset the statuses of five bugs in the past two days that have been munged by passers-by.

[Martin Albisetti (beuno)]

I've been thinking about this issue a bit.
Maybe we add an extra confirmation dialog if you're not part of the project (or a bug supervisor, etc)?

This would still keep it easy, and make random people think about it for a bit more.

[Eleanor Berger (intellectronica)]

I think an even better variant of this would be to provide an undo function, and an information message prompting the user to undo if they're not sure this was the right thing to do. That's very hard to implement, though, so a confirmation step for people who aren't project contributers will probably work.

The problem I have with it is that it will make the interaction annoying for those users who legitimately need to change the value. Ideally, I'd like to see if we can solve this problem with a tool less blunt.

[Graham Binns (gmb)]

2009/8/19 Tom Berger <email address hidden>:
> I think an even better variant of this would be to provide an undo
> function, and an information message prompting the user to undo if
> they're not sure this was the right thing to do. That's very hard to
> implement, though, so a confirmation step for people who aren't project
> contributers will probably work.
>
> The problem I have with it is that it will make the interaction annoying
> for those users who legitimately need to change the value. Ideally, I'd
> like to see if we can solve this problem with a tool less blunt.

A good way to handle this would be to do it in the same way that Gmail
does. When you perform an undoable action you're notified by an
information message at the top of the page (rather like Launchpad's
"thank you for your bug" message). Next to this is an undo link.

I'm not sure that this would be particularly annoying, as long as the
notification / undo message is well-designed and unobtrusive.

[Eleanor Berger (intellectronica)]

2009/8/19 Graham Binns <email address hidden>:
> 2009/8/19 Tom Berger <email address hidden>:
>> I think an even better variant of this would be to provide an undo
>> function, and an information message prompting the user to undo if
>> they're not sure this was the right thing to do. That's very hard to
>> implement, though, so a confirmation step for people who aren't project
>> contributers will probably work.
>>
>> The problem I have with it is that it will make the interaction annoying
>> for those users who legitimately need to change the value. Ideally, I'd
>> like to see if we can solve this problem with a tool less blunt.
>
> A good way to handle this would be to do it in the same way that Gmail
> does. When you perform an undoable action you're notified by an
> information message at the top of the page (rather like Launchpad's
> "thank you for your bug" message). Next to this is an undo link.

Yes, that's exactly what I was thinking of. The only problem is that
it's quite hard to implement right now.

[Matthew Paul Thomas (mpt)]

It may eventually be necessary to prevent people from changing the status of bug reports unless they either have an official role in the relevant project, or have met some other standard that shows they know what they're doing, for example having reported 5 bugs that ended up getting fixed in any Launchpad project.

But judging purely from personal experience, ;-) I expect that most of these changes are happening by accident rather than misguided intention. People are clicking on the value by accident, and then experiencing either bug 401683 (clicking again in exactly the same place changes the value when it shouldn't) or bug 399239 (it's not obvious how to cancel out of the popup).

So, I think this bug can be fixed in two steps:
1. Fix bug 401683.
2. Whenever someone changes a value using one of the pseudo-menus, show a pair of icon-only cancel and confirm buttons (✖)(✔) at the right end of the table cell.
    - If they click the cancel button, the cell should revert to its original value.
    - If they click the confirm button, the buttons should be replaced by a spinner, and the XHR stuff should happen.
    - If they just leave it like that and do nothing, no change should be committed.

You will need pairs of cancel and confirm buttons for inline editing of the project name and the assignee anyway, so having similar buttons for the Status, Importance, and cancel/confirm interface for milestone values would be consistent with that.

[Jonathan Lange (jml)]

mpt, I'm guessing clicking by accident, or clicking in order to figure out what the hell 'Triaged' means.

I think an Undo feature would help, but as mentioned it's quite difficult to do, and this bug is causing more work for Ubuntu developers who might otherwise be spending their time getting Skype to work for me again :)

Tom, what precisely is wrong with the suggestion in the bug description? My understanding of the code is fairly shallow, but it seems to me to be a fairly simple change that will address the problem while also helping people who actually prefer to comment on status changes.

[Deryck Hodge (deryck)]

We'll definitely plan to implement a fix for this coming cycle. I like the comment overlay idea, too, though I suspect it's a bit more work than it at first appears. In talking to beuno about it yesterday, he suggested a confirmation overlay that would be presented to people with accounts newer than a certain date range or karma lower than a certain value while preserving current functionality for people who passed that check, which actually wouldn't be too difficult.

This may be a two-stage bug fix, where we do something as soon as possible to stop the pain, and then refine to another more elegant solution in a latter branch. But certainly, it's a priority to get a fix or this.

[Scott Kitterman (kitterman)]

OK, it's been three months. What's the plan now?

[Eleanor Berger (intellectronica)]

@kitterman the bug is triaged but not currently scheduled. This is not because we don't want to fix it but simply because given the finite resources we have and the many bugs we have to tackle, we've had to postpone working on it for a bit. If you, or anyone else, feels like jumping in and helping prepare a branch that solves the problem, we'll be happy to help (and eternally grateful) - find one of us on IRC for a pre-implementation chat. Otherwise, we're definitely going to fix it ourselves soon.

[Scott Kitterman (kitterman)]

I ask because a previous comment said it was scheduled to be fixed in the
nextt cycle. If LP would accept a revert of this change, I'll look into
it.

[Eleanor Berger (intellectronica)]

What precisely are you suggesting to revert, the inline editing interface? The benefits of it far far far outway any inconvenience, so no.

[Scott Kitterman (kitterman)]

Just for bug status. That's the one that seems to be problematic. Bug
status cganges without comment are almost always an error.

[Eleanor Berger (intellectronica)]

I don't think this is the case. We often change status without commenting. I think that the right solution is one of the following or both:

1. Prompting for a comment after a metadata change.
2. Requiring confirmation from users who are not regular bug contributors.

[Scott Kitterman (kitterman)]

OK. In Ubuntu it's almost never correct. That's certainly more complexity
than I'm up for attempting.

[Eleanor Berger (intellectronica)]

With the release of the update to the lazr widget we closed this bug, but there's more work coming on adding a confirmation step, which is covered by bug #531963.

[Scott Kitterman (kitterman)]

What was fixed?

[Eleanor Berger (intellectronica)]

Sorry not being more explicit, Scott. This bug really only covered some of the work, namely making the widget pop up in a position that places the mouse cursor above the currently selected item, so that users don't accidentally choose a new option. That's definitely not the complete fix, we only closed this bug (and opened a new one for the rest) because this part of the fix landed in time for the 10.02 release and the rest missed it. That's mostly complete, and will land very soon (follow bug #531963 if you want to be notified when we consider that fixed too).

[Scott Kitterman (kitterman)]

That's a reasonable first step. Thanks.