Need to have proper permissions settings.

[maxulysse]

cf https://github.com/nf-core/dualrnaseq/pull/3

This PR was merge (there was actually enough agreements, but I still think it as been merged) by someone who is on slack but not on the channel for this pipeline and who I haven't seen any comment on the PR in question either. Not sure of the current involvement in the project. From what I understood, this issue has happened already with the kmermaid pipeline too. So I really think that stricter permissions settings should be enforced especially for merging PR. I'm tagging the @nf-core/core team for now, but any idea is welcome.

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like A clear and concise description of what you want to happen.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Additional context Add any other context or screenshots about the feature request here.

[maxulysse]

For the moment, my ideas are:

• Having a team for each pipeline, as we currently have for eager and sarek. It'll be easy to control who does what, and the main devs can really control who does what. Main inconvenience, it has to be done for each pipeline, and probably for tools, website, etc...

• Having an extra team of trusted people that will merge PR

• Waiting for other people to come up with better ideas

[ewels]

Currently we have two teams - nf-core/core and nf-core/all (Omitting the @ symbols to avoid pinging everyone).

I have thought about making teams for every pipeline, but I wonder if that’s overkill? I think it’s less overhead to just add contributors to the pipeline. Only extras with the teams is that a pipeline team can be pinged and also reviews can be assigned. But either could work.

If we remove write permissions for nf-core/all then I think that there is definitely scope for a middle team of trusted contributors who are active members of the community and understand the way we work.

What we should definitely do is read into the fine-grained permissions available on GitHub. I think that there are many more levels available now than there were when we started the organisation. So there might be some good middle ground there.