Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Updated issue triage guidelines #1024

Merged
merged 4 commits into from
May 17, 2017
Merged

Updated issue triage guidelines #1024

Changes from 2 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
b422b16
Merge remote-tracking branch 'storybooks/master'
shilman May 12, 2017
e8a1267
Document new issue labeling scheme
shilman May 12, 2017
7f81fb8
Updated triage labels with more detail including merged label
shilman May 16, 2017
674d6e2
Merge branch 'master' into update-issue-labels
shilman May 17, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 14 additions & 6 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,16 +33,16 @@ To test your project against the current latest version of storybook, you can cl
```
cd packages/react-storybook
npm link

cd <your-project>
npm link @kadira/storybook

# repeat with whichever other parts of the monorepo you are using.
```

### Reproductions

The best way to help figure out an issue you are having is to produce a minimal reproduction against the `master` branch.
The best way to help figure out an issue you are having is to produce a minimal reproduction against the `master` branch.

A good way to do that is using the example `test-cra` app embedded in this repository:

Expand Down Expand Up @@ -99,7 +99,16 @@ Issues that are tagged `question / support` or `needs reproduction` are great pl

### Triaging issues

Once you've helped out on a few issues, if you'd like triage access, you can help label issues, and respond to reporters. New issues should be labelled as one of `bug`, `new feature`, `question / support` or `discussion`.
Once you've helped out on a few issues, if you'd like triage access you can help label issues and respond to reporters.

We use the following label scheme to categorize issues:
- **type** - `bug`, `feature`, `question / support`, `discussion`, `greenkeeper`, `maintenance`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a label feature / change request might be more descriptive.

- **area** - `addon: x`, `addons-api`, `stories-api`, `ui`, etc.
- **status** - `needs reproduction`, `needs PR`, `in progress`, etc.

All issues should have a `type` label. They should also have one or more `area`/`status` labels. We use these labels to filter issues down so we can easily see all of the issues for a particular area, and keep the total number of open issues under control.

For example, here is the list of [open, untyped issues](https://github.com/storybooks/storybook/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20-label%3A%22bug%22%20-label%3A%22discussion%22%20-label%3A%22feature%22%20-label%3A%22maintenance%22%20-label%3A%22question%20%2F%20support%22%20-label%3A%22documentation%22%20-label%3A%22greenkeeper%22), or here is a list of [bugs that have not been modified since 2017-04-01](https://github.com/storybooks/storybook/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3A%22bug%22%20updated%3A%3C%3D2017-04-01%20). For more info see [searching issues](https://help.github.com/articles/searching-issues/) in the Github docs.

If an issue is a `bug`, and it doesn't have a clear reproduction that you have personally confirmed, label it `needs reproduction` and ask the author to try and create a reproduction, or have a go yourself.

Expand All @@ -111,13 +120,12 @@ If an issue is a `bug`, and it doesn't have a clear reproduction that you have p

- `bug`s should be closed when the issue is fixed and merged to `master`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

merged to master or released?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think merged myself. Otherwise we need another label fixed or the like and we mentally have to ignore fixed issues. I appreciate users might not find an issue that has been closed but not yet released however.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although maybe it's easier for us to ignore fixed issues, and we can use them to construct a meaningful changelog. I change my vote ;)


- `new feature`s should be closed when merged or if the feature is deemed to be not appropriate.
- `feature`s should be closed when merged or if the feature is deemed to be not appropriate.

- `question / support`s should be closed when the question has been answered. If the questioner drops offline, a reasonable period to wait is two weeks.

- `discussion`s should be closed at a maintainer's discretion.


## Development Guide

> If you want to work on a UI feature, refer to the [Storybook UI](https://github.com/storybooks/storybook/tree/master/packages/storybook-ui) project.
Expand Down