search

pullreminders / backlog

Public backlog for http://pullpanda.com
59 stars 9 forks source link

Question: Draft GitHub PR's #155

Open davidgoate opened 5 years ago

davidgoate commented 5 years ago

I have a question r.e. https://github.blog/2019-02-14-introducing-draft-pull-requests/

Does the clock start ticking on draft PR's in the same way as non-draft ones? e.g. do they count towards average time to merge while in the draft state?

I guess it can make sense still that if someone is tagged as a reviewer of a draft PR to get early feedback that that metric should count towards review time. I think one could make an argument that it should also still count towards time to merge too, but it does seem legit to me that having a way which encourages early feedback on the PR without it necessarily being open or ready is a good thing and this measure can't really be used to track how long a feature has taken from start to end anyway since the clock starts counting only when the developer opens the PR - not when they pick up the work.

Either way, I'd like to be clear for now on how this measurement currently works with respect to draft state PR's.

Thanks!

abinoda commented 5 years ago

@davidgoate Right now the clock starts ticking when a PR is opened, not when marked ready for review. We could allow the option of viewing both times, though.

davidgoate commented 5 years ago

@abinoda

the clock starts ticking when a PR is opened

do you know internally in GitHub whether the PR is considered "open" in the draft state. I would imagine that it is given that the API docs seem to have two different JSON attributes for state and draft.

I think it would be a "kinder" metric, to have the option to measure the time between when the PR comes out of draft state and finally gets merged for the average time to merge section.

My reasoning is that one one hand I think we'd want to encourage developers to get as much early and fast feedback as possible (both from humans and automated tooling which runs on PR's). They might feel discouraged from opening PR's "too early" if the metric for "time to merge" starts to look worse when people are more exploratory by nature in opening PR's compared to their peers who perhaps just open the PR when they think it's much more mature.

I think our workflow at least is more that PR's are usually opened when the author considers it appropriate to be merged in the current state - of course the reviewer(s) may not agree. What I would wonder is whether more developers would feel more free to open PR's earlier in an exploratory way for immediate input even before they would themselves consider the code ready to be merged if they didn't sense there was some negative tracking consequence to it.

Any other thoughts on this very welcome, I could see how it can be argued from different directions.