Document the roles of F-Droid members on the website

F-Droid is a big team and we have many members. It's not clear who is in charg of which part. I thought we should document all roles in the team, including the maintainers of different repos, the admin of the accounts and channels, reviewers of translation, and other roles. This can make the F-Droid team more transparent.

I like this idea.

We already have a portion of this overview in the wiki, so we probably should merge this information to the new overview.

Per the board's roles and regulations:

The Technical Lead is responsible for publishing the list of current Core Developers on the website of F-Droid.

And this slightly broader topic was brought up in yesterday's board meeting:

Clarify procedures core contributors must follow to gain access to various accounts and internal teams (e.g. outreach and the official mastodon account) and document current access and members. Also to avoid inconsistent application as it would be unfortunate if some team members are required to jump through more hoops than others for the same access.

This was considered something the board's governance subcommittee should look into (cc @fdroid/board).

I think we should follow Debian's example here. It names the teams and describes in detail about what the responsibility of the team is. I don't think we want to widely broadcast who is on which team for all things. For certain teams, that's like putting a target on their head for hackers to follow.

I don't think we want to widely broadcast who is on which team for all things.

That information should be available internally though.

For certain teams, that's like putting a target on their head for hackers to follow.

The members of a repo are public anyway. Not sure which team should be hidden.

Like people running servers, people who have access to change key things like the domain name registrar, mail service, hosting, etc.

I totally agree it should be internally available. Debian maintains a private DD-only database for that.

I agree with @eighthave and @obfusk here:

• list of core contributors is public
• list of what teams exist (like outreach, comco etc) should be public, but not mentioning its members (publicly) for the reasons given by Hans
• list of teams with their members mentioned should be available internally, access level "team members" (r/o) and maybe "developer+" (r/w)
• procedures for application, conditions/prerequisites/requirements etc should be available at least to all team members, so this is transparent at least internally.

list of what teams exist (like outreach, comco etc) should be public, but not mentioning its members (publicly) for the reasons given by Hans

I agree that some teams should not have their members listed publicly. But you might want to choose different examples as the comco team members have been announced publicly and outreach can pretty much be deduced from #430 (closed).

We should probably make it explicit when teams' member lists are not supposed to be public.

We should probably make it explicit when teams' member lists are not supposed to be public.

So that we know to keep discussions & issues leaking such information internal.

If a team should be a secret, there should be a good reason. I thought it makes no sense to hide the member for most teams.

I'm a fan of adapting Kerchoff's Principle to as much as we can.