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

How to extend triage to pull requests? #5

Open
chrisdickinson opened this issue Nov 12, 2014 · 1 comment
Open

How to extend triage to pull requests? #5

chrisdickinson opened this issue Nov 12, 2014 · 1 comment

Comments

@chrisdickinson
Copy link
Contributor

As of nodebugme/site@fe2d715, pull requests should no longer show up in the triage queue -- this is good, because all the questions nodebugme asks are about issues, not pull requests.

However, there are a lot of pull requests, and it would be great to be able to make some information available about them! The problem is, then, what to ask?

The parameters are:

  1. Questions must be objective, not subjective. That is to say, two reasonable humans who have roughly equal background knowledge & experience, should be able to come to the same answer to a question -- even if their opinions differ.
  2. Answers to questions, while objective, must not be easily derived from the data available -- after all, if it's easy to derive, why not have a computer do it?
  3. Answers should provide an actionable outcome for contributors.
  4. There should be some benefit to answering the question on Nodebugme (vs. directly commenting on the pull request).

A few questions I'm thinking of:

  1. Has this pull request already been resolved? When?
  2. Does this pull request duplicate functionality from any other pull request? Which ones?
@fhemberger
Copy link

I would add:

Does this pull request fix existing issues?
[ ] Yes: Issue number(s) …………………
[ ] No
[ ] Don't know

While triaging, I stumbled upon several issues having already a PR linked to them, where the proposed solution was discussed and at least generally agreed on. So I usually marked those issues (with mostly less specific discussions) as duplicate.

It would also be nice if an issue/PR could be flagged as actual bug, feature request, general question, documentation issue, etc. along with a severity/complexity estimation of the issue ("we should entirely rewrite core module xy" vs. "I fixed a spelling mistake"). This would it make easier to crunch a larger number of small/easy issues or postponing feature requests, reducing the total amount of tickets to have more time discussing/fixing the larger ones.

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