Bug 12254 – Github interaction improvement proposals (via user.js or addins)

Vladimir Panteleev is working on something to improve our experience with using Github, since it's really lacking some needed features. Here we can list our enhancement requests. Some off the top of my head: - currently you can't filter through pulls assigned to you or to anyone else for that matter. It only works when you have Issues enabled in a repository (we don't for D-related projects). - you can't designate one pull being blocked by another pull (e.g. when a DMD pull needs a Druntime/Phobos pull being merged first). - you can't mark a pull as being stalled by something. E.g. maybe it needs more work to be done, but simply closing it means it can get lost forever. - you can't mark a pull as already being fully reviewed and ready to merge. Maybe it just needs a rebase. - you can't filter through closed pulls where you can tell whether a pull was closed because it was merged, or it was closed but not merged. - displaying the current autotester results next to each pull in the pull request listing page would be good to have, rather than to have to open each pull to see the current results. You can view a list of pulls in the autotester, but they don't have a pull title and I hate having to use 2 websites for the same task. - is a pull request trivial or more elaborate? you can't mark a pull as being trivial, although you can use naming conventions. - timers: you sometimes ping the author of a pull request for an update (you request edits or a rebase), but the author seems to have vanished. You really want to be notified within some timeframe (say 2 weeks) if the author hasn't responded yet, so someone else can take over the work and continue with another new pull request. Otherwise the pull can easily stay stale for an entire year simply because nobody noticed the author is gone or isn't working on the pull anymore.

- A checklist of questions which should be answered before merging. Sometimes a pull request is merged because discussions tend to drown out all the questions, it's hard to keep track which questions were resolved and which ones were not. If we had a way of marking questions (comments) as important they could show up at the top, and later we could mark them as resolved when they're answered.

Created attachment 1332 screenshot

(In reply to comment #1) > - A checklist of questions which should be answered before merging. Sometimes a > pull request is merged because discussions tend to drown out all the questions, > it's hard to keep track which questions were resolved and which ones were not. > If we had a way of marking questions (comments) as important they could show up > at the top, and later we could mark them as resolved when they're answered. (In reply to comment #2) > Created an attachment (id=1332) [details] > screenshot Posted a screenshot to see what I mean.

I think the important fact is that currently, reviewers must scan the entire discussion for every pull every time they are making a pass through the pull request list. This can be solved by allowing reviewers to assign a status to each pull, e.g.: - open questions (there are unanswered questions to the pull author) - WIP (there is a problem with the patch that needs to be fixed) - under review (just needs more LGTMs) The status is reset when some activity occurs on the pull, implying that the pull's status needs to be reevaluated.

(In reply to comment #4) > I think the important fact is that currently, reviewers must scan the entire > discussion for every pull every time they are making a pass through the pull > request list. This can be solved by allowing reviewers to assign a status to > each pull, e.g.: > - open questions (there are unanswered questions to the pull author) > - WIP (there is a problem with the patch that needs to be fixed) > - under review (just needs more LGTMs) > > The status is reset when some activity occurs on the pull, implying that the > pull's status needs to be reevaluated. Yes. Honestly I have no idea what Github is doing these days, they blog about hiring new people all the time, but are they implementing features or just drinking beer in pubs around the world? (sometimes I feel like they're hosting a traveling show).

I'm not sure about this, but we could try enabling issues on the repositories. This would let us tag and assign pull requests, and the autotester could tag pulls as passing/failing. We could even have a bot that could tag pulls as stale if they have been in the 'needs work' state for > n weeks etc. The downside is that people might start reporting actual issues there instead of here, but it might be worth the extra bookkeeping.

(In reply to comment #6) > I'm not sure about this, but we could try enabling issues on the repositories. > This would let us tag and assign pull requests, and the autotester could tag > pulls as passing/failing. We could even have a bot that could tag pulls as > stale if they have been in the 'needs work' state for > n weeks etc. I think that would make sense only if it solved all or almost all of the problems. > The downside is that people might start reporting actual issues there instead > of here, but it might be worth the extra bookkeeping. I think there's some file you can add to the repository that'll be displayed automatically when attempting to file a new issue. This can direct users to Bugzilla.

(In reply to comment #7) > (In reply to comment #6) > > I'm not sure about this, but we could try enabling issues on the repositories. > > This would let us tag and assign pull requests, and the autotester could tag > > pulls as passing/failing. We could even have a bot that could tag pulls as > > stale if they have been in the 'needs work' state for > n weeks etc. > > I think that would make sense only if it solved all or almost all of the > problems. > Well, decent tagging and search does seem to cover most of these. > > I think there's some file you can add to the repository that'll be displayed > automatically when attempting to file a new issue. This can direct users to > Bugzilla. That would work.

GitHub PR interface has improved a lot since this issue was opened (labels, checklists, filtering etc.), so I think we can now close this.

> you can't filter through closed pulls where you can tell whether a pull was closed because it was merged, or it was closed but not merged. I think this one is still true. But otherwise yeah things have improved. :)