Add EEP-00: Governance Model and Code of Conduct (#307)

CHANGES.md

@@ -4,6 +4,20 @@ This is a record of all past estimagic releases and what went into them in rever
 chronological order. We follow [semantic versioning](https://semver.org/) and all
 releases are available on [Anaconda.org](https://anaconda.org/OpenSourceEconomics/estimagic).
 
+
+## 0.4.1
+
+- {gh}`307` Adopts a code of condact and governance model
+- {gh}`384` Polish documentation ({ghuser}`janosg` and {ghuser}`mpetrosian`)
+- {gh}`374` Moves the documentation to MyST ({ghuser}`baharcos`)
+- {gh}`365` Adds copybuttos to documentation ({ghuser}`amageh`)
+- {gh}`371` Refactors the pounders algorithm ({ghuser}`segsell`)
+- {gh}`369` Fixes CI ({ghuser}`janosg`)
+- {gh}`367` Fixes the linux environment ({ghuser}`timmens`)
+- {gh}`294` Adds the very first experimental version of tranquilo ({ghuser}`janosg`,
+  {ghuser}`timmens`, {ghuser}`segsell`, {ghuser}`mpetrosian`)
+
+
 ## 0.4.0
 
 - {gh}`366` Update  ({ghuser}`segsell`)

CODE_OF_CONDUCT.md

@@ -0,0 +1,132 @@
+## Code of Conduct
+
+### Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, religion, or sexual identity
+and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
+
+### Our Standards
+
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+* Demonstrating empathy and kindness toward other people
+* Being respectful of differing opinions, viewpoints, and experiences
+* Giving and gracefully accepting constructive feedback
+* Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience
+* Focusing on what is best not just for us as individuals, but for the
+  overall community
+
+Examples of unacceptable behavior include:
+
+* The use of sexualized language or imagery, and sexual attention or
+  advances of any kind
+* Trolling, insulting or derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or email
+  address, without their explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+### Enforcement Responsibilities
+
+Community leaders are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
+
+Community leaders have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, and will communicate reasons for moderation
+decisions when appropriate.
+
+### Scope
+
+This Code of Conduct applies within all community spaces, on all formal and
+informal events, and also applies when an individual is officially representing
+the community in public spaces. Examples of representing our community include
+- using an official e-mail address
+- posting via an official social media account
+- acting as a representative at an online or offline event
+- acting as a representative surrounding an event
+
+### Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the community leaders responsible for enforcement. You can contact
+either [Mariam Petrosyan](https://github.com/mpetrosian)
+([email protected]) or [Tim Mensinger](https://github.com/timmens)
+([email protected]). All complaints will be reviewed and investigated
+promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the
+reporter of any incident.
+
+### Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining
+the consequences for any action they deem in violation of this Code of Conduct:
+
+#### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed
+unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing
+clarity around the nature of the violation and an explanation of why the
+behavior was inappropriate. A public apology may be requested.
+
+#### 2. Warning
+
+**Community Impact**: A violation through a single incident or series
+of actions.
+
+**Consequence**: A warning with consequences for continued behavior. No
+interaction with the people involved, including unsolicited interaction with
+those enforcing the Code of Conduct, for a specified period of time. This
+includes avoiding interactions in community spaces as well as external channels
+like social media. Violating these terms may lead to a temporary or
+permanent ban.
+
+#### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including
+sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public
+communication with the community for a specified period of time. No public or
+private interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, is allowed during this period.
+Violating these terms may lead to a permanent ban.
+
+#### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behavior,  harassment of an
+individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within
+the community.
+
+### Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 2.0, available at
+https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
+
+Community Impact Guidelines were inspired by [Mozilla's code of conduct
+enforcement ladder](https://github.com/mozilla/diversity).
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see the FAQ at
+https://www.contributor-covenant.org/faq. Translations are available at
+https://www.contributor-covenant.org/translations.

MANIFEST.in

@@ -9,6 +9,7 @@
 include CITATION
 include LICENSE
 include CHANGES.md
+include CODE_OF_CONDUCT.md
 
 recursive-include src *.css
 recursive-include src *.csv

README.md

@@ -10,6 +10,7 @@
 [![image](https://codecov.io/gh/OpenSourceEconomics/estimagic/branch/main/graph/badge.svg)](https://codecov.io/gh/OpenSourceEconomics/estimagic)
 [![image](https://results.pre-commit.ci/badge/github/OpenSourceEconomics/estimagic/main.svg)](https://github.com/OpenSourceEconomics/estimagic/actions?query=branch%3Amain)
 [![image](https://img.shields.io/badge/code%20style-black-000000.svg)](https://github.com/psf/black)
+[![image](https://img.shields.io/badge/Contributor%20Covenant-2.1-4baaaa.svg)](CODE_OF_CONDUCT.md)
 
 
 ## Introduction

docs/source/development/changes.md

@@ -1,5 +1,3 @@
 (changes)=
-# Changes
-```{eval-rst}
-.. include:: ../../../CHANGES.md
+```{include} ../../../CHANGES.md
 ```

docs/source/development/code_of_conduct.md

@@ -0,0 +1,3 @@
+(coc)=
+```{include} ../../../CODE_OF_CONDUCT.md
+```

docs/source/development/eep-00-governance-model.md

@@ -0,0 +1,159 @@
+(eep-00)=
+
+
+# EEP-00: Governance model & code of conduct
+
+```{eval-rst}
++------------+------------------------------------------------------------------+
+| Author     | `Maximilian Blesch <https://github.com/MaxBlesch>`_,             |
+|            | `Janoś Gabler <https://github.com/janosg>`_,                     |
+|            | `Hans-Martin von Gaudecker <https://github.com/hmgaudecker>`_,   |
+|            | `Annica Gehlen <https://github.com/amageh>`_,                    |
+|            | `Sebastian Gsell <https://github.com/segsell>`_,                 |
+|            | `Tim Mensinger <https://github.com/timmens>_,                    |
+|            | `Mariam Petrosyan <https://github.com/mpetrosian>`_,             |
+|            | `Tobias Raabe <https://github.com/tobiasraabe>`_,                |
+|            | `Klara Röhrl <https://github.com/roecla>`_                       |
++------------+------------------------------------------------------------------+
+| Status     | Accepted                                                         |
++------------+------------------------------------------------------------------+
+| Type       | Standards Track                                                  |
++------------+------------------------------------------------------------------+
+| Created    | 2022-04-28                                                       |
++------------+------------------------------------------------------------------+
+| Resolution |                                                                  |
++------------+------------------------------------------------------------------+
+```
+
+## Purpose
+
+This document formalizes the estimagic code of conduct and governance model. In case
+of changes, this document can be updated following the estimagic Enhancement Proposal
+process detailed below.
+
+
+
+```{include} ../../../CODE_OF_CONDUCT.md
+```
+
+## estimagic governance model
+
+### Summary
+
+The governance model strives to be lightweight and based on
+[consensus](https://numpy.org/doc/stable/dev/governance/governance.html#consensus-based-decision-making-by-the-community)
+of all interested parties. Most work happens in GitHub issues and pull requests (regular
+decision process). Any interested party can voice their concerns or veto on proposed
+changes. If this happens, the estimagic Enhancement Proposal (EEP) process can be used
+to iterate over proposals until consesus is reached (controversial decision process). If
+necessary, members of the steering council can moderate heated debates and help to
+broker a consensus.
+
+### Regular decision process
+
+Most changes to estimagic are additions of new functionality or strict improvements of
+existing functionality. Such changes can be discussed in GitHub issues and discussions
+and implemented in pull requests. They do not require an estimagic Enhancement Proposal.
+
+Before starting to work on estimagic, contributors should read [how to
+contribute](how-to) and the [styleguide](styleguide). They can also reach out to
+existing contributors if any help is needed or anything remains unclear. We are all
+happy to help onboarding new contributors in any way necessary. For example, we have
+given introductions to git and GitHub in the past to help people make a contribution to
+estimagic.
+
+Pull requests should be opened as soon as work is started. They should contain a good
+description of the planned work such that any interested party can participate in the
+discussion around the changes. If planned changes turn out to be controversial, their
+design should be discussed in an estimagic Enhancement Proposal before the actual work
+starts. When the work is finished, the author of a pull request can request a review. In
+most cases, previous discussions will show who is a suitable reviewer. If in doubt, tag
+[janosg](https://github.com/janosg). Pull requests can be merged if there is at least
+one approving review.
+
+Reviewers should be polite, welcoming and helpful to the author of the pull request who
+might have spent many hours working on the changes. Authors of pull requests should keep
+in mind that reviewers' time is valuable. Major points should be discussed
+publicly on GitHub, but very critical feedback or small details can be moved to private
+discussions — if the latter are necessary at all (see [the bottom section of this blog
+post](https://rgommers.github.io/2019/06/the-cost-of-an-open-source-contribution/) for
+an excellent discussion of the burden that review comments place on maintainers, which
+might not always be obvious). Video calls can help if a discussion gets stuck. The code
+of conduct applies to all interactions related to code reviews.
+
+### estimagic Enhancement Proposals (EEPs) / Controversial decision process
+
+Large changes to estimagic can be proposed in estimagic Enhancement Proposals, short
+EEPs. They serve the purpose of summarising discussions that may happen in chats,
+issues, pull requests, in person, or by any other means. Simple extensions (like adding
+new optimizers) do not need to be discussed with such a formal process.
+
+EEPs are written as markdown documents that become part of the documentation. Opening an
+EEP means opening a pull request that adds the markdown document to the documentation.
+It is not necessary to already have a working implementations for the planned changes,
+even though it might be a good idea to have rough prototypes for solutions to the most
+challenging parts.
+
+If the author of an EEP feels that it is ready to be accepted they need to make a post
+in the relevant [Zulip topic](https://ose.zulipchat.com) and a comment on the PR that
+contains the following information:
+
+1. Summary of all contentious aspects of the EEP and how they have been resolved
+2. Every interested party has seven days to comment on the PR proposing the EEP, either
+   with approval or objections. While only objections are relevant for the decision
+   making process, approvals are a good way to signal interest in the planned change and
+   recognize the work of the authors.
+3. If there are no unresolved objections after seven days, the EEP will automatically be
+   accepted and can be merged.
+
+Note that the pull requests that actually implement the proposed enhancements still
+require a standard review cycle.
+
+### Steering Council
+
+The estimagic Steering Council consists of five people who take responsibility for the
+future development of estimagic and the estimagic community. Being a member of the
+steering council comes with no special rights. The main roles of the steering council
+are:
+
+- Facilitate the growth of estimagic and the estimagic community by organizing community
+events, identifying funding opportunities and improving the experience of all community
+members.
+- Develop a roadmap, break down large changes into smaller projects and find
+contributors to work on the implementation of these projects.
+- Ensure that new contributors are onboarded and assisted and that pull requests are
+reviewed in a timely fashion.
+- Step in as moderators when discussions get heated, help to achieve consensus on
+controversial topics and enforce the code of conduct.
+
+The Steering Council is elected by the estimagic community during a community meeting.
+
+Candidates need to be active community members and can be nominated by other community
+members or themselves until the start of the election. Nominated candidates need to
+accept the nomination before the start of the election.
+
+If there are only five candidates, the Steering Council is elected by acclamation. Else,
+every participant casts five votes. The 5 candidates with the most votes become elected.
+Candidates can vote for themselves. Ties are resolved by a second round of voting where
+each participant casts as many votes as there are positions left. Remaining ties are
+resolved by randomization.
+
+Current memebers of the estimagic Steering Council are:
+- [Janoś Gabler](https://github.com/janosg)
+- [Annica Gehlen](https://github.com/amageh)
+- [Hans-Martin von Gaudecker](https://github.com/hmgaudecker)
+- [Tim Mensinger](https://github.com/timmens)
+- [Mariam Petrosyan](https://github.com/mpetrosian)
+
+
+### Community meeting
+
+Community meetings can be held to elect a steering council, make changes to the
+governance model or code of conduct, or to make other decisions that affect the
+community as a whole. Moreover, they serve to keep the community updated about the
+development of estimagic and get feedback.
+
+Community meetings need to be announced via our public channels (e.g. the [zulip
+workspace](https://ose.zulipchat.com) or GitHub discussions) with sufficient time until
+the meeting. The definition of sufficient time will increase with the size of the
+community.

docs/source/development/eep-01-pytrees.md

@@ -6,7 +6,7 @@
 +------------+------------------------------------------------------------------+
 | Author     | `Janos Gabler <https://github.com/janosg>`_                      |
 +------------+------------------------------------------------------------------+
-| Status     | Draft                                                            |
+| Status     | Accepted                                                         |
 +------------+------------------------------------------------------------------+
 | Type       | Standards Track                                                  |
 +------------+------------------------------------------------------------------+

docs/source/development/eeps.md

@@ -1,28 +1,14 @@
 # EEPs
 
-Large changes to estimagic can be proposed in estimagic enhancement proposals, short
-EEPs. They serve the purpose of summarising discussions
-that may happen in chats, issues, pull requests, in person, or by any other means.
-Simple extensions (like adding new optimizers) do not need to be discussed with such
-a formal process.
-
-If the author of an EEP feels that it is ready to be accepted they need to make a
-post in our [zulip workspace](https://ose.zulipchat.com) and a comment on the PR that
-contains the following information:
-
-1. Summary of all contentious aspects of the EEP and how they have been resolved
-2. Every interested party has seven days to comment on the PR proposing the EEP,
-   either with approval or objections.
-3. If there are no unresolved objections after seven days, the EEP will automatically
-   be accepted.
-
-Note that the Pull Requests that actually implement the proposed enhancements still
-require a standard review cycle.
+Estimagic Enhancement Proposals (EEPs) can be used to discuss and design large
+changes. EEP-00 details the EEP process, the estimagic governance model and the
+estimagic Code of Conduct. It is the only EEP that gets continuously updated.
 
 These EEPs are currently in place:
 
 ```{toctree}
 :maxdepth: 1
 
+eep-00-governance-model.md
 eep-01-pytrees.md
 ```

docs/source/development/index.md

@@ -3,6 +3,7 @@
 ```{toctree}
 :maxdepth: 1
 
+code_of_conduct
 how-to
 styleguide
 eeps