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.

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

Workflow #30

Closed
piscisaureus opened this issue Dec 11, 2014 · 3 comments
Closed

Workflow #30

piscisaureus opened this issue Dec 11, 2014 · 3 comments

Comments

@piscisaureus
Copy link
Collaborator

I don't believe that a generic response will really help us classify issues.

Instead, I would suggest that initial triaging is still done by a group of maintainers, but that we use caine to make our workflow much easier.

A good workflow ensures for every issue the ball is clearly in someone's court at all times, and the responsible person (or group) can know what is expected from them. This allows maintainers and community members confidently ignore open issues that are not in their court.

I think most issues can be classified as such:

  • Needs attention from any maintainer: (new or review), e.g.
    • a new issue or pull request needs triage
    • a PR is ready for review and landing
    • a maintainer needs to check up on the status of a discussion and decide how to go forward (e.g. close, bring to the TC or continue the discussion)
  • Needs attention from all or most members of the TC (tc agenda), e.g.
    • for PRs and proposals with a big impact (api change, new feature, architectural change).
  • Needs attention from the community, (discuss or community), e.g.
    • proposals / new features for which it is unclear whether there is sufficient community support, and need further discussion
    • proposals / new features that are low-priority for the tc
  • Needs attention from (or action by) the issue creator (need info), e.g.
    • More information is needed to triage a bug (e.g. operating system, node version, reduced test case)
    • More information is needed to evaluate a proposal or PR (e.g. motivation, future plans)
    • The author of a pull request needs to make changes based on feedback.
  • Accepted, e.g.
    • The maintainers have decided to add a new feature, but nobody is working on it.
    • A bug needs to be investigated by a maintainer, but nobody has has taken ownership of the issue.
    • ❗ this is the only step in the workflow where more detailed labeling (os, module) is really useful
  • In progress, e.g.
    • A maintainer or community member has promised to work on an issue.

On some of the transition between the above states Caine could give a canned response, e.g. when I label an issue community discussion it could say.

  Thanks for contributing to io.js. A maintainer has indicated that your suggestion needs to be discussed in the community. It will be taken into consideration if there are signs of broad community support.

PS: I've used some potential names for label; I don't suggest you use them all exactly as I said.

@indutny
Copy link
Owner

indutny commented Dec 12, 2014

@piscisaureus I don't think that it belong to caine :) It looks like a totally different bot

@piscisaureus
Copy link
Collaborator Author

@indutny Caine can become what it isn't today :)

But in al seriousness, I'd like to think about how a bot can help with our workflow, which means we have to think about our workflow first. I can also take it to the io.js repo if you think it's more appropriate there.

@indutny
Copy link
Owner

indutny commented Dec 13, 2014

@piscisaureus the question is - would I like it to be that? ;)

The workflow you are talking about does not yet exist, so it is way too early (in my opinion) to create a bot that will help us in "housekeeping" of it. Let's continue on io.js repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants