Data

Tools

Indexes

Applications

Experiments

Awesome

An open API service indexing awesome lists of open source software.

https://github.com/purescript/governance


https://github.com/purescript/governance

Last synced: 12 months ago
JSON representation

Awesome Lists containing this project

README 

          
# PureScript governance



## Purpose



The core PureScript GitHub organization ()

exists to maintain and develop:



*   The PureScript language (as defined by the implementation in the compiler

    repository, `purescript/purescript`), and the compiler itself

*   The PureScript core libraries (that is, the libraries under the

    `purescript` org on GitHub)

*   The PureScript website infrastructure (purescript.org, Try PureScript,

    Pursuit)

*   Documentation

*   Package Sets



## Project Values



*   PureScript is industrially focused; it is not a vehicle for programming

    language research. Consequently, stability is a high priority. Feature

    requests which have a large impact on downstream code are unlikely to be

    accepted.

*   Prefer fewer, more powerful features to many special-purpose ones. With a

    smaller feature set, things are easier to document, the implementation is

    easier to understand and work with, and features are less likely to

    interact poorly with one another.

*   Prefer to move slowly and consider decisions carefully, especially if they

    are likely to have a long-term impact.

*   If it is possible to adequately solve a need downstream of the compiler

    and/or core libraries, we are unlikely to add features for solving that

    need inside the compiler and/or core libraries.



## Roles



### Core Team Members



The core team leads the development of the language, compiler,

and core libraries. Since the language is defined by its implementation, the

compiler project and associated responsibilities are what largely shape its

direction and development.



The core organization team members are:



*   Gary Burgess ([@garyb](https://github.com/garyb))

*   Liam Goodacre ([@LiamGoodacre](https://github.com/LiamGoodacre))

*   Christoph Hegemann ([@kritzcreek](https://github.com/kritzcreek))

*   Hardy Jones ([@joneshf](https://github.com/joneshf))

*   Nathan Faubion ([@natefaubion](https://github.com/natefaubion))

*   Cyril Sobierajewicz ([@kl0tl](https://github.com/kl0tl))

*   Fabrizio Ferrai ([@f-f](https://github.com/f-f))

*   Verity Scheel ([@MonoidMusician](https://github.com/MonoidMusician))

*   Thomas Honeyman ([@thomashoneyman](https://github.com/thomashoneyman))

*   Nicholas Wolverson ([@nwolverson](https://github.com/nwolverson))

*   Ryan Hendrickson ([@rhendric](https://github.com/rhendric))

*   Justin Garcia ([@PureFunctor](https://github.com/PureFunctor))

*   Mike Solomon ([@mikesol](https://github.com/mikesol))



Core team members have demonstrated a long-term commitment to maintaining

central components of the ecosystem such as the compiler, core libraries,

tooling, or documentation resources, as well as engaging with the community as

a whole.



Core team members are expected to use their privileges responsibly, in order to

guide the development of the language, compiler, and core libraries in a way

that they feel best serves the community as a whole.



Core team membership is not predicated on responding to issues or pull requests in

any given timeframe; core team members may choose to involve themselves in the

development of the language, compiler, and libraries to whatever extent they

wish to. The reasoning for this is that we don't want any given maintainer to

feel pressured to do things that their life and schedules don't permit.



### Core Collaborators



Core team members may extend commit access on a project basis to those that have

expressed interest in maintaining a subset of the organization. Collaborators

include:



*   Alex Berg ([@chexxor](https://github.com/chexxor)) - Documentation, Infrastructure

*   Justin Woo ([@justinwoo](https://github.com/justinwoo)) - Package Sets

*   [@btrepp](https://github.com/btrepp) - Spago

*   Dennis Gosnell ([@cdepillabout](https://github.com/cdepillabout)) - Spago

*   Gareth Smith ([@Dretch](https://github.com/Dretch)) - Spago

*   Eric Ahlberg ([@eahlberg](https://github.com/eahlberg)) - Spago

*   Elliot Davies ([@elliotdavies](https://github.com/elliotdavies)) - Spago

*   Eric Thul ([@ethul](https://github.com/ethul)) - Core libraries

*   Jan Hrcek ([@jhrcek](https://github.com/jhrcek)) - Spago

*   Vladimir Kalnitsky ([@klntsky](https://github.com/klntsky)) - Spago

*   Steve Baker ([@stkb](https://github.com/stkb)) - Spago

*   Valtteri Pajunen ([@vapaj](https://github.com/vapaj)) - Spago

*   Colin Wahl ([@colinwahl](https://github.com/colinwahl)) - Registry, Spago

*   Miles Frain ([@milesfrain](https://github.com/milesfrain)) - Book



Collaborators are encouraged to help out with maintenance in any of the

following ways (or however else they see fit):



*   Merging PRs if they are ready to be merged (see below)

*   Managing the issue tracker (labelling, closing, or otherwise tidying up

    issues)

*   Discussing proposed features or bug reports

*   Sending PRs

*   Reviewing PRs



### Role Changes



*   Core team members may choose to step down and become core collaborators, or choose to leave the organization entirely, at any time.

*   Core collaborators may be promoted to core team members at the discretion of the rest of the core team members.



#### Onboarding checklist



Checklist of things that will need to happen when a new Core Team member is inducted:

- Add them to the Core Team on GitHub

- Add them to the Core Team on Discord

- Open a Pull Request to this document to add them to the list

- Announcement on Discourse



## Making Decisions



Most decisions which directly concern the language, compiler, or core libraries

should receive the approval of the core team members. For example, this would apply

to:



*   Feature requests

*   Concerns raised during pull request review

*   Adding new collaborators

*   Promoting collaborators to core team members

*   Changes to governance



For a decision to be made, it should receive the approval of all core team members

who choose to participate in the discussion. In essence, every core owner has a

veto (which they are expected to use responsibly).



Not all core team members are required to participate in every discussion -- it is

expected that most discussions will only involve a subset of the core team members.

Before any particular decision is finalized, sufficient time should be given so

that people have an opportunity to object, especially for decisions which would

be difficult to reverse later. In general, the length of time that is

considered "sufficient" depends on the magnitude of the decision, and core

core team members are expected to use their judgement. If a month has passed since the

first approval by a core owner, and no other core team members have objected in that

time, a decision can always be considered to have been approved.



Core team members have the final say in decisions, although they are expected to be

receptive to the needs of the wider community.



## Internal Discussions



Non-public privacy-respecting discussions can be found via the following team-based discussion boards:

- [Core Team Discussions](https://github.com/purescript/core-team-discussions/discussions)

- [Infrastructure Team Discussions](https://github.com/purescript/infra-team-discussions/discussions)

- [Compiler Team Discussions](https://github.com/purescript/compiler-team-discussions/discussions)



## Pull Requests



Before merging, pull requests on the compiler and core library repositories

should receive two approving code reviews: either from two core team members, or

from one core team member and one compiler/core libraries collaborator (as

appropriate, depending on the repository). If the PR submitter is a core team

member or compiler/core libraries collaborator, they can be assumed to have

approved it, and so the PR would only need one more approval before it could be

merged.