**Responding quickly and gratefully to issues directly affects the success of he project.**
{: .panel-heading}
Being part of the project team means helping to triage and address issues as they come in so the project can continue to run smoothly.
- 1. Issues are for constructive dialog
- 2. Label Issues by type
- 3. How to address a new open Issue
- 4. Accepting Issues
- 5. Championing Issues
- 6. Consensus
- 7. Requesting Technical Steering Committee (TSC) help
- 8. Evaluating core features (TSC members only)
- 9. When to close an Issue
- 10. References
Even negative issues are contributions, so always keep the following points in mind.
As a project team member, you must handle Issue conversations maturely and calmly. Do your best to work with everyone no matter their style--even when people get rude or aggressive. Remember, poor wording choice can also be a sign of someone who doesn't know English very well, so be sure to consider that when trying to determine the tone of someone's message. Being rude, even when someone is being rude to you, reflects poorly on the team and the project as a whole.
The Open Source Survey 
| Fig1. - Problems encountered in open source
Source:
| http://opensourcesurvey.org/2017/ | | |
|---|
| | | |
 |
| | |
Negative experiences have real consequences for project health. 21% of people who experienced or witnessed a negative behavior said they stopped contributing to a project because of it, and 8% started working in private channels more often. [2]
| Fig2. - Negative behavior in open source
Source:
| http://opensourcesurvey.org/2017/ | | |
|---|
| | | |
 |
| | |
Ask questions about the issue whenever something isn't clear. Don't assume you understand what's being reported if there are details missing. Whenever you are unsure, it's best to ask for more information.
It's unlikely we'll be able to accommodate every request, so don't be afraid to say that something doesn't fit into the scope of the project or isn't practical. It's better to give such feedback if that's the case.
Don't be afraid to close issues that you don't think will be done, or when it's become clear from the conversation that there's no further work to do. Issues can always be reopened if they are closed incorrectly, so feel free to close issues when appropriate. Just be sure to leave a comment explaining why the issue is being closed (if not closed by a commit).
The first goal when evaluating an issue is to determine which category the issue falls into.
There are three primary issue categories for issues: defects, features, and questions.
A software defect is a shortcoming, error, flaw, failure, or fault that either
- Produces an incorrect or unexpected result, or
- Causes unintended behavior.
- The community agrees the issue is valid;
- The defect has been confirmed by someone other than the person who reported the issue; and
- The issue includes step-by-step instructions for reproducing the flaw.
A feature refers to public-facing functionality your consumers either use directly or supports the completion of tasks that end with user-facing results.
-
Adding user-facing functionality that doesn't already exist; or
-
A user-facing enhancement to something that already exists.
An inquiry about how something works that won't result in a code change. We'd prefer if people use the mailing list or Stack Overflow for questions, but sometimes they'll open an issue.
When an issue is opened, the bot will automatically apply the label:
Issues labeled with status: triage are the ones that need to be looked at by team members to determine what to do next.
Toggle view of the Issue workflow flowchart.
The steps for prioritizing an issue are:
-
Reply with a thankful comment.
Why:
Someone contributed their time to submit an issue, which means you've converted a user into a contributor! Either request more information (if necessary) or state your opinion about the issue.
If it's a verified defect, ask if the user would like to submit a Pull Request.
-
Verify your understanding of the Issue. Is the Issue clear and understandable?
No:
Add the status: revision needed label to the issue. The bot will add a comment asking for more information. You don't need to comment any further until the person who opened the issue responds with the information requested from the bot.
Yes:
Remove the status: triage pending label.
Add any other applicable labels.
-
changes affect the build system. -
changes don't modify src or test files. -
changes the CI/CD configuration files and scripts,# Examples with scopes ci(travis): descriptive subject ci(circle): descriptive subject ci(browser-stack): descriptive subject ci(sauce-labs): descriptive subject -
Notification that a production or development
library has an available update or verified vulnerability. -
Changes to third-party production or
development support libraries.SemVer ⇧
Apply the label type: fix to ensure that the
PATCHversion also increments. -
documentation changes -
valuable new functionality.SemVer ⇧
Features increment the
MINORversion. -
Defect repairs.SemVer ⇧
Fixes increment the
PATCHversion. -
change that improves performance -
code changes that improve design, but neither
fixes a bug nor adds a feature. -
reverts to a previous commit SHAortag. -
changes that do not affect the meaning of the code
(white-space, formatting, missing semi-colons, etc) -
add missing tests or correct existing testsLabels that affect the product version
We follow Semantic Versioning 2.0.0
.
| Version |
MAJOR |
| :---------: | :---------------------------------------------------: | | :---------------------------------------------------------: | | Definition version when you add functionality in a backwards-compatible manner. version when you make backwards-compatible bug fixes. 
| >| |
Issues may be labeled as status: accepted when the issue is:
- A defect that you've been able to reproduce and verify (i.e. you're sure it's a defect)
- A new feature or change that you're championing and consensus has been reached for its inclusion in the project
The status: accepted label will be added to other issues by a TSC member if it's appropriate for the roadmap.
New rules and rule changes require a champion. As champion, it's your job to:
-
Gain consensus from the archetypes-rules team on inclusion
-
Guide the rule creation process until it's complete (so only champion a rule that you have time to implement or help another contributor implement)
Once consensus has been reached on inclusion, add the "accepted" and, optionally, "help wanted" and "good first issue" labels, as necessary.
Consensus is reached on issues when there are at least three team members who believe the change is a good idea and no one who believes the change is a bad idea. In order to indicate your support for an issue, leave a +1 reaction (thumbs up) on the original issue description in addition to any comments you might have.
If consensus cannot be reached on an issue, or an issue's progress has been stalled and it's not clear if the issue should be closed, then you can refer the issue to the TSC for resolution. To do so, add the "tsc agenda" label to the issue and add a comment including the following information:
- A one-paragraph summary of the discussion to this point.
- The question you would like the TSC to answer.
The issue will be discussed at the next TSC meeting and the resolution will be posted back to the issue.
In addition to the above, changes to the core (including CLI changes) that would result in a minor or major version release must be approved by the TSC by standard TSC motion. Add the label "tsc agenda" to the issue and it will be discussed at the next TSC meeting. In general, requests should meet the following criteria to be considered:
- The feature or feature is in scope for the project and should be added to the roadmap
- Someone is committed to including the change within the next year
- There is reasonable certainty about who will do the work
When a suggestion is too ambitious or would take too much time to complete, it's better not to accept the proposal. Stick to small, incremental changes and lay out a roadmap of where you'd like the project to go eventually. Don't let the project get bogged down in big features that will take a long time to complete.
Be on the lookout for changes that would break the public API. Issues that represent breaking changes should have the label type: breaking change.
All team members are allowed to close issues depending on how the issue has been resolved.
Team members may close an issue immediately if:
- The issue is a duplicate of an existing issue.
- The issue is just a question and has been answered.
Team members may close an issue where the consensus is to not accept the issue after a waiting period (to ensure that other team members have a chance to review the issue before it is closed):
- Wait 2 days if the issue was opened Monday through Friday.
- Wait 3 days if the issue was opened on Saturday or Sunday.
In an effort to keep the issues backlog manageable, team members may also close an issue if the following conditions are met:
-
Close after it has been open for 21 days, as these issues do not have enough support to move forward.
-
Close after 90 days if no one from the team or the community is willing to step forward and own the work to complete to it.
-
Close after 90 days if it has not been completed.
[ 1 ] Github And Collaborators. (2018) Open Source Survey. Retrieved May 05, 2018, from http://opensourcesurvey.org/2017/
Back to Maintainer Guide