For this project, issues on GitHub represent actionable work that should be done at some future point. It may be as simple as a small typo fix or as large as tracking the need to create a new guideline, standard or recipe. However, it should be work that falls under the mission statement of the project.
For issues that are meant to request an enhancement or addition (see Labels, below), we'd like the issue to contain the following details:
- A short description of the proposed change
- Rationale: A paragraph or two justifying why the change will benefit the project
- Details (optional): if you want to do so, you can also provide additional details that may find their way into a pull request once the issue is approved (see Labels, below).
- Open Questions (optional): any questions that you feel should be discussed on the issue.
- Pull Request (optional): If a pull request is created, you can link to it from the issue in this section
- Updates: As you update an existing issue, keeping a running change log in this section is desirable.
There are few major reasons that we might close an issue:
- Issues unrelated to the mission statement of the project.
- Issues that are specific to OpenStack API guidelines. Since this project is targeting APIs that are not related to OpenStack, we'll direct you to the OpenStack API Working Group.
- Nebulous issues. Issues that are not sufficiently specific or clear will be closed.
- Sometimes after debate, we'll decide an issue isn't a good fit for the project. In that case, we'll also close it. Because of this, we ask that you don't start working on an issue until it's tagged with "up for grabs" or "issue approved". We'd hate for you to spend time and effort working on a change we'll ultimately be unable to take.
We use GitHub labels on our issues in order to classify them. We have the following categories per issue:
- Type: These labels classify the type of issue. We use the following types:
- formatting: Formatting or typo related issues
- enhancement: Issues related to an existing guideline, standard or recipe that improves it, but do not add new documents
- addition: Issues related to a request for a new guideline, standard or recipe. If approved, at least one new document will be created.
- Ownership: These labels are used to specify who owns specific issue. Issues without an ownership tag are still considered "up for discussion" and haven't been approved yet. We have the following different types of ownership:
- up for grabs: Small sections of work which we believe are well scoped. These sorts of issues are a good place to start if you are new. Anyone is free to work on these issues.
- approved: Larger scale issues. Like up for grabs, anyone is free to work on these issues, but they may be trickier or require more work.
- grabbed by community: Someone outside the Rackspace Enterprise Architecture team has assumed responsibility for addressing this issue and is working on a fix. The comments for the issue will call out who is working on it. You shouldn't try to address the issue without coordinating with the owner.
- grabbed by assignee: Like grabbed by community, except the person the issue is assigned to is making a fix. This will be someone on the Rackspace Enterprise Architecture team.
We assign each issue to a Rackspace Enterprise Architecture team member. In most cases, the assignee will not be the one who ultimately fixes the issue (that only happens in the case where the issue is tagged "grabbed by assignee"). The purpose of the assignee is to act as a point of contact between the Rackspace Enterprise Architecture team and the community for the issue and make sure it's driven to resolution. If you're working on an issue and get stuck, please reach out to the assignee (just at mention them) and they will work to help you out.