From 17954ea03bb64736cb95c313ab02928a823c8592 Mon Sep 17 00:00:00 2001 From: Luca Comellini Date: Tue, 14 Feb 2023 16:05:55 -0800 Subject: [PATCH] Add Issue Lifecycle and update Contributing --- CONTRIBUTING.md | 21 +++++++++++++++------ ISSUE_LIFECYCLE.md | 37 +++++++++++++++++++++++++++++++++++++ 2 files changed, 52 insertions(+), 6 deletions(-) create mode 100644 ISSUE_LIFECYCLE.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 9ce3e08b..405c9701 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -14,12 +14,15 @@ The following is a set of guidelines for contributing to the NGINX Prometheus Ex * [Git Style Guide](#git-style-guide) * [Go Style Guide](#go-style-guide) -[Code of Conduct](https://github.com/nginxinc/nginx-prometheus-exporter/blob/main/CODE_OF_CONDUCT.md) +[Code of Conduct](CODE_OF_CONDUCT.md) ## Ask a Question -We will have a public forum soon where you can come and ask questions and have a discussion. For now please open an Issue on GitHub with the label `question`. +To ask a question please use [Github Discussions](https://github.com/nginxinc/nginx-prometheus-exporter/discussions). +You can also join our [Community Slack](https://community.nginx.org/joinslack) which has a wider NGINX audience. + +Please reserve GitHub issues for feature requests and bugs rather than general questions. ## Getting Started @@ -28,7 +31,7 @@ Follow our [Getting Started Guide](README.md#getting-started) to get the NGINX P ### Project Structure * This Prometheus Exporter is written in Go and supports both the open source NGINX software and NGINX Plus. -* The project dependencies reside in the `/vendor`. We use [go modules](https://github.com/golang/go/wiki/Modules) for managing dependencies. +* We use [Go modules](https://github.com/golang/go/wiki/Modules) for managing dependencies. ## Contributing @@ -43,16 +46,22 @@ To suggest an enhancement, please create an issue on GitHub with the label `enha ### Open a Pull Request * Fork the repo, create a branch, submit a PR when your changes are tested and ready for review -* Fill in [our pull request template](https://github.com/nginxinc/nginx-prometheus-exporter/issues/new?template=bug_report.md) +* Fill in [our pull request template](.github/PULL_REQUEST_TEMPLATE.md) + +> **Note** +> +> If you’d like to implement a new feature, please consider creating a feature request issue first to start a discussion about the feature. + +### Issue lifecycle -Note: if you’d like to implement a new feature, please consider creating a feature request issue first to start a discussion about the feature. +* When an issue or PR is created, it will be triaged by the core development team and assigned a label to indicate the type of issue it is (bug, feature request, etc) and to determine the milestone. Please see the [Issue Lifecycle](ISSUE_LIFECYCLE.md) document for more information. ## Style Guides ### Git Style Guide * Keep a clean, concise and meaningful git commit history on your branch, rebasing locally and squashing before submitting a PR -* Follow the guidelines of writing a good commit message as described here https://chris.beams.io/posts/git-commit/ and summarised in the next few points +* Follow the guidelines of writing a good commit message as described here https://chris.beams.io/posts/git-commit/ and summarized in the next few points * In the subject line, use the present tense ("Add feature" not "Added feature") * In the subject line, use the imperative mood ("Move cursor to..." not "Moves cursor to...") * Limit the subject line to 72 characters or less diff --git a/ISSUE_LIFECYCLE.md b/ISSUE_LIFECYCLE.md new file mode 100644 index 00000000..c57bc037 --- /dev/null +++ b/ISSUE_LIFECYCLE.md @@ -0,0 +1,37 @@ +# Issue Lifecycle + +To ensure a balance between work carried out by the NGINX engineering team while encouraging community involvement on this project, we use the following issue lifecycle. (Note: The issue *creator* refers to the community member that created the issue. The issue *owner* refers to the NGINX team member that is responsible for managing the issue lifecycle.) + +1. New issue created by community member. + + +2. Assign issue owner: All new issues are assigned an owner on the NGINX engineering team. This owner shepherds the issue through the subsequent stages in the issue lifecycle. + + +3. Determine issue type: This is done with automation where possible, and manually by the owner where necessary. The associated label is applied to the issue. + #### Possible Issue Types + `needs more info`: The owner should use the issue to request information from the creator. If we don't receive the needed information within 7 days, automation closes the issue. + + `bug`: The implementation of a feature is not correct. + + `proposal`: Request for a change. This can be a new feature, tackling technical debt, documentation changes, or improving existing features. + + `question`: The owner converts the issue to a github discussion and engages the creator. + + +4. Determine milestone: The owner, in collaboration with the wider team (PM & engineering), determines what milestone to attach to an issue. Generally, milestones correspond to product releases - however there are two 'magic' milestones with special meanings (not tied to a specific release): + + - Issues assigned to backlog: Our team is in favour of implementing the feature request/fixing the issue, however the implementation is not yet assigned to a concrete release. If and when a `backlog` issue aligns well with our roadmap, it will be scheduled for a concrete iteration. We review and update our roadmap at least once every quarter. The `backlog` list helps us shape our roadmap, but it is not the only source of input. Therefore, some `backlog` items may eventually be closed as `out of scope`, or relabelled as `backlog candidate` once it becomes clear that they do not align with our evolving roadmap. + + - Issues assigned to `backlog candidate`: Our team does not intend to implement the feature/fix request described in the issue and wants the community to weigh in before we make our final decision. + + `backlog` issues can be labeled by the owner as `help wanted` and/or `good first issue` as appropriate. + + +5. Promotion of `backlog candidate` issue to `backlog` issue: If an issue labelled `backlog candidate` receives more than 30 upvotes within 60 days, we promote the issue by applying the `backlog` label. While issues promoted in this manner have not been committed to a particular release, we welcome PRs from the community on them. + + If an issue does not make our roadmap and has not been moved to a discussion, it is closed with the label `out of scope`. The goal is to get every issue in the issues list to one of the following end states: + + - An assigned release. + - The `backlog` label. + - Closed as `out of scope`.