In the Moving Forward Project, we leverage Github issues to efficantly translate work done into documentable efforts.
In the olde days of chat issues, devs would accept issues that were created by the CS team. Instead, developers assign github issues to themselves and document changes in the comment section, closing the issue upon completion.
There are two types of issues.
- Created by the Customer Service team and is eventually translated into a Developer issue with more a more elaborate selection of relevent labels, milestones and projects.
- Notated with the
team:supportlabel.
- Created by a developer to keep track of work that has been done and what work needs to be done.
- Notated with the
team:developerlabel.
The team that initialized the issue.
team:support- a member of the Customer Service team created this issue.
team:developer- a member of the Developer team created this issue.
Brand new functionality. New pages, workflows, endpoints, etc.
addition:feature- this issue is intended to be a new feature.
Server environment, With good QA, you'll identify issues on test and staging deployments.
environment:staging- this issue pertains to a release that is currently in staging.
environment:test- this issue pertains to our local testing environment.
Affect user’s comprehension, or overall enjoyment of the product. These can be both opportunities and “UX bugs”.
experience:design- this issue pertains to the way something looks.
experience:ux- this issue pertains to user flow.
Requires further conversation to figure out the action steps. Most feature ideas start here.
feedback:discussion- by default, all
team:supportissues arefeedback:discussionissues. - also used for developers if they want to document a discussion.
- by default, all
feedback:question- this issue is a question about functionality.
feedback:request- this issue is a request for new or different functionality.
Iterations on existing features or infrastructure. Generally these update speed, or improve the quality of results. Adding a new “Owner” field to an existing “Calendar” model in the API, for example.
improvement:enhancement- this issue pertains to improving upon an existing feature
improvement:optimization- this issue pertains to improving the efficiancy or performance of a feature.
No action needed or possible. The issue is either fixed, addressed better by other issues, or just out of product scope.
inactive:duplicate- this issue is a duplicate of another issue
inactive:invalid- this issue is simply invalid in our project's scope.
inactive:wontfix- this issue described intended functionality or a bug which will never be fixed.
Converting measurements, reorganizing folder structure, and other necessary (but less impactful) tasks.
mindless:chore- any mindless/chore task, especially things like sysadmin.
mindless:legal- changes made to the website in respect to a legal request or responsibility.
Taking action, but need a few things to happen first. A feature that needs dependencies merged, or a bug that needs further data.
pending:in progress- this issue has work thats begun on it but something else has to happen before this issue can be completed.
pending:on hold- something else has to happen before work on this issue can begin/
pending:watchlist- this issue needs more information before we can act .
If the repository covers multiple parts, this is how we designate where the issue lives. (i.e. web, mobile).
platform:chromeplatform:edgeplatform:firefoxplatform:safari
This is how we designate what specific set of features this issue is pertinent to.
project:google syncproject:leadsproject:call listproject:check listproject:calendar
Issues that make the product feel broken. High priority, especially if its present in production.
problem:bug- this issue pertains to unexpected behaviour in the project.
problem:security- this issue pertains to a security flaw like exposure to XSS, SQL Injection, Insecure Connections (i.e non-SSL), etc.
The effect an issue has on the versioning of the release of the project.
versioning:compatible- this issue does not create a change that would not require another application to update their usage of our API or application. (i.e an endpoint takes the same parameters and returns the same data, but was changed to perform better)
versioning:incompatible- this issue creates a change that would break if another application didn't update their usage of our API. (i.e an endpoint is removed or replaced)