search

fatiando / community

Community resources, guidelines, meeting notes, authorship policy, maintenance, etc.
Other
8 stars 4 forks source link

Governance structure and community roles #76

Closed leouieda closed 1 year ago

leouieda commented 1 year ago

We've had some discussion of this for a while now but I really want to make a push for having an official governance structure and roles within the community. It doesn't have to be complicated and can have as many or as few roles as we think we need. I'm particularly keen to get this done so that we can better recognise community members doing work that isn't captured by GitHub (like participating in discussions, managing social media, the survey, etc). I really want these to be listed and celebrated in https://www.fatiando.org/community

Proposed structure

BDFL: Benevolent Dictator For Life = me. Not much power in this, mostly a tie breaker or making hard decisions if there is no consensus. Main responsibility is thinking about the long term vision, direction, and health of the project. And not necessarily for life (I name @santisoler as an obvious successor).

Steering Council: Responsible for keeping the project running, discussing directions, recruiting volunteers for the other roles, organising events, making funding applications, etc. Would be people who are heavily involved in the project (participate in development/chat/calls/discussions). We can name some people to start and then implement a nomination and voting process for new members. This would be people like myself @santisoler @aguspesce @MGomezN @LL-Geo @mdtanker etc.

Community Managers: Responsible for breathing life into our community. Includes organising the weekly call (sending a reminder, changing time if needed, inviting specific people to attend, etc), managing social media accounts, welcoming new people to our community, approaching specific groups for engagement (Geolatinas, ESWN, and the like come mind), putting together events, running the user survey, etc. (of course, no single person needs to do all of this). This would be people like @MGomezN @santisoler @aguspesce

Package Maintainers: Responsible for a particular packages direction, development, release, and PR review. Can be more than one per package (ideally at least 2). Permission should be given rather freely since my experience has been that people respond well to being given power and responsibility. Maintainers should be in the Council but don't have to if they don't want to. This would be people like myself @santisoler at the moment (we really need to recruit a bit better on this regard). This group would need admin level permission on GitHub and PyPI to make releases. There will be one group per package, though they will likely significantly overlap.

Project Contributors: Everyone else who is involved in the project in any way. For example, people who answer questions in the forum or chat, come to the calls, submit PRs, submit issues, writes tutorials, etc. No responsibility comes with this category and we're just happy to have them involved at all. Ideally the council, community managers, and maintainers are sourced from this pool.

Package Authors: The official authors of each software package. These are people who have contributed to a package and are in the AUTHORS.md files. The idea is that people will retain this even if stepping away from other roles. The processes for being included is laid out in our Authorship Guide.

How to implement this

  1. Decide on a Fatiando call if we want to do this and if this structure is acceptable.
  2. Create a GOVERNANCE.md file with the above role descriptions (better worded) and other information like how to make changes to it.
  3. Create GitHub teams for each role and assign the right people to each (except authors, who are sourced from the AUTHORS.md files).
  4. Make sure everyone has the right permissions to do what they need, including access to other accounts like social media.
  5. Add this information to the https://www.fatiando.org/community page, sourcing pictures, names, etc from the GitHub teams. This way, the teams are the only thing that need to be updated manually.

Reference

leouieda commented 1 year ago

The main purpose of this is to give more credit to people who are doing excellent work in our community. In particular, community managers tend to not have their work registered on GitHub and so end up being less visible. The second goal is to provide an actual title for people to put on their CVs as external (volunteer) roles. Hopefully this can help people transition into new careers or advance in the one they're in.

leouieda commented 1 year ago

Another resource to investigate https://investinopen.org/research/good-community-governance/

santisoler commented 1 year ago

Loved you put a lot of effort in this, we really need it to be more transparent.

There's one group of people that aren't laid out in these scheme: authors that have write permission in repos (can create branches in the upstream repo, manage issues and pull requests, make releases). The main difference with Maintainers is that they cannot manage the settings of the repos and won't have access to external certificates (PyPI, Zenodo, etc). Should we include a different tier for this people?

From an organizational point of view I think it's too much, but from a practical point of view sounds reasonable.

aguspesce commented 1 year ago

I understand your reasons to do this... I promise to read all the link to talk about this in the next meeting.

leouieda commented 1 year ago

Discussed and approved on our 2022/11/09 call: https://github.com/fatiando/community/blob/main/development-calls/2022.md#2022-11-09