Skip to content

Commit

Permalink
Create a GOVERNANCE document for our community (#78)
Browse files Browse the repository at this point in the history 
The document specifies the roles within our community, including their
responsibilities and how they are appointed. The document does not list
current holders of each role (except the BDFL and Founders), which will
be displayed on our website instead.
These rules were discussed and agreed upon during our 2022-11-09
community call
https://github.com/fatiando/community/blob/main/development-calls/2022.md#2022-11-09.
Draws on similar documents from SimPEG, Jupyter, Numpy, and SciPy.
  • Loading branch information
@leouieda
leouieda authored Mar 14, 2023
1 parent 63d08fe commit f0d3c48
Show file tree
Hide file tree
Showing 2 changed files with 258 additions and 3 deletions.
252 changes: 252 additions & 0 deletions GOVERNANCE.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,252 @@
# Fatiando a Terra Project Governance

The purpose of this document is to formalize the governance process used by the
project in both ordinary and extraordinary situations. It is also meant to
clarify how decisions are made, where the decision making power lies, and the
responsibilities of each role assigned to community members.

## The Project

The Fatiando a Terra Project (The Project) is a community-driven project that
develops and maintains open-source software for geophysics.
Software repositories include those in the [`fatiando`][github] and
[`fatiando-data`][github-data] GitHub organizations.
They are developed openly and hosted on public repositories.
Software developed by The Project is released under the BSD 3-clause (or
similar) open source license.

The Project is developed by a distributed team of developers, called
the Project Contributors (see below).
The Project Community consists of all Contributors and users of The Project.
Contributors work on behalf of and are responsible to the larger Project
Community.
We strive to keep the barrier between Contributors and users as low as
possible.

## Governance

> This section describes the governance and leadership model of The Project.
These are the roles that can be assigned to The Project Community members:

- Benevolent Director For Life (BDFL)
- Steering Council Member
- Community Managers
- Package Maintainer
- Package Author
- Project Contributor
- Project Founder

The individuals currently occupying each role will be listed on our website
[fatiando.org][website].

### Benevolent Director For Life (BDFL)

The Project will have a BDFL (Benevolent Dictator for Life).
The BDFL is chair of the Steering Council (see below) and has the same
responsibilities of other Council members.
In addition:

* As *Dictator*, they, have the authority to make all final decisions for The
Project.
* As *Benevolent*, they, in practice, chooses to defer that authority to the
consensus of the Community and Steering Council.

It is expected that the BDFL will only rarely assert their final authority.
Because it is rarely used, we refer to the BDFL's final authority as a
"special" or "overriding" vote.
When it does occur, the BDFL's override typically happens in situations where
there is a deadlock in building consensus among the Community.

The BDFL can step down at any time, and acting in good faith, will also listen
to serious calls to do so.
The BDFL can appoint their successor, but it is expected that the Steering
Council and the Community will be consulted on this decision.
If the BDFL is unable to appoint a successor, the Steering Council will make
this decision, preferably by consensus but, if needed, by a majority vote.

### Steering Council

The overall role of the Steering Council is to ensure, through working with the
BDFL and taking input from the Community, the long-term well-being of the
project, both technically and as a community.
It is expected that all communication between the Council will be carried out
in the open through one of The Project's [communication channels][contact].

The Council are responsible for planning, organization, and direction of The
Project's operations and programs.
There is an expectation that Steering Council members will attend regular
online meetings and invest effort in community and organizational strategy, as
well as developing and acting on the long-term vision of The Project.
The Steering Council may delegate their authority on a particular decision or
set of decisions to any other Contributor at their discretion.
The Project encourages others to fork the project if they disagree with the
overall direction the Council is taking.

To become eligible for being a Steering Council Member, an individual must be a
Project Contributor who has produced contributions that are substantial in
quality and quantity, and sustained over at least one year.
Contributions include, but are not limited to, code, code review,
infrastructure work, community participation, community help/building,
education and outreach, design work, etc.
We want to encourage a diverse array of backgrounds, viewpoints, and talents in
our team.
Potential Council Members will be nominated by existing Council Members and
voted upon by the existing Council.
Based on a successful vote, the newly elected Member is invited to serve in
that capacity.
A newly elected Member will be mentored in their role by an existing Council
Member (appointed by the Council) until they feel that the mentorship is no
longer required.
The initial Steering Council was appointed by the BDFL (Leonardo Uieda) in
2022.

If a Council member becomes inactive in the project for a period of one year,
they will be considered for removal from the Council.
Before removal, the inactive Member will be approached by the BDFL to see if
they plan on returning to active participation.
If not, they will be removed immediately upon a Council vote.
If they plan on returning to active participation, they will be given a grace
period of one year.
If they don't return to active participation within that time period, they will
be removed by vote of the Council.
Former Council members will be listed on the project website, acknowledging the
period during which they were active in the Council.

The Council reserves the right to eject current Members if they are deemed to
be actively harmful to the project's well-being, and attempts at communication
and conflict resolution have failed.

### Community Managers

The main role of the Community Managers is to breath life into our Community.
Community Managers are responsible for, among other things,
promoting attendance at regular community calls, managing social media
accounts, welcoming new people to the Community, approaching specific groups
for engagement and partnership with The Project (e.g., Geolatinas, Earth
Science Women's Network), putting together
community events, running the user survey, etc.
Of course, no single Community Manager will be responsible for all of these
activities.
Sub-committees can be formed at the discretion of the current Community
Managers to delegate responsibility for certain activities to other Project
Contributors.
Community Managers are appointed by the Steering Council upon suggestion from
the Community or self-nomination by potential candidates.
A newly appointed Community Manager will be mentored in their role by an
existing Community Manager and/or Steering Council Member until they feel that
the mentorship is no longer required.

Community Managers will have administrative access to the accounts and
repositories that are required to fulfil their roles.
It is expected that they will employ standard IT safety procedures to secure
passwords and account information (using a password manager, enabling
two-factor authentication, avoiding duplication of passwords, etc).

### Package Maintainers

The Package Maintainers oversee and manage the development, maintenance,
goals, and scope of a particular software package.
Each of the software packages developed by The Project will have a team of
Package Maintainers.
Their responsibilities are:

* Welcoming new contributors to the software.
* Reviewing contributions to the software in the form of pull requests, issues,
and discussions.
* Maintaining the health and viability of the software.
* Managing the release of new versions of the software.
* Delegating responsibility for development and review to other Project
Contributors.
* Recruiting and mentoring new Maintainers and Contributors

Package Maintainers are appointed by existing Package Maintainers for the
particular software upon consultation with the Steering Council.
To be eligible for appointment as a Package Maintainer, an individual must be a
Project Contributor who has produced code contributions to the software that
are substantial in quality and quantity, and sustained over at least one year.
The Steering Council can also appoint a Package Maintainer in special
circumstances, for example of a software has no currently acting Maintainer.
Maintainers can step down from their role at any time.
It is expected that they will notify the Steering Council and fellow
Maintainers with at least one month notice so that a replacement can be
appointed if required.

Package Maintainers will have administrative access to the software repository
and package distribution services (PyPI, conda-forge) for which they are
responsible.
It is expected that they will employ standard IT safety procedures to secure
shared passwords and their own accounts (using a password manager, enabling
two-factor authentication, avoiding duplication of passwords, etc).

### Package Authors

The Package Authors are the official authors and copyright holders for each
software package developed by The Project.
Package Authors are listed in the `AUTHORS.md` file of each software repository.
The processes and rules for becoming a Package Author are laid out in our
[Authorship Guide][authorship].

### Project Contributors

The Project Contributors are anyone who has made a contribution to The Project.
Contributions include, but are not limited to, code, code review,
infrastructure work, community participation, community help/building,
education and outreach, design work, etc.
Anyone can be a Contributor and Contributors can be affiliated with any legal
entity or none.

There are no responsibilities or powers assigned to Project Contributors.
Candidates for the other roles in The Project governance are mostly recruited
from the pool of Project Contributors.

### Project Founders

The Project Founders are the people who played a role in the conceptualization
of The Project.
They hold no special authority in The Project and are included as an
acknowledgement of their contribution.

## Changes to this document

We will hold an annual meeting dedicated to discussions of The Project
governance.
At these meetings, we will review governance documents, including this
document, and the overall goals and direction of The Project.
Anyone is welcome to join these meetings.

The authority to change the governance model is held by the Steering Council.
Any changes to the governance model will be done in a consensus building
process between the Steering Council, BDFL, Project Contributors and the
Community.

Suggestions to governance processes can always be raised in the interim through
one of our [communication channels][contact] or directly to a member of the
Steering Council.

## Acknowledgement

Substantial portions of this document were adapted from:

* [SimPEG governance document][simpeg]
* [Jupyter/IPython project governance document][jupyter]
* [NumPy governance document][numpy]
* [SciPy governance document][scipy]

## License

To the extent possible under law, the authors have waived all copyright and
related or neighboring rights to the Fatiando a Terra project governance
document, as per the [CC-0 public domain dedication / license][cc0].

<!-- Links -->
[cc0]: https://creativecommons.org/publicdomain/zero/1.0/
[simpeg]: https://github.com/simpeg/community/blob/main/governance.md
[jupyter]: https://github.com/jupyter/governance/blob/master/governance.md
[numpy]: https://github.com/numpy/numpy/blob/master/doc/source/dev/governance/governance.rst
[scipy]: https://docs.scipy.org/doc/scipy/reference/dev/governance/governance.html
[github]: https://github.com/fatiando
[github-data]: https://github.com/fatiando-data
[contact]: https://www.fatiando.org/contact
[website]: https://www.fatiando.org
[authorship]: https://github.com/fatiando/community/blob/main/AUTHORSHIP.md
9 changes: 6 additions & 3 deletions README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,12 +5,12 @@ guidelines, meeting notes, a place to organize project wide maintenance, etc.

## Weekly calls (open to everyone)

* 📜 **Meeting notes & agenda**: https://hackmd.io/@fatiando/development-calls-2022
* 📜 **Meeting notes & agenda**: https://hackmd.io/@fatiando/development-calls-2022
* 📅 **Shared calendar**: https://www.fatiando.org/calendar

We meet up **weekly** to discuss project development, get to know each other,
share experiences, and even **code things live** to show our process.
They are a great way to learn more about day-to-day development and get to
They are a great way to learn more about day-to-day development and get to
know our global community.
It's absolutely fine to join and just listen to what we discuss
but we welcome participation!
Expand All @@ -20,7 +20,7 @@ on how to connect. We post links to the join the call and reminders on our
chat rooms so keep an eye out!

Meeting notes are archived in the `development-calls` folder of this repository.
Please **do not edit these directly**. Use the HackMD link above instead
Please **do not edit these directly**. Use the HackMD link above instead
(changes there get synced to this repository periodically).

## Code of Conduct
Expand All @@ -43,6 +43,9 @@ performing maintenance, establishing authorship, and more:
archives and publications
* [Maintainers Guide](MAINTENANCE.md): procedures for maintenance tasks like
handling pull requests, making releases, etc.
* [Governance Structure](GOVERNANCE.md): how the project is organized and
managed by our community, the various roles we occupy, and how to participate
in project governance.

Please feel free to use these files for your own projects.
**If you make any changes that aren't specific to your project,
Expand Down

0 comments on commit f0d3c48

Please sign in to comment.