Moving over a discussion from #2826:

@bgruening in #2826 (comment)

We do not have a strict guideline to wait for reviews afaik.

@dpryan79 in #2826 (comment)

@bgruening I though there used to be the idea that if you were submitting a brand new recipe that the core team should give it a thumbs up before merging. I imagine a /review team could serve that purpose (for new recipes that are already passing tests).

@epruesse in #2826 (comment)

We claimed in the paper that we enforce a 4-eyes process, and as Bioconda's membership grows, we should move toward a setup where not everyone can just merge themselves. => The members of that group should at some point become the only ones with merge privileges.

@mbargull in #2826 (comment)

I would be very much in favor to make reviews mandatory for every merge. Even for stupidly simple version bumps -- typos or forgotten build number resets and such can always happen.
If one wants to argue this would needlessly slow down package releases, I'd counter that rarely none of those lovely "blazing-fast-never-sleeping-maniacs" are around 😉.

I think having a @bioconda/review might be a good idea, just to have the ability to somehow ping people for a review. The only downside I see is that, IIRC, there is no possibility to "hop-onto/hop-off of" GitHub teams easily. Meaning, it would be nice to have the possibility to join a team, esp. @bioconda/review, only temporarily when one has a bit time to spare (and doesn't have to bug anyone with appropriate permissions on every join/leave).

@chambm in #2826 (comment)

-1 on mandatory reviews. My experience with this has been that it overwhelms the team doing reviews and leads to slow turn around times. conda-forge processes are currently similar to this; my recent PRs there have gotten 3+ days to review and merge for simple version bumps. Even the current slow Travis build times make it hard to respond to issues in tools I'm maintaining that require updating or fixing packages, so I'd find it hard to have a slower process.

@mbargull in #2826 (comment)

My experience with this has been that it overwhelms the team doing reviews and leads to slow turn around times.

Possible, sure. Although I see Bioconda less susceptible to that than conda-forge since we have that unified repository here. So the probability someone sees/reviews a PR should be higher compared to single feedstocks on conda-forge. But thanks for sharing that concern!

@tiagoantao in #2826 (comment)

-1 on mandatory reviews also. But I think it would bet good to have a team to help with people that ask for voluntary reviews.

@epruesse in #2826 (comment)

Let's start by having a review team and seeing how long it takes for reviews to be done in the worst case. Turnaround time and stability are competing interests, and that discussion is out of scope here.

That said... I'm using Bioconda to provision the tools I need in "production". In that environment I can easily live with a week's turnaround time, but breakage (networkx...grrr) is a problem. IIRC Bioconda policy is releases only, not pre-releases or alphas, for that exact reason. The only time I really need something to get uploaded quickly is to fix breakage, which I'd much prefer not to have happened in the first place. Hence: +1 for mandatory reviews.

@bgruening in #2826 (comment)

Lets move the discussion about mandatory review into a new thread (@epruesse, @mbargull do you want to do this?).