Open bernhold opened 3 years ago
Need resources about work-in-progress pull requests, how to use them, and when to use them instead of regular pull requests.
In my mind (and practice), PR drafts are for code that is still in progress of being developed (designed and/or implemented). Different ideas are being tried, major gaps are left unfilled because their is no point in filling those gaps with solutions that aren't yet fully defined, etc. What is being reviewed in a draft PR is primarily the design and major implementation strategies or key integration (not all) questions. In some sense a draft PR is kinda sorta a way to have an async design review using the same conversation mechanisms GitHub provides for normal PRs.
I agree with that. I remember once reading an article that advocated starting a WIP PR even before you start coding (though I couldn't figure out how to do that in GitHub -- maybe other sites support it) to socialize the idea, discuss the design, etc. The obvious alternative would be to do the preliminaries in an issue and then move to a PR. But that fragments the discussion.
I would think the more UNfamiliar one is with a code base and/or team they are planning a PR for, the more value there would be in engaging the target team ahead of doing the actual work. There is a ton of context that might help in informing the work and having the ability to have an async conversation about it, being able to point to specific bits and pieces of code easily, is very useful in having that conversation. That is exactly what a draft PR provides.
I think this can be helped with https://github.com/betterscientificsoftware/bssw.io/issues/409#issuecomment-1079702025.
But GitHub itself suggests opening a PR early to get some feedback.
But I think a better answer is create an Epic or Story for the changes you want to make and then make them in series of smaller PRs.
This is to respond to a request by Slaven Peles of the ExaSGD project.
Need resources about work-in-progress pull requests, how to use them, and when to use them instead of regular pull requests.