launchpad-dev team mailing list archive

["Christopher M. Penalver" <christopher.m.penalver@xxxxxxxxx>]

Hello. I wanted to start with a email to the list versus rushing to file 
a Wishlist report against Launchpad Itself to see if others have noticed 
this, discover if something is already in the works to address, and 
reveal other issues.

The problem?

I've observed for at least seven years (as long as I've had a Launchpad 
account) that many non-original reporters who are not familiar with 
Launchpad typically make comments, but don't provide anything useful for 
a developer to address the issue.

The user logic flow:
-> User searches their problem and finds a Launchpad URL, or receives 
email about a PACKAGE (Ubuntu) bug report they have commented on, marked 
themselves affected, and/or are subscribed to, and are not the original 
reporter.
-> User is unfamiliar with Launchpad.
-> User replies to email or goes to Launchpad and comments, but writes 
in a way that provides little or no helpful information (i.e. logs) for 
a developer to fix any problem.

A recent example demonstrating and not to embarrass/witch-hunt:
https://bugs.launchpad.net/xorg-server/+bug/1278223/comments/92
https://bugs.launchpad.net/xorg-server/+bug/1278223/comments/93

The same commenter has been asked to file a new report before in 
https://bugs.launchpad.net/xorg-server/+bug/1278223/comments/78, but the 
email could have been placed in Junk/Spam and missed.

Problem impact?

+ It wastes triaging time requesting folks to file a new report.
+ It clutters reports with unrelated comments that have nothing to do 
with solving the original reporter's problem.
+ It prevents the actual number of bugs with quality logs to be realized 
on Launchpad.
+ The status quo conditions folks into thinking making comments without 
logs is helpful for developers to fix bugs.

What conditions is this problem correlated to?

HIGHLY
+ Comment/reply has no log attached, or no log like commentary in the body.
+ User who is not the original reporter.
+ User has not filed a bug report against the same PACKAGE (Ubuntu) the 
report they are now commenting on is about.

MODERATELY
+ User is not a member of any Ubuntu teams.
+ User has 0 Karma.
+ Making a comment after another comment that contains:
ubuntu-bug
+ User has Low or no number of bug reports against any PACKAGE (Ubuntu).
+ Making a comment after another comment which contains their name.
+ Making a comment within one/two hours of another comment.
+ Making a comment immediately after another comment from a user who is 
a member of a Ubuntu team.

What can be done about it?

It would be helpful if when the relevant conditions are satisfied, the 
following happens:
1) If they are replying to an email, Launchpad does not commit the 
comment. Instead, it sends the commenter a reply which includes a URL 
relating to the bug. This URL would note that it appears they are 
providing a comment that doesn't provide logs. It would request them to 
file a new report if they haven't done so instead of making further 
comments, and provide a suggestion to read 
https://wiki.ubuntu.com/ReportingBugs. It would then present the user 
with a link to https://bugs.launchpad.net/ubuntu/+filebug, as likely 
they don't know which package to file it against. Below this would be a 
statement that if they are a developer (e.g. upstream who doesn't use 
Launchpad much), or triager (e.g. new triager who may not be member of 
Ubuntu Bug Squad/Control) then please confirm the change by clicking a 
"Save Changes" button.

2) If the commenter clicks one of the following on the Launchpad report:
"Does this bug affect you?"
"Post Comment"
"Save Changes"
"Also afects project"
"Also affects distribution/package"
"Edit tags"
"Mark as a duplicate"
"Assigned to"

that the comment is not committed. Instead, they are swung into the URL 
noted above.

It makes sense to start with the HIGHLY correlated conditions as they 
could be utilized without implementing a probability scoring model.

However, if too many false positives are encountered (which seems 
unlikely), a probability scoring model could be introduced, which would 
include other relevant conditions.

What do you think?

- Chris Penalver
E-Mail: christopher.m.penalver@xxxxxxxxx