bugs can be closed with no explanation

[Rolf Leggewie]

Setting the status of a bug ticket to Invalid, Opinion, Fix Commited or Fix released should require a comment. Otherwise it's impossible to verify that change later. Quite a few tickets get closed accidentally (possibly by scripts where there is an error in the number). Have a look at bug 425112 for a (not so terribly important) example.

[Robert Collins (lifeless)]

That example you give was closed by the bug filer. I rather think that the bug filer at least is entitled to just revoke the ticket they opened ;)

Anyhow, this is a reasonable point to consider, but we need to be careful not to break or diminish usability while adding constraints like this.

[Martin Pool (mbp)]

Having just seen another bug accidentally set to 'Opinion' I think
there might be something to this.

Launchpad already has some kind of concept of users who are active in
a project. Perhaps if someone who's not already involved with the bug
or any of the related projects changes the status or other metadata we
should ask them "are you really sure?"

Martin

[Rolf Leggewie (r0lf)]

Why not require a comment from everyone, regardless of their privs, role or karma level? It's not too much of a burden, I'd say and it greatly helps everybody else to understand why the ticket was indeed closed.

[Martin Pool (mbp)]

On 12 September 2011 18:07, Rolf Leggewie <email address hidden> wrote:
> Why not require a comment from everyone, regardless of their privs, role
> or karma level?  It's not too much of a burden, I'd say and it greatly
> helps everybody else to understand why the ticket was indeed closed.

A few overlapping things:
 * some people garden a huge number of bugs, sometimes now without any
message - this would be a regression for them. an illustrative case
is that i have just undone some noise edits and doing so would have
been extra annoying if i had to enter placeholder text.
 * this would be reduced if there was a quicker ui to add both text
and a status change at once; at the moment changing just status is
substantially faster; making it easy may make people comment more
 * requiring a comment is a good way to get comments like '.'
 * i don't know if requiring a comment will really make these users think twice

Possibly we can use flags to experiment with it.

Let's not overdesign it before someone's actually ready to work on it.

[Robert Collins (lifeless)]

Asking someone if they are sure would be a step towards addressing 'users close bugs they shouldn't', vs 'bugs can be closed without an explanation'. If you are seeing the wrong bug being closed as a thing, please file a bug about that.

[Rolf Leggewie (r0lf)]

I'm not sure I fully understand Robert's last comment. I'm the OP for this ticket, so I hope you will grant me to explain my POV.

For me, this is mostly about being able to come back to a ticket and understand why somebody else closed it. Discouraging users from closing bugs they should not is not my focus, that should be done by granting them the right privilege level. I'm absolutely with Martin on "do not overengineer this" and that's why I think that trying to discern between active and inactive users is way-over-the-top engineering.

Think about a source code repo. Any good project will require you to have a meaningful commit message. Same thing here, if you close a ticket, say why you did it. And it's easy enough even when using scripts to mass-handle bug tickets, I do this myself from time to time. In fact, I want a comment especially in the case of mass-handled tickets. A short comment such as "closing all breezy tickets" or something like that shouldn't be too much of a burden. But it allows to verify later on if a ticket was closed in error.

[Matthew Paul Thomas (mpt)]

Bugzilla required (I don't know whether it still requires) a comment when closing a report. A common result -- it's happened 3959 times so far, in Mozilla's Bugzilla -- has been someone resolving a bug with "." as the entire comment. (I suggested imposing a minimum length on the comment, but that was rightly seen as worsening an annoyance.)

The main interface for changing a bug's status is now the direct-manipulation interface -- click the old status, then click the new status in the menu, and you're done. It is miles away from the comment form. So introducing the requirement to comment would require some design work. One case to consider would be where you comment to explain why you're resolving the report, but forget to actually mark it resolved, and then resolve it properly 30 or 40 minutes later. How would Launchpad tell that you didn't need to add another comment?

[Robert Collins (lifeless)]

So, all things considered, I think this would be a mistake. Hoops that folk have to jump through don't increase usability; the most friendly way to increase clarity of communication would be to make it easier to add comments.