Difference between revisions of "Bug or Suggestion"
From Dreamwidth Notes
(There's an art to it.) |
m (added cats) |
||
| (9 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | Dreamwidth has a few workflows for submitting items to [[ | + | Dreamwidth has a few workflows for submitting items to [[Github Issues]]. The ideal workflow to use depends on the exact situation. |
=Suggestion= | =Suggestion= | ||
| − | Dreamwidth solicits a wide range of user opinions on many proposed changes before approving an item for implementation. A relatively small percentage of the active user population of Dreamwidth is comfortable using | + | Dreamwidth solicits a wide range of user opinions on many proposed changes before approving an item for implementation. A relatively small percentage of the active user population of Dreamwidth is comfortable using Github Issues, compared to the users who follow the <dwcomm>dw_suggestions</dwcomm> community. |
| + | |||
| + | See: [[Suggestions Process]] | ||
The following types of changes are particularly likely to be referred to the whole user community (not just staff, contractors, and developers) for discussion: | The following types of changes are particularly likely to be referred to the whole user community (not just staff, contractors, and developers) for discussion: | ||
| − | + | ;New Feature: An entirely new feature that does not currently exist. | |
| − | An entirely new feature that does not currently exist. | + | |
| − | + | ;Enhancement: Changes to improve an existing feature. | |
| − | Changes to improve an existing feature. | + | |
| − | + | ;Preferred Implementation: Some new features, enhancements, and outright bug fixes require a decision about how best to do it out of two or more possible ways. The <dwuser>dw_suggestions</dwuser> participants can also provide feedback for this. | |
| − | Some new features, enhancements, and outright bug fixes require a decision about how best to do it out of two or more possible ways. The <dwuser>dw_suggestions</dwuser> participants can also provide feedback for this. | + | |
=Bug= | =Bug= | ||
| − | Something that is broken (not functioning as designed). | + | * Something that is broken (not functioning as designed). |
| − | Something that is broken-as-designed (is functioning as designed, but how it is designed is bad). | + | * Something that is broken-as-designed (is functioning as designed, but how it is designed is bad), and the fix is unambiguous and does not require community discussion. (Example: a site image that lacks an alt tag and really needs one.) |
| − | Straightforward items that do not require community discussion. | + | * Straightforward items that do not require community discussion. |
| + | |||
| + | See: [[Bug Report Workflow (Support)]] and [[Github Issues]]/[[Git How To]] (for developers) | ||
| + | |||
| + | [[Category: Support]] | ||
| + | [[Category: Development]] | ||
Latest revision as of 19:18, 12 August 2015
Dreamwidth has a few workflows for submitting items to Github Issues. The ideal workflow to use depends on the exact situation.
Suggestion
Dreamwidth solicits a wide range of user opinions on many proposed changes before approving an item for implementation. A relatively small percentage of the active user population of Dreamwidth is comfortable using Github Issues, compared to the users who follow the ![[info]](http://wiki.dreamwidth.net/wiki/extensions/LJ/images//dw/user.png){kind=small}
dw_suggestions community.
See: Suggestions Process
The following types of changes are particularly likely to be referred to the whole user community (not just staff, contractors, and developers) for discussion:
- New Feature
- An entirely new feature that does not currently exist.
- Enhancement
- Changes to improve an existing feature.
- Preferred Implementation
- Some new features, enhancements, and outright bug fixes require a decision about how best to do it out of two or more possible ways. The dw_suggestions participants can also provide feedback for this.
Bug
- Something that is broken (not functioning as designed).
- Something that is broken-as-designed (is functioning as designed, but how it is designed is bad), and the fix is unambiguous and does not require community discussion. (Example: a site image that lacks an alt tag and really needs one.)
- Straightforward items that do not require community discussion.
See: Bug Report Workflow (Support) and Github Issues/Git How To (for developers)
