Workflow Labels

Workflow Labels

These are the GitHub labels used to enable the process we use to maintain Revel so that contributors and core team members can understand how we can work together more effectively.

1) Identify Issue Type

Ideally, issues are triaged/acknowledged immediately by identifying their type.

This will enable us to reply to community feedback more promptly while addressing more urgent concerns quickly. This will lead to increased trust in Revel as a reliable tool as well as increased commitment to Revel by its users.

• Support: not actionable, recommend StackOverflow
• Bug: Item is a bug
• Enhancement: New enhancement of existing feature
• Feature: New feature

2) Tag Relevant Topics

Topics help coordinate effort so contributors can focus on certain areas of Revel while identifying related changes that can be done all at once when possible.

• Topics include:
  • #controller
  • #log
  • #template
  • #modules
  • #docs
  • #cache
  • #config
  • #build
  • #jobs
  • #routing
  • #session
  • #static
  • #runtime
  • #i18n
  • #http
  • #filter
  • #code-quality
  • #content-negotiation
  • #debugging
  • #domain-routing

3) Determine Priority

After this initial acknowledgement, further work should be done to prioritize non-critical work. Bugs should take top priority and therefore do not require additional prioritization. Other issue types should have their own priority label.

For simplicity and effectiveness, we use MoSCoW prioritization. The term is an acronym derived from the first letter of each of four prioritization categories (Must have, Should have, Could have, and Won't have but would like) (https://en.wikipedia.org/wiki/MoSCoW_method). We currently do not label Won't have issues.

• Could: when we have free time
• Should: sooner rather than later
• Must: now, top priority

4) Estimate Effort

It's important to demonstrate an understanding of the tasks required to act on an issue. This is only an estimate, but an important part of the planning process.

• Unknown: Needs more planning to determine
• Minutes: Will take up to 60 minutes to implement.
• Hours: Less than a day
• Days: Less than a week

Anything that takes longer than a couple of days should be broken down into smaller chunks.

5) Track Issue Status

We want to ensure that issues are carried to completion and these labels will make it clear what is needed to do this for each issue.

Progressive Status

• Planning: Active planning underway
• Ready: Ready to implement
• Doing: Implementation has started
• Needs Testing: Code complete, needs peer verification

Blocked Status

• Waiting For Reply: Question raised, need reply

Terminal Status

• Tested: Ready for release
• Declined: Duplicated, obsolete, or not required.