diff --git a/COLLABORATORS.md b/COLLABORATORS.md new file mode 100644 index 00000000000..0ec93f5fcf7 --- /dev/null +++ b/COLLABORATORS.md @@ -0,0 +1,22 @@ +# Apollo OSS Collaborator Guidelines + +Thanks for helping make Apollo OSS better! Here are a few quick repo maintenance guidelines intended to help keep Apollo projects happy and healthy. + +## Overall + +- Please remember to be polite and respectful to all community members, no matter what is being reported, contributed, etc. People who are taking time out of their lives to participate in the Apollo ecosystem should feel welcomed, included and appreciated. + +## Issues + +- Issues are for bugs only. All other requests should be redirected accordingly, then closed. Feature requests have their own [repo](https://github.com/apollographql/apollo-feature-requests), and requests for help should go to [Slack](https://www.apollographql.com/slack) or [Stack Overflow](http://stackoverflow.com). +- If a bug report is valid, add the `confirmed` label, and optionally decide if community help should be requested using the `help-wanted` label. If you’re planning on working on it, assign the issue to yourself. +- If an issue isn’t easily reproducible, ask for a reproduction and add a `reproduction-needed` label. +- If a reproduction has been asked for but hasn’t been received in 1 week, close the issue. + +## Pull Requests + +* Ensure PR’s have tests (when it makes sense, which is almost always). +* Make sure `CHANGELOG`’s are updated/maintained. Either request that the PR author adds a `CHANGELOG` entry, or add one yourself. Make sure the PR is referenced along with their GitHub username, and link to their profile (to give them extra kudos). +* Don’t forget to consider how a PR you’re merging will affect the docs; either ask contributors for docs changes, open a new issue to track outstanding changes, or consider implementing the docs changes yourself. +* Always think about backwards compatibility; please don’t merge PR’s that require major version bumps, unless talking it over with the core team. +* If the PR has a small number of commits, or a large number of semantically unimportant commits, squash and merge the PR. If the PR commits are well thought out, isolated and would add value to the git history if kept separate, do a merge commit. diff --git a/ISSUE_TRIAGE.md b/ISSUE_TRIAGE.md deleted file mode 100644 index 759ad1c55c9..00000000000 --- a/ISSUE_TRIAGE.md +++ /dev/null @@ -1,59 +0,0 @@ -# Issue Triage - -This document describes the process Apollo contributors use to organize issues. We use Github [issues](https://github.com/apollographql/apollo-client/issues) here to track bugs, and issues in the [Apollo Client Feature Request repo](https://github.com/apollographql/apollo-feature-requests) to track feature requests and discussions. Our goal is to maintain a list of issues that are relevant and well-defined (and [labeled](https://github.com/apollographql/apollo-client/labels)) such that a contributor can immediately begin working on the code for a fix or feature request. Contributors who want to dive in and write code aren't likely to prioritize working on issues that are ambiguous and have low impact. - -We would love to have more contributors who are willing to help out with triaging issues. You can begin by helping issue requesters create good reproductions and by confirming those reproductions on your own machine. It won't be long before the core maintainers notice your work and ask whether you'd like to be promoted to an issue maintainer. - -- [Issue lifecycle](#issue-lifecycle) - - [Bugs](#bugs) - - [Help questions](#help-questions) - - [Feature requests](#feature-requests) -- [Classification](#classification) - - [Severity](#severity) - - [Impact](#impact) -- [Issues ready to claim](#issues-ready-to-claim) - -## Issue lifecycle - -All issues follow the flow outlined below. Your job as an issue maintainer is to work with the requester and others within the community towards the goal of having an issue either become 'claimable' or closed. Read on for more details on the process. - -![Flowchart](./docs/assets/IssueTriageFlow.png "Issue Lifecycle") - -The first step is in determining whether the issue is a bug, help question or feature request. Read on for more details. - -### Bugs - -1. Duplicates should be closed and marked as such. -2. If the bug would be better filed under a different repository (react-apollo, graphql-tag, graphql-anywhere, etc. ), close the issue and politely point the author to the right location. -3. Add the `bug` label. Bugs should have a high-quality reproduction as described [here](CONTRIBUTING.md#reporting-bugs). You may need to help the reporter reduce their bug to a minimal reproduction. Leave the issue open. -5. A reproduction should be confirmed by at least one person other than the original reporter. Run the reproduction and validate that the bug exists; then make a note of your findings on the issue. If a reproduction is supplied but doesn't work, add the `can't-reproduce` label and make a comment describing what happened. -6. Finally, once you've confirmed the reproduction add the `confirmed` label and [classify](#classification) the issue (removing the `can't-reproduce` label if it exists). - -### Help questions - -[Stack Overflow](http://stackoverflow.com/questions/tagged/apollo) and our [Slack channel](https://www.apollographql.com/slack) are the place to ask for help on using the framework. Close issues that are help requests and politely refer the author to the above locations. - -### Feature requests - -Apollo Client feature requests and discussions are managed in the [Apollo Client Feature Request repo](https://github.com/apollographql/apollo-feature-requests). Feature request triaging should happen there. Feature requests and/or discussions opened in this repository should be closed, with a message asking the original requestor to re-open the feature request / discussion in the FR repo. - -

Classification

- -Assign a classification (via GH labels) that enables the community to determine how to prioritize which issues to work on. - -### Priority - -- `high-priority`: Issue impacts more or less every user. -- `medium-priority`: Issue impacts users using a feature that is commonly but not universally used. -- `low-priority`: Issue would go unnoticed by almost all users, apart from those using a very niche feature, or a feature in an unusual way. - -## Issues ready to claim - -This state indicates that bugs/feature requests have reached the level of quality -required for a contributor to begin writing code against (you can easily [filter for this list](https://github.com/apollographql/apollo-client/labels/confirmed) by using the `confirmed` label). - -Although this should have already been done by this stage, ensure the issue is -correctly labeled and the title/description have been updated to reflect an -accurate summary of the issue. - -Contributors should comment on and/or assign themselves an issue if they begin working on it so that others know work is in progress. diff --git a/docs/assets/IssueTriageFlow.png b/docs/assets/IssueTriageFlow.png deleted file mode 100644 index eed38efcf20..00000000000 Binary files a/docs/assets/IssueTriageFlow.png and /dev/null differ