403474 - Private Bug drafts for quick jot-down and gradual refinement before public submission

Status: NEW

(Bugzilla :: Creating/Changing Bugs, enhancement, P4)

Description

[Philip Ashmore]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20071030 Fedora/2.0.0.8-2.fc8 Firefox/2.0.0.8
Build Identifier: 

Use case:
User installs / runs software suite ABC and notices a slew of issues/bugs they would like to report.
User logs into bugzilla and enters the 'drafts' page.
From there they can enter multiple summary/details/severity entries in a table.
When more time is available, they can (assign/look up) the product(s) these bugs relate to so that they become 'live' bugs.
They can also do a more thorough check to see if these bug 'drafts' are duplicates.

Reproducible: Always

Steps to Reproduce:
1. You have a slew of bugs to report and would like to jot them down quickly while they're fresh in your mind.
2. You don't have time to do a full (search for duplicates/find the bugzilla reference for the exact product)
3.
Actual Results:  
(Enter them / check for duplicates / find the bugzilla product reference) as quickly as you can in the time available.
If you run out of time, come back to the bug reporting task later and hope you remember most of them.

Expected Results:  
Usually some bugs are forgotten

There should be a "jotter" or "drafts" facility where you can at least capture the main details of the bugs you want to report.
The best place for this is bugzilla as you may not be using the same machine to continue your bug reporting.

The closest bug I could find to this was
https://bugzilla.mozilla.org/show_bug.cgi?id=246272

Comment 1

[Max Kanat-Alexander]

This is actually kind of a neat idea.

The drafts would be private to the individual until actually "published". This would also allow for better templating, which could be nice.

Comment 3

[Vitaly Fedrushkov]

Looks like task for Lazarus or any other browser plugin to manage not-yet-submitted web forms.

Comment 4

[Philip Ashmore]

I know what you're thinking but in this case there's no way around having space on the server for these drafts.
This is because the bug reporter may not be at the same physical machine when they want to continue working on an individual bug report. Think of bug reports involving multiple architectures.

Comment 6

[Thomas D. (:thomas8)]

Private bug drafts would be a great help not only to quickly record a number of bugs and double-check for duplicates, but also to improve the quality of each bug before publishing (double-check correctness / completeness / conciseness of STR etc, prepare & add attachments, add dependencies, associate/delimitate similar bugs etc., fine-tune proposed concepts / solutions etc.). Keeping and building the bug report online within bugzilla is a lot simpler, more versatile and efficient than relying on browser cache and individual notes on different machines.

The UI could be as simple as a checkbox like "Private Draft" to the left of the "Save Changes" buttons, unchecked by default. Check "Private Draft", then "Save Changes" to file a new bug as private draft. Unchecking, then "Save Changes" removes the checkbox for good, and the bug becomes public.
Implementation might re-use the mechanism we have for security-relevant bugs that are kept secret from the public and only accessible for the bug reporter and administrative masterminds.

Comment 7

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #6)
> Private bug drafts would be a great help not only to quickly record a number
> of bugs and double-check for duplicates, but also to improve the quality of
> each bug before publishing (double-check correctness...

...speaking of which, comment 6 is wrong about the buttons:

> The UI could be as simple as a checkbox like "Private Draft" to the left of
> the "Save Changes" buttons, unchecked by default.

... above "Submit bug" button, of course, below Security checkbox

> Check "Private Draft", then "Save Changes" to file a new bug as private draft.
...should turn "Submit bug" button's caption into "Save as draft", and vice versa for unchecking...

> Unchecking "Private Draft", then
> "Submit bug" removes the checkbox for good, and the bug becomes public.
> Implementation might re-use the mechanism we have for security-relevant bugs
> that are kept secret from the public and only accessible for the bug
> reporter and administrative masterminds.

Something along those lines. Comments / Other ideas?

Comment 8

[Thomas D. (:thomas8)]

Can somebody reply to comment 6 and comment 7?

I think this RFE has an excellent cost-benefit ratio and the potential to improve quality and completeness of bugs a lot.

How hard would it be to mimic something like the mechanism we have for security-relevant bugs and add a single "Private draft" checkbox (near "Submit bug") that hides a bug from public view while granting access only to the reporter and administrators?

Comment 9

[Thomas D. (:thomas8)]

Max, can you make a followup on your recommendation in comment 1, and comment on my comment 6 and comment 7 and comment 8?

It's really unfortunate that this high-potential RFE (and probably quite easy to implement as shown above) does not seem to get much attention. I miss this feature every time I open a new bug, and it actually prevents me from filing some bugs when I know I won't have time to publish all the details at once (instead of having my own draft to improve until it's ready for publication).

Comment 10

[Frédéric Buclin]

(In reply to Thomas D. from comment #9)
> It's really unfortunate that this high-potential RFE (and probably quite
> easy to implement as shown above)

It's by far not trivial to implement. Adding a checkbox or a button in the UI is not the problem. The problem is how to store such bugs in the backend. Must they get a bug ID despite they are not "officially" released? What happens if someone abuses the system (pre-files many bugs but never makes them public/official)? I don't want Bugzilla to become a place where you can put your list of to-do things. So how often should they be purged to not fill the DB? Also, this would involve a lot of code change to ignore unreleased bugs, not only in Bugzilla::Search but almost everywhere.

I certainly don't want these bugs to be stored in the bugs table. But I'm also not sure I want a dedicated table for such bugs, because this means duplicating the bugs table and keeping them in sync (from a DB schema point of view). So it's not trivial to implement.

Comment 11

[Philip Ashmore]

Maybe just adding a "draft" category would do it.

This way the reporter is letting readers know that there are more details to follow.

They can change it to one of the regular categories later when they add more details.

It's certainly the case that currently bugs can be submitted without enough detail to work with.

Letting the reader know that this is unavoidable, will be remedied and that it's not just a gaffe is being good-mannered.

Comment 12

[Dave Miller [:justdave]]

Given the current state of technology (which didn't exist at the time this bug was filed) this almost sounds like a job for Etherpad.

Comment 13

[Thomas D. (:thomas8)]

BMO's Splinter Review addon is able to handle saving drafts before publishing. Can we get some inspiration from there?

(In reply to Frédéric Buclin from comment #10)
> The problem is how to store such bugs in the backend.

If storing bug drafts in bmo's DBs is a problem, I'd be perfectly happy to store them locally on my computer using HTML5 local storage feature or such.

> Must they get a bug ID despite they are not "officially" released?

Probably not.

> What happens if someone abuses the system (pre-files many bugs but never makes
> them public/official)? I don't want Bugzilla to become a place where you can
> put your list of to-do things. So how often should they be purged to not
> fill the DB?

I wouldn't purge, but you could just limit the number of drafts allowed per user to say, 50 draft bugs.

> Also, this would involve a lot of code change to ignore
> unreleased bugs, not only in Bugzilla::Search but almost everywhere.

It would be OK to treat draft bugs as a different animal that can't be searched. If there was a central "draft" flag on such bugs, it should be possible to ignore them without adding too much code. I just need an option where I can develop some bugs incrementally, adding dependencies and such, before filing. 

> I certainly don't want these bugs to be stored in the bugs table. But I'm
> also not sure I want a dedicated table for such bugs, because this means
> duplicating the bugs table and keeping them in sync (from a DB schema point
> of view). So it's not trivial to implement.

Alternatively, perhaps HTML5 local storage?

Comment 14

[Thomas D. (:thomas8)]

(In reply to Dave Miller [:justdave] from comment #12)
> Given the current state of technology (which didn't exist at the time this
> bug was filed) this almost sounds like a job for Etherpad.

Hmmm. Can we tweak Etherpad to include things like dependencies, keywords, flags, etc.? We're not just looking for a place to jot down notes, we're looking for an integrated option where a proper bug including all properties can be incrementally created before publishing.

Comment 15

[Thomas D. (:thomas8)]

(In reply to Frédéric Buclin from comment #10)
> (In reply to Thomas D. from comment #9)
> > It's really unfortunate that this high-potential RFE ... does not seem to get
> > much attention.
> > I miss this feature every time I open a new bug, and it actually prevents me
> > from filing some bugs when I know I won't have time to publish all the
> > details at once (instead of having my own draft to improve until it's ready
> > for publication).
> It's by far not trivial to implement.

@Frédéric, I acknowledge that it is not trivial. However, I believe the benefits will far outweigh the costs of implementation, namely the potential for better quality bugs with less noise, less mail traffic, less questions etc. If you allow users to incrementally refine a bug until it's ready for publishing, such bugs can start off from a much higher level which is practically impossible in the current design.