Difference between revisions of "Bug or Suggestion"
From Dreamwidth Notes
(s/Bugzilla/GHI/) |
m (added cats) |
||
(2 intermediate revisions by one other user not shown) | |||
Line 19: | Line 19: | ||
* Straightforward items that do not require community discussion. | * Straightforward items that do not require community discussion. | ||
− | See: [[Bug Report Workflow (Support)]] and [[Github Issues]]/[[ | + | 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 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)