indutny / caine Goto Github PK

n/t

n/t

Just testing

It would be nice if I had to explicitly mention @caineio in my response. For example:

Valid Response

@caineio

1. Yes
2. Core
3. v1.0.0

All responses by OP that don't start with @caineio should be ignored.

Bot, speak to me!

• this is another item in an ordered list
• list item 2
• list item 3

This is a test line above the data, there are some words in it.

• yes
• tls
• v0.12

this is a test line below the data, there are words in here too

• this is another item in an ordered list
• list item 2
• list item 3

@caineio

1. yes
2. crypto
3. v0.12

test

test

1. no
2. what
3. irrelevant

@caineio

1. yes
2. tls
3. v0.12

@caineio

world

With not enough info

• yes
• tls
• v0.12

1. yes
2. other
3. v1.0.0

This is a test post

It would be nice if I've already opened issues on the repo to get a condensed form of the "summary" on how to classify the issues. Perhaps not even showing them at all after I've opened some number of issues.

Representative Example

Issues 1-2 for a user: show full how to response
Issues 3-10 for a user: show condensed response with more info link
Issues 10+: Show no response until some time threshold has passed without being classified.

That said, these are just examples of one possible optimization to make it less annoying.

n/t

testing

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.

What's this then?

I'd love to see the "Introduction" Post, any replies, and the Issue Opener responses cleaned out. As it stands now I've seen a number of issues with comments and responses that have increased the signal to noise ratio for that issue.

1. yes
2. crypto
3. v0.12