On 11 November 2017 at 20:04, Jeremy Lavergne wrote: > These sound reasonable to me. > > When dealing with tags, my general encouragement is to ask: > "Are these tags the fewest necessary to reach your goal?"
This is why I started the discussion. >> - needs_review: nobody with sufficient expertise took a look yet to >> provide some qualified feedback This is kind of default state anyway. But some PRs might be extra tricky to do and I would reserve the tag for those. >> - wait_for_maintainer: someone from our team thinks the commit is ok, >> but would prefer to wait for the port maintainer to take a look first This is also kind-of-evident from: - a green check given by some reviewer (but it's never clear whether this check was given by the actual maintainer or someone else; this would make it more clear) - a request for the maintainer to make a review but it would be nice to have an obvious label This would probably be most useful for Trac. >> - more_changes_needed: the changes are not quite ready yet A while ago I created a tag WIP and people argued that work-in-progress should not even be submitted as a PR. It was then removed. I would still find it useful though. It might turn out that 90% of work is done and someone finds a problem that needs to be resolved first. There's another potentially related thing (not sure if it should be the same or another tag). Like "no, please don't commit an update to lua because this breaks many ports". Or, "wait-a-moment, it turns out that something is broken after this, I need a couple of more days to fix it". >> - wait_for_upstream_feedback: we would prefer if upstream would take a >> look, or at least to get an upstream ticket open before merging the >> changes >> >> - wait_for_opinion: there's still an ongoing debate, opinions >> potentially differ, we need more brainstorming etc. Mojca
