Add Bug Solution box (metadata) to contain what the user must do
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Launchpad itself |
New
|
Undecided
|
Unassigned | ||
Bug Description
I am one of the victims of the bug I commented here
https:/
Please read that bug report and my comment.
The following recommendations belong to "Launchpad itself" for Ubuntu.
For the sake of Ubuntu, may I once again recommend:
- to add keywords of the bug description to indicate the affected versions (starting kernel X, fixed in Y)
- to mark as important such things as data destruction, to tick "affects you" (and allow anyone?)
- in addition to "Bug description", to create a "Bug correction" in which any Ubuntu user can find in words he understands how to correct or circumvent his problem in the system version he is using.
No "fixed", "patch released" or "upgrade" please.
- in case the problem occurs with a particular hardware, to insistingly ask the manufacturers to indicate in their specifications "Supported OS: Linux kernel ≥ X or Ubuntu ≥ Y".
It would have saved me days used to run tests, to find out the reason and the correction.
And most of all, it would have saved my neighbour's disk !!!
| Colin Watson (cjwatson) wrote Re: Better metadata for data-loss bugs | #1 |
| summary: |
- Make Launchpad useful for Ubuntu users + Better metadata for data-loss bugs |
| André Pirard (a.pirard) wrote | #2 |
| summary: |
- Better metadata for data-loss bugs + Add Bug Solution box (metadata) to contain what the user must do |
| André Pirard (a.pirard) wrote | #3 |
| William Grant (wgrant) wrote | #4 |
In general, almost all of this is out of scope for Launchpad itself.
* We did look into adding explicit database-modelled version information to bug tasks very early on in the design, but it was ruled excessively complicated and it's unlikely that we'll add it at this point.
* While I certainly agree that data destruction is important, determining this and managing bug importances is up to the maintainers of the project/package in question.
* Some bugs have workarounds, but many don't, and can only be addressed by upgrading or similar - no matter how much we might wish it to be otherwise. Project maintainers can and do edit bug descriptions to add workaround information at times, which I think is wiser than adding a new "correction" field. We don't have to have explicit fields for every possibility, and adding that would become unmanageable; Launchpad's bug tracking system is already complex.
* Dealing with manufacturers is clearly not something that Launchpad (as a hosting site) can do.