I’d assume that a means I reviewed and verified so a distinction isn’t really needed. If anything is unclear, rather amend with some text. We could maybe use to “mark” a “+0 review” that would then need some text to explain…
As far as a for verification is concerned, we should have Jenkins and/or Travis CI report back on PRs via the PR API to (at least partially) solve that.
regarding labels: I guess we won’t need a “work in progress” label, right? Because if something is WIP, you just don’t create a pull request?
On the other hand: if you thought it would be ready for review but after the first review realized that you need to go back to the drawing table, would you close the PR oder would you … set some label?
Actually we could decide to just close the pull request and reopen one at a later stage. Your fork with your changes is still there and you can continue to work on it…
I could imagine that something like the labels above makes sense for us as well. Maybe we can even synchronise labels somehow with Jira, so that if an issue is mentioned in the PR (which should be the case usually), some script sets labels according to what we have in Jira.
I don’t like that it’s a table, but we do need the information (and we required it with our Gerrit process already). They question is where to put the information.
“Tests pass” should be determined automatically, license should be clear (GPL for Neos, MIT for Flow), documentation should be contained in the PR.
“Bug fix” / “new feature” / “BC breaks” was communicated in the commit subject, question is if we continue to do that. We could modify it a little and write subjects like:
Bugfix: Make infinite loop less endless
or
(!) Feature: Use PHPLIB instead of Symfony Components
Sure. I was just thinking about how we did it “back then”. OTOH, it might be a chance to begin using “abandon” more often, which we used only seldomly.
Regarding “WIP” tag/flag - there is still some case where you have some idea on how to implement a specific feature/task and want to show it early to get feedback, where it should be clear that this is not merge-ready. Should those cases then be handled with simply linking to the feature branch in one’s own fork, or would it still be valid to already create a PR?
I would like to add the third option for nitpicks to just merge the original change and push a follow up fixing the nits afterwards (which then could probably be merged as no-brainer).
if you assign a WIP label, be prepared that noone reviews your code - if it’s ready for review, don’t mark as WIP
This is still a no go for me. IMHO everyone should be curious about conceptual ideas and very early feedback is sometimes very helpful to get stuff out of WIP. I usually open PRs as WIP to get feedback…
I would rather come to the formula:
If you don’t want your code/change reviewed don’t start a pull request (yet). If it is really only halfway done code wait until the concept becomes clear to open a PR.
Same goes for failing style/tests. Both may block a merge, but the concept might be OK just that the code changes break a lot of tests, also there it would be great to get some early feedback on the change itself.