search

nodebugme / discussion

need help? or just wanna ask a question? open an issue on this repo!
4 stars 0 forks source link

How to extend triage to pull requests? #5

Open chrisdickinson opened 10 years ago

chrisdickinson commented 10 years ago

As of https://github.com/nodebugme/site/commit/fe2d7151921dd055d43d98c6fec954767b6952bf, 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 commented 10 years ago

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.