I will use this post to document how permissions are distributed among our tools.
We have the following groups:
- Steering group – handles setting up votes on matters that affect the whole collective. This includes large project changes, financial issues, and updates to statutes
- Development group – handles software development and associated tooling for all Funkwhale projects. Only members of this group may commit code to the codebase
- Moderation group – handles the moderation of the Funkwhale collective. They uphold the Funkwhale code of conduct in project spaces and establish moderation rules. This group has the right to exclude users from community spaces if they violate the code of conduct.
- Infrastructure group – handles the commissioning and maintenance of Funkwhale's server and network infrastructure. Only members of this group may make changes to infrastructure
- Documentation group – handles the documentation of all Funkwhale projects
- Communications group – handles promoting Funkwhale projects and communicating news
- Design group – handles the UI and UX design of all Funkwhale projects
Some initial thoughts and preconditions about those groups:
Although the main idea of the Collective is to have a collective ownership about the project and its assets, its a bad idea to grant every member full access to everything. There are serious data protection issues, security issues and trust issues. We therefore need some restrictions. I therefore tried to grant as much access as required for everyone to work without restrictions and as less as possible to avoid issues as described before.
Steering Group
The Steering Group is mandated to hold the ownership of the project. It needs to be able to manage membership and access to all tools. This needs to be considered when deciding about the access to our tools.
In order to do this, the members of the Steering Group get Admin Access to the Forum, Gitlab, Weblate, Mattermost, Penpot, Bitwarden, open.audio and Peertube.
Development Group
Development is mostly happening on Gitlab. My aim would be to have a process in place which requires everyone to get their changes approved, even members of the development group. Approval can be given by members of the development group, the main task is therefore to review changes from contributors. Gitlab still needs to be configured to do exactly this.
Moderation Group
All spaces that are regimented by our Code of Conduct needs to be moderatable by the Moderation Group. They therefore need moderation access to Flarum, Gitlab, open.audio, Mattermost and our Matrix Channels.
Infrastructure Group
Obviously the infrastructure group needs to have root access to our servers and admin access to our infrastructure in order to get the job done. This is mostly done by managing SSH Keys on the servers and access to the relevant passwords in Bitwarden.
Documentation group
It would be nice if changes to the documentation would require approval by at least one member of the Documentation Group. Whether or not Gitlab is able to be configured accordingly is yet to be evaluated. From my perspective no further access is required.
Communications Group
The communications has to approve blog posts and gets access to our social media channels through Bitwarden.
Design Group
The Design Group needs to have access to Penpot and needs to be able to attach their design drafts to Gitlab Issues.
I already started to play with Gitlab Permissions. Its probably messy right now, but that is expected. Its a hard transition to be made and hopefully everything will be much cleaner and more independent from me or whoever the project maintainer be in the future.
As always, I appreciate all input and feedback. Did I evaluated something totally wrong or is something missing? Let me know!