Difference between revisions of "Bug or Suggestion"

From Dreamwidth Notes
Jump to: navigation, search
m (Suggestion: formatting)
m (added cats)
 
(5 intermediate revisions by 3 users not shown)
Line 1: Line 1:
Dreamwidth has a few workflows for submitting items to [[Bugzilla]]. The ideal workflow to use depends on the exact situation.  
+
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 Bugzilla, compared to the users who follow the <dwcomm>dw_suggestions</dwcomm> community.  
+
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]]
 
See: [[Suggestions Process]]
Line 18: Line 18:
 
* 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.)  
 
* 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]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 [info]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)