launchpad development|
⇤ ← Revision 1 as of 2010-03-22 15:42:53
Size: 1455
Comment:
|
Size: 1739
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 3: | Line 3: |
| ''There should be a way to decline working on bugs without closing down discussions in the bug report.'' | ''There should be a way to close bugs without closing down discussions in the bug report.'' |
| Line 5: | Line 5: |
| '''As a ''' $PERSON<<BR>> '''I want ''' $FEATURE<<BR>> '''so that ''' $BENEFIT<<BR>> ''Consider clarifying the feature by describing what it is not?'' ''Link this from [[LEP]]'' |
'''As a ''' bug supervisor for a project<<BR>> '''I want ''' a way to reject bugs without shutting down continued conversation<<BR>> '''so that ''' bug lists only have relevant bugs for me but community members can continue discussing issues.<<BR>> |
| Line 15: | Line 11: |
| ''Why are we doing this now?'' | === Why do this now? === |
| Line 17: | Line 13: |
| ''What value does this give our users? Which users?'' | Bugs continue to be filled against Launchpad that experience status toggling wars as developers seek to remove bugs from Launchpad workflows but users want them re-opened for discussion. === What value does a new approach provide? === If we had a way to remove bugs from bug lists on Launchpad while leaving discussion open, both developers and users would be happy. |
| Line 21: | Line 21: |
| ''Who really cares about this feature? When did you last talk to them?'' | * Mark Shuttleworth * Any bug supervisor for a project |
| Line 25: | Line 26: |
| ''What MUST the new behaviour provide?'' ''What MUST it not do?'' == Subfeatures == ''Other LaunchpadEnhancementProposal``s that form a part of this one.'' |
This has to be done somehow with a bug's status field, as it is the status that indicates the state of the bug. |
| Line 35: | Line 30: |
| ''What are the workflows for this feature?'' ''Provide mockups for each workflow.'' '''''You do not have to get the mockups and workflows right at this point. In fact, it is better to have several alternatives, delaying deciding on the final set of workflows until the last responsible moment.''''' |
Current suggestions have been to add a status called OPINION. |
| Line 42: | Line 34: |
| ''How will we know when we are done?'' | We will know we have been successful when discussions continue independent of developer work flow on a bug. |
| Line 44: | Line 36: |
| ''How will we measure how well we have done?'' | XXX: Actual stats/metrics still to be added to this LEP. |
| Line 48: | Line 40: |
| ''This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the first part of our release change log. It is mandatory.'' | Bug Supervisors can make use of a new status, OPINION, which will mark a bug closed but is meant to indicate discussions are free to continue in the bug. |
| Line 52: | Line 44: |
| ''Put everything else here. Better out than in.'' | There has been some email discussion between Deryck, Jono L., and Mark about the name of the status. OPINION seems the best anyone can come up with but is still problematic due to the fact that it's purpose is not that clear. |
Close Bugs, while Leaving Discussions Open
There should be a way to close bugs without closing down discussions in the bug report.
As a bug supervisor for a project
I want a way to reject bugs without shutting down continued conversation
so that bug lists only have relevant bugs for me but community members can continue discussing issues.
Rationale
Why do this now?
Bugs continue to be filled against Launchpad that experience status toggling wars as developers seek to remove bugs from Launchpad workflows but users want them re-opened for discussion.
What value does a new approach provide?
If we had a way to remove bugs from bug lists on Launchpad while leaving discussion open, both developers and users would be happy.
Stakeholders
- Mark Shuttleworth
- Any bug supervisor for a project
Constraints
This has to be done somehow with a bug's status field, as it is the status that indicates the state of the bug.
Workflows
Current suggestions have been to add a status called OPINION.
Success
We will know we have been successful when discussions continue independent of developer work flow on a bug.
XXX: Actual stats/metrics still to be added to this LEP.
Release Note
Bug Supervisors can make use of a new status, OPINION, which will mark a bug closed but is meant to indicate discussions are free to continue in the bug.
Thoughts?
There has been some email discussion between Deryck, Jono L., and Mark about the name of the status. OPINION seems the best anyone can come up with but is still problematic due to the fact that it's purpose is not that clear.
