├── .editorconfig ├── .gitignore ├── .npmrc ├── .prettierignore ├── code-of-conduct.md ├── data ├── humans.yml └── teams.yml ├── decisions.md ├── invoices ├── 0000-template.md ├── 2019-04-16-johno.md ├── 2019-05-31-wooorm.md ├── 2019-07-01-wooorm.md ├── 2019-07-31-wooorm.md ├── 2019-08-31-wooorm.md ├── 2019-09-30-wooorm.md ├── 2019-10-31-wooorm.md ├── 2021-06-01-wooorm.md ├── 2021-07-02-wooorm.md ├── 2021-08-31-wooorm.md ├── 2021-09-30-wooorm.md ├── 2021-10-31-wooorm.md ├── 2021-11-30-wooorm.md ├── 2021-12-31-wooorm.md ├── 2022-01-31-wooorm.md ├── 2022-03-31-wooorm.md ├── 2022-04-30-wooorm.md ├── 2022-07-17-jounqin.md ├── 2023-01-31-wooorm.md ├── 2023-03-31-wooorm.md ├── 2023-04-30-wooorm.md ├── 2023-05-31-wooorm.md ├── 2023-06-30-wooorm.md ├── 2023-07-31-wooorm.md ├── 2023-09-01-wooorm.md ├── 2023-09-30-wooorm.md ├── 2023-10-06-murderlon.md ├── 2023-10-31-wooorm.md ├── 2024-07-31-wooorm.md ├── 2024-09-02-wooorm.md ├── 2024-10-01-wooorm.md ├── 2024-11-01-wooorm.md ├── 2024-12-02-wooorm.md ├── 2025-02-03-wooorm.md └── 2025-03-05-wooorm.md ├── members.md ├── moderation.md ├── organizations.md ├── package.json ├── permissions.md ├── readme.md ├── script └── list-of-humans.js └── tsconfig.json /.editorconfig: -------------------------------------------------------------------------------- 1 | root = true 2 | 3 | [*] 4 | charset = utf-8 5 | end_of_line = lf 6 | indent_size = 2 7 | indent_style = space 8 | insert_final_newline = true 9 | trim_trailing_whitespace = true 10 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | *.d.ts 2 | *.log 3 | *.map 4 | *.tsbuildinfo 5 | .DS_Store 6 | node_modules/ 7 | -------------------------------------------------------------------------------- /.npmrc: -------------------------------------------------------------------------------- 1 | ignore-scripts=true 2 | package-lock=false 3 | -------------------------------------------------------------------------------- /.prettierignore: -------------------------------------------------------------------------------- 1 | *.md 2 | -------------------------------------------------------------------------------- /code-of-conduct.md: -------------------------------------------------------------------------------- 1 | # Code of conduct 2 | 3 | ## Our pledge 4 | 5 | In the interest of fostering an open and welcoming environment, we as 6 | contributors and maintainers pledge to making participation in our collective 7 | and our community a harassment-free experience for everyone, regardless of age, 8 | body size, disability, ethnicity, sex characteristics, gender identity and 9 | expression, level of experience, education, socio-economic status, nationality, 10 | personal appearance, race, religion, or sexual identity and orientation. 11 | 12 | ## Our standards 13 | 14 | Examples of behavior that contributes to creating a positive environment 15 | include: 16 | 17 | * Using welcoming and inclusive language 18 | * Being respectful of differing viewpoints and experiences 19 | * Gracefully accepting constructive criticism 20 | * Focusing on what is best for the community 21 | * Showing empathy towards other community members 22 | 23 | Examples of unacceptable behavior by participants include: 24 | 25 | * The use of sexualized language or imagery and unwelcome sexual attention or 26 | advances 27 | * Trolling, insulting/derogatory comments, and personal or political attacks 28 | * Public or private harassment 29 | * Publishing others’ private information, such as a physical or electronic 30 | address, without explicit permission 31 | * Other conduct which could reasonably be considered inappropriate in a 32 | professional setting 33 | 34 | ## Our responsibilities 35 | 36 | Maintainers are responsible for clarifying the standards of acceptable behavior 37 | and are expected to take appropriate and fair corrective action in response to 38 | any instances of unacceptable behavior. 39 | 40 | Maintainers have the right and responsibility to edit, delete, hide, or lock 41 | code, comments, commits, edits, issues, posts, pull requests, and other 42 | contributions that are not aligned to this code of conduct, or to ban 43 | temporarily or permanently any contributor for other behaviors that they deem 44 | inappropriate, threatening, offensive, or harmful. 45 | 46 | ## Scope 47 | 48 | This code of conduct applies both within collective spaces and in public spaces 49 | when an individual is representing the collective or its community. 50 | Examples of representing a collective or community include using an official 51 | collective email address, posting via an official social media account, or 52 | acting as an appointed representative at an online or offline event. 53 | Representation of the collective may be further defined and clarified by 54 | maintainers. 55 | 56 | ## Enforcement 57 | 58 | Instances of abusive, harassing, or otherwise unacceptable behavior may be 59 | reported via the collective email address, `moderation@unifiedjs.com`, which 60 | will go to all moderators, or by contacting individual moderators via 61 | `richard@unifiedjs.com`, which will go only to Richard Littauer, or to 62 | `olivia@unifiedjs.com`, which will go only to Olivia Hugger. 63 | All complaints will be reviewed and investigated and will result in a response 64 | that is deemed necessary and appropriate to the circumstances. 65 | The moderation team is obligated to maintain confidentiality with regard to the 66 | reporter of an incident. 67 | Further details of specific enforcement policies may be posted separately. 68 | 69 | Maintainers who do not follow or enforce the code of conduct in good faith may 70 | face temporary or permanent repercussions as determined by other members of the 71 | collective leadership. 72 | 73 | In cases where community members transgress against the values in the code of 74 | conduct, members of the moderation team will use a three-strike warning system, 75 | where the aggressor will be warned twice before they are permanently excluded 76 | from our community spaces. 77 | This code applies to GitHub, Twitter, and any other space that this community 78 | uses for communication. 79 | For interactions between community members outside of this space, the code also 80 | applies if the interactions are reported and deemed to be interfering with 81 | community members safely working on the collective together. 82 | Conversations between moderators (when they are more serious than discussing 83 | simple warnings) will occur in private repositories or through email, to ensure 84 | both anonymity for reporters and the safety of the moderators. 85 | 86 | For more information on how to report violations and how the code of conduct is 87 | enforced, see our [moderation policy][moderation]. 88 | 89 | ## Attribution 90 | 91 | This code of conduct is adapted from the [Contributor Covenant][homepage], 92 | version 1.4, available at 93 | 94 | For answers to common questions about this code of conduct, see 95 | 96 | 97 | [homepage]: https://www.contributor-covenant.org 98 | 99 | [moderation]: moderation.md 100 | -------------------------------------------------------------------------------- /data/humans.yml: -------------------------------------------------------------------------------- 1 | # These folks have access to complete orgs. 2 | # For folks w/ access to specific repos, see: 3 | # 4 | - name: Adam Morse 5 | email: hi@mrmrs.cc 6 | url: https://mrmrs.cc 7 | github: mrmrs 8 | npm: mrmrs 9 | - name: Ahmad Awais 10 | email: me@AhmadAwais.com 11 | github: ahmadawais 12 | npm: mrahmadawais 13 | - name: Brent Jackson 14 | email: jxnblk@gmail.com 15 | url: https://jxnblk.com 16 | github: jxnblk 17 | npm: jxnblk 18 | - name: Christian Murphy 19 | email: christian.murphy.42@gmail.com 20 | github: ChristianMurphy 21 | npm: christianmurphy 22 | - name: Christopher Biscardi 23 | email: chris@christopherbiscardi.com 24 | url: https://www.christopherbiscardi.com 25 | github: ChristopherBiscardi 26 | npm: biscarch 27 | - name: Guillermo Rauch 28 | email: rauchg@gmail.com 29 | url: https://rauchg.com 30 | github: rauchg 31 | npm: rauchg 32 | - name: Jessica Stokes 33 | email: hello@jessicastokes.net 34 | github: ticky 35 | npm: ticky 36 | - name: John Otander 37 | email: johnotander@gmail.com 38 | url: http://johnotander.com 39 | github: johno 40 | npm: johno 41 | - name: Jonathan Haines 42 | email: jonno.haines@gmail.com 43 | github: BarryThePenguin 44 | npm: barrythepenguin 45 | - name: Joun Qin 46 | email: admin@1stg.me 47 | github: JounQin 48 | npm: jounqin 49 | - name: Junyoung Choi 50 | email: fluke8259@gmail.com 51 | url: https://rokt33r.github.io 52 | github: Rokt33r 53 | npm: rokt33r 54 | - name: Keith McKnight 55 | email: keith@mcknig.ht 56 | url: https://keith.mcknig.ht 57 | github: kmck 58 | npm: kmck 59 | - name: Laurie Barth 60 | url: https://laurieontech.dev/ 61 | github: laurieontech 62 | npm: laurieontech 63 | - name: Marouane Fazouane 64 | email: fazouanem3@gmail.com 65 | github: fazouane-marouane 66 | npm: fazouane-marouane 67 | - name: Matija Marohnić 68 | email: matija.marohnic@gmail.com 69 | url: https://silvenon.com 70 | github: silvenon 71 | npm: silvenon 72 | - name: Merlijn Vos 73 | email: merlijn@soverin.net 74 | github: Murderlon 75 | npm: murderlon 76 | - name: Mudit Ameta 77 | email: zeusdeux@gmail.com 78 | url: https://mudit.xyz 79 | github: zeusdeux 80 | npm: zeusdeux 81 | - name: Nikita Sobolev 82 | email: mail@sobolevn.me 83 | github: sobolevn 84 | npm: sobolevn 85 | - name: Olivia Hugger 86 | email: mokou@posteo.de 87 | github: komaeda 88 | npm: komaeda 89 | - name: Remco Haszing 90 | email: remcohaszing@gmail.com 91 | url: https://remcohaszing.nl 92 | github: remcohaszing 93 | npm: remcohaszing 94 | - name: Richard Littauer 95 | email: richard@maintainer.io 96 | url: https://burntfen.com 97 | github: RichardLitt 98 | npm: richardlitt 99 | - name: Sidhartha Chatterjee 100 | email: me@sidharthachatterjee.com 101 | url: http://sidharthachatterjee.com 102 | github: sidharthachatterjee 103 | npm: sidharthachatterjee 104 | - name: Stephan Schneider 105 | email: stephanschndr@gmail.com 106 | github: zcei 107 | npm: zcei 108 | - name: Tim Neutkens 109 | email: tim@vercel.com 110 | github: timneutkens 111 | npm: timneutkens 112 | - name: Titus Wormer 113 | email: tituswormer@gmail.com 114 | url: https://wooorm.com 115 | github: wooorm 116 | npm: wooorm 117 | - name: Victor Felder 118 | email: victor@draft.li 119 | url: https://draft.li 120 | github: vhf 121 | npm: vhf 122 | - name: Zeke Sikelianos 123 | email: zeke@sikelianos.com 124 | url: http://zeke.sikelianos.com 125 | github: zeke 126 | npm: zeke 127 | -------------------------------------------------------------------------------- /data/teams.yml: -------------------------------------------------------------------------------- 1 | # Teams have access to complete orgs. 2 | # For folks w/ access to specific repos, see: 3 | # 4 | - name: core 5 | collective: true 6 | humans: 7 | ChristianMurphy: maintainer 8 | johno: maintainer 9 | Murderlon: maintainer 10 | RichardLitt: contributor 11 | wooorm: maintainer 12 | zcei: contributor 13 | - name: moderation 14 | collective: true 15 | humans: 16 | komaeda: maintainer 17 | RichardLitt: maintainer 18 | - name: unified 19 | lead: wooorm 20 | humans: 21 | ChristianMurphy: merger 22 | johno: merger 23 | JounQin: merger 24 | Murderlon: merger 25 | Rokt33r: merger 26 | remcohaszing: releaser 27 | vhf: contributor 28 | wooorm: releaser 29 | zcei: contributor 30 | zeusdeux: contributor 31 | - name: remark 32 | lead: wooorm 33 | humans: 34 | BarryThePenguin: merger 35 | ChristianMurphy: merger 36 | fazouane-marouane: merger 37 | johno: releaser 38 | JounQin: merger 39 | kmck: merger 40 | Murderlon: merger 41 | remcohaszing: releaser 42 | Rokt33r: merger 43 | sobolevn: contributor 44 | vhf: merger 45 | wooorm: releaser 46 | zeke: merger 47 | zeusdeux: contributor 48 | - name: rehype 49 | lead: wooorm 50 | humans: 51 | ChristianMurphy: merger 52 | johno: merger 53 | JounQin: merger 54 | kmck: releaser 55 | Murderlon: merger 56 | remcohaszing: releaser 57 | vhf: contributor 58 | wooorm: releaser 59 | - name: retext 60 | lead: wooorm 61 | humans: 62 | Murderlon: merger 63 | RichardLitt: contributor 64 | wooorm: releaser 65 | - name: redot 66 | lead: ChristianMurphy 67 | humans: 68 | ChristianMurphy: releaser 69 | wooorm: releaser 70 | - name: micromark 71 | lead: wooorm 72 | humans: 73 | fazouane-marouane: merger 74 | johno: merger 75 | JounQin: merger 76 | Murderlon: merger 77 | remcohaszing: merger 78 | vhf: contributor 79 | wooorm: releaser 80 | zcei: contributor 81 | zeusdeux: contributor 82 | - name: mdx 83 | lead: johno 84 | humans: 85 | ahmadawais: contributor 86 | ChristopherBiscardi: merger 87 | johno: releaser 88 | JounQin: merger 89 | jxnblk: contributor 90 | laurieontech: merger 91 | mrmrs: contributor 92 | rauchg: contributor 93 | remcohaszing: releaser 94 | sidharthachatterjee: merger 95 | ticky: contributor 96 | timneutkens: releaser 97 | wooorm: releaser 98 | zcei: contributor 99 | - name: vfile 100 | lead: wooorm 101 | humans: 102 | ChristianMurphy: merger 103 | JounQin: merger 104 | komaeda: contributor 105 | Rokt33r: merger 106 | remcohaszing: merger 107 | wooorm: releaser 108 | - name: syntax tree 109 | lead: wooorm 110 | humans: 111 | BarryThePenguin: merger 112 | ChristianMurphy: merger 113 | JounQin: merger 114 | kmck: releaser 115 | Murderlon: merger 116 | remcohaszing: merger 117 | wooorm: releaser 118 | -------------------------------------------------------------------------------- /decisions.md: -------------------------------------------------------------------------------- 1 | # Decisions policy 2 | 3 | This document describes how members of the collective make decisions. 4 | It describes how initiatives can be brought forward through issues, pull 5 | requests, RFCs, and motions. 6 | The collective follows a, typically lazy, consensus-seeking decision-making 7 | process, with voting as a last resort. 8 | 9 | This document is developed by the unified collective core team. 10 | 11 | ## Table of contents 12 | 13 | * [Initiatives](#initiatives) 14 | * [Issues](#issues) 15 | * [RFCs](#rfcs) 16 | * [Motions](#motions) 17 | 18 | ## Initiatives 19 | 20 | ```text 21 | +-------------------+ 22 | | Does it impact | yes 23 | | roles of persons? +----------------------------------------+ 24 | +---------+---------+ | 25 | | no | 26 | +---------+---------+ | 27 | | Does it impact | | 28 | | management of | yes | 29 | | organizations or +--------------------------------------+ | 30 | | projects | | | 31 | +---------+---------+ | | 32 | | no | | 33 | +---------+---------+ | | 34 | | Does it impact | yes | | 35 | | multiple +---------------+ | | 36 | | organizations? | | | | 37 | +---------+---------+ | | | 38 | | no | | | 39 | +---------+---------+ | | | 40 | | Does it impact | yes | | | 41 | | multiple +-------------+ | | | 42 | | projects? | | | | | 43 | +---------+---------+ | | | | 44 | | no | | | | 45 | +---------+---------+ +--------+-+--------+ +--------+-+--------+ 46 | | Open a PR / issue | | Create an RFC | | Request a motion | 47 | +-------------------+ +-------------------+ +-------------------+ 48 | ``` 49 | 50 | The collective is a federated system of organizations, consisting in turn of 51 | small and highly interconnected projects, governed by different people with 52 | different interests. 53 | This means that centrally organizing decisions is rather tricky. 54 | The challenge thus rests in providing a decision system scoped towards both 55 | collective and organization teams, without compromising simplicity for either of 56 | them. 57 | 58 | Typically, decisions can be made through **issues** (and pull requests). 59 | For “substantial” initiatives, such as those affecting multiple projects or 60 | organizations, decisions are made through **RFC**s. 61 | If a decision affects management of projects or organizations, or the roles of 62 | persons within the collective, decisions are made through **motion**s. 63 | 64 | All persons participating in the collective must follow the code of conduct. 65 | This code provides the *minimum* of expected behavior in the community. 66 | It is understood and, in fact, *expected* that members will have and express 67 | individual opinions. 68 | If other members express concerns about initiatives, acknowledge their concerns 69 | by pausing, and discussing to come to a common agreement. 70 | Value a diversity of views and opinions. 71 | Everyone gets to speak up. 72 | Criticize ideas rather than people. 73 | Avoid preferential treatment and hold everyone (including yourself) accountable 74 | to the same set of standards. 75 | Treat the community and its members with respect, consideration, and the highest 76 | standards of ethical conduct. 77 | Take responsibility for the collective’s statements. 78 | 79 | The collective follows a, typically lazy, consensus-seeking decision-making 80 | process. 81 | 82 | The goal of **consensus** is that everyone (whose voice is recognized) agrees on 83 | a decision. 84 | **Consensus therefore results in an acceptable solution**, one that can be 85 | supported, even though it may not be the “favorite” of each individual. 86 | 87 | **Lazy consensus** does not require explicit approval from every member. 88 | Under lazy consensus a lack of objections is interpreted as a silent approval. 89 | 90 | **Consensus-seeking** is consensus with an additional option of a fallback vote 91 | if consensus appears unattainable during the process. 92 | 93 | In consensus-seeking, discussion of potential proposals is held first, followed 94 | by the framing of a solution, and then modifying it until the group reaches a 95 | consensus if there is no longer any disagreement. 96 | If agreement cannot be reached, the group votes. 97 | 98 | ### Issues 99 | 100 | Most initiatives can be initiated as issues or pull requests. 101 | Fixing a typo, reporting a bug, adding a new option, etc. 102 | 103 | Issues are, typically, a solution to an initiative. 104 | The decision to be made is whether the initiative makes sense for the project 105 | and whether the solution matches the criteria of the project. 106 | 107 | The process for deciding on issues and pull requests is lazy consensus. 108 | The wait time for an issue or pull requests starts when it is opened. 109 | It could be zero, such as for a typo, but it is recommended to last for two days 110 | (48 hours): it’s open for interpretation by maintainers. 111 | In case consensus is split between actively disagreeing factions, a vote is held 112 | to accept the initiative, requiring active agreement from the majority. 113 | 114 | ### RFCs 115 | 116 | Some initiatives are “substantial”, and we ask that these be put through a bit 117 | of a design process and produce a consensus among the community. 118 | 119 | An **RFC** (*request for changes* or *request for comments*, whichever you 120 | prefer) is a document written to justify a change or decision. 121 | RFCs are, typically, initiatives that have different solutions, one of which can 122 | be proposed. 123 | The decision to be made is to reach consensus for an initiative and around 124 | its solution. 125 | Once an RFC is accepted, the changes detailed in it can be implemented through 126 | issues and pull requests. 127 | 128 | For the collective, RFCs are kept in the [`unifiedjs/rfcs`][rfcs] repository. 129 | Consult its readme for detailed information on the RFC process. 130 | 131 | Anyone may propose an initiative, and anyone may voice their opinions, but only 132 | maintainers can object or vote. 133 | 134 | The process for deciding on RFCs is consensus seeking, with an emphasis on the 135 | discussion of potential proposals. 136 | The wait time for an RFC starts when a maintainer calls for the final comment 137 | period and lasts for three days (72 hours). 138 | In case consensus is split between actively disagreeing factions, a vote is held 139 | to accept the initiative, requiring active agreement from the majority. 140 | 141 | ### Motions 142 | 143 | Some initiatives affect the roles of persons in the collective or the management 144 | of projects. 145 | These are put through a process of a formal motion. 146 | 147 | A **motion** is a proposal from a person to a group that the group takes a 148 | certain action. 149 | The process for deciding on motions is a vote to accept the initiative, 150 | requiring agreement from the majority. 151 | The wait time for a motion starts when it is requested, and lasts for at least 152 | three days (72 hours), or longer, until a majority is reached or cannot be 153 | reached. 154 | 155 | | Scope | Topic | Name | Initiator | Voter | Enactor | 156 | | ------------ | ------- | -------------------------------- | -------------------------- | ---------- | ----------------- | 157 | | Collective | Person | Motion to nominate a contributor | Member | Core | Lead / maintainer | 158 | | Collective | Person | Motion to nominate a maintainer | Maintainer / ex-maintainer | Core | Lead / maintainer | 159 | | Collective | Person | Motion to nominate a releaser | Merger | Core | Lead / maintainer | 160 | | Collective | Person | Motion to be excused from duty | Maintainer | n/a | Lead / maintainer | 161 | | Collective | Project | Motion to delete a project | Member | Core | Lead | 162 | | Collective | Project | Motion to withdraw governance | Member | Core | Lead | 163 | | Collective | Person | Motion to prune | Lead / maintainer | Maintainer | Lead / maintainer | 164 | | Organization | Person | Motion to elect a lead | Lead | Maintainer | Lead | 165 | | Organization | Project | Motion to archive a project | Member | Maintainer | Lead | 166 | | Organization | Project | Motion to grant governance | Person | Maintainer | Lead | 167 | 168 | 169 | 170 | [rfcs]: https://github.com/unifiedjs/rfcs 171 | -------------------------------------------------------------------------------- /invoices/0000-template.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2000-00-00 4 | * **Person**: FULL\_NAME ([@GITHUB\_HANDLE](https://github.com/GITHUB_HANDLE)) 5 | * **Rate**: $HOURLY\_RATE/hr 6 | 7 | ## Items 8 | 9 | | Item | Description | Hours | Total | 10 | | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | ----- | ------- | 11 | | unifiedjs/collective | On the left hand side add a link to a relevant PR, GH organization, repo, or other link with your work. In this column describe it. | *XX* | **$YY** | 12 | 13 | *** 14 | 15 | * **Other relevant**: 16 | * **Links**: 17 | -------------------------------------------------------------------------------- /invoices/2019-04-16-johno.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2019-04-16 4 | * **Person**: John Otander ([@johno](https://github.com/johno)) 5 | * **Rate**: $40/hr (non-profit, open source discount) 6 | 7 | ## Items 8 | 9 | | Item | Description | Hours | Total | 10 | | --------------------------------------------------------- | ------------------------------------------------ | ----- | -------- | 11 | | [@mdx-js/mdx#451](https://github.com/mdx-js/mdx/pull/451) | Feature development and documentation for MDX v1 | *24* | **$960** | 12 | 13 | *** 14 | 15 | * **Release post**: 16 | * **Release tweet**: 17 | -------------------------------------------------------------------------------- /invoices/2019-05-31-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2019-05-31 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | * **Rate**: $40/hr (non-profit, open source discount) 6 | 7 | ## Items 8 | 9 | | Item | Description | Hours | Total | 10 | | ------------------ | ----------------------------- | ----- | ------------- | 11 | | unified collective | Development and support (May) | *110* | **$4,400.00** | 12 | 13 | *** 14 | 15 | * **Commits**: [2106](https://github.com/search?o=desc\&q=author%3Awooorm+committer-date%3A%222019-05-01..2019-06-01%22\&s=author-date\&type=Commits) 16 | * **Issues and PRs**: [42](https://github.com/search?o=desc\&q=author%3Awooorm+created%3A%222019-05-01..2019-06-01%22\&s=created\&type=Issues) 17 | * **Reviews**: [14](https://github.com/search?o=desc\&q=reviewed-by%3Awooorm+created%3A%222019-05-01..2019-06-01%22\&s=created\&type=Issues) 18 | -------------------------------------------------------------------------------- /invoices/2019-07-01-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2019-07-01 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | * **Rate**: $40/hr (non-profit, open source discount) 6 | 7 | ## Items 8 | 9 | | Item | Description | Hours | Total | 10 | | ------------------ | ------------------------------ | ----- | ------------- | 11 | | unified collective | Development and support (June) | *108* | **$4,320.00** | 12 | 13 | *** 14 | 15 | * **Commits**: [908](https://github.com/search?o=desc\&q=author%3Awooorm+committer-date%3A%222019-06-01..2019-07-01%22\&s=author-date\&type=Commits) 16 | * **Issues and PRs**: [29](https://github.com/search?o=desc\&q=author%3Awooorm+created%3A%222019-06-01..2019-07-01%22\&s=created\&type=Issues) 17 | * **Reviews**: [20](https://github.com/search?o=desc\&q=reviewed-by%3Awooorm+created%3A%222019-06-01..2019-07-01%22\&s=created\&type=Issues) 18 | -------------------------------------------------------------------------------- /invoices/2019-07-31-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2019-07-31 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | * **Rate**: $40/hr (non-profit, open source discount) 6 | 7 | ## Items 8 | 9 | | Item | Description | Hours | Total | 10 | | ------------------ | ------------------------------ | ----- | ------------- | 11 | | unified collective | Development and support (July) | *108* | **$4,320.00** | 12 | 13 | *** 14 | 15 | * **Commits**: [346](https://github.com/search?o=desc\&q=author%3Awooorm+committer-date%3A%222019-07-01..2019-08-01%22\&s=author-date\&type=Commits) 16 | * **Issues and PRs**: [16](https://github.com/search?o=desc\&q=author%3Awooorm+created%3A%222019-07-01..2019-08-01%22\&s=created\&type=Issues) 17 | * **Reviews**: [24](https://github.com/search?o=desc\&q=reviewed-by%3Awooorm+created%3A%222019-07-01..2019-08-01%22\&s=created\&type=Issues) 18 | -------------------------------------------------------------------------------- /invoices/2019-08-31-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2019-08-31 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | * **Rate**: $40/hr (non-profit, open source discount) 6 | 7 | ## Items 8 | 9 | | Item | Description | Hours | Total | 10 | | ------------------ | -------------------------------- | ----- | ------------- | 11 | | unified collective | Development and support (August) | *115* | **$4,600.00** | 12 | 13 | *** 14 | 15 | * **Commits**: [192](https://github.com/search?q=author%3Awooorm+committer-date%3A%222019-08-01..2019-09-01%22\&type=Commits) 16 | * **Issues and PRs**: [17](https://github.com/search?q=author%3Awooorm+created%3A%222019-08-01..2019-09-01%22\&type=Issues) 17 | * **Reviews**: [19](https://github.com/search?o=desc\&q=reviewed-by%3Awooorm+created%3A%222019-08-01..2019-09-01%22\&s=created\&type=Issues) 18 | -------------------------------------------------------------------------------- /invoices/2019-09-30-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2019-09-30 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | * **Rate**: $40/hr (non-profit, open source discount) 6 | 7 | ## Items 8 | 9 | | Item | Description | Hours | Total | 10 | | ------------------ | ----------------------------------- | ----- | ------------- | 11 | | unified collective | Development and support (September) | *110* | **$4,600.00** | 12 | 13 | *** 14 | 15 | * **Commits**: [44](https://github.com/search?q=author%3Awooorm+committer-date%3A%222019-09-01..2019-10-01%22\&type=Commits) 16 | * **Issues and PRs**: [19](https://github.com/search?q=author%3Awooorm+created%3A%222019-09-01..2019-10-01%22\&type=Issues) 17 | * **Reviews**: [6](https://github.com/search?q=reviewed-by%3Awooorm+created%3A%222019-09-01..2019-10-01%22\&type=Issues) 18 | -------------------------------------------------------------------------------- /invoices/2019-10-31-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2019-10-31 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | * **Rate**: $40/hr (non-profit, open source discount) 6 | 7 | ## Items 8 | 9 | | Item | Description | Hours | Total | 10 | | ------------------ | ----------------------------------- | ----- | ------------- | 11 | | unified collective | Development and support (September) | *115* | **$4,600.00** | 12 | 13 | *** 14 | 15 | * **Commits**: [216](https://github.com/search?q=author%3Awooorm+committer-date%3A%222019-10-01..2019-11-01%22\&type=Commits) 16 | * **Issues and PRs**: [21](https://github.com/search?q=author%3Awooorm+created%3A%222019-10-01..2019-11-01%22\&type=Issues) 17 | * **Reviews**: [37](https://github.com/search?q=reviewed-by%3Awooorm+created%3A%222019-10-01..2019-11-01%22\&type=Issues) 18 | -------------------------------------------------------------------------------- /invoices/2021-06-01-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2021-06-01 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | ------------------ | ----------------------------- | ------------- | 10 | | unified collective | Development and support (May) | **$4,600.00** | 11 | 12 | *** 13 | 14 | These numbers are since the previous invoice, which was on 2019-10-31. 15 | 16 | * **Commits**: 17 | [8324](https://github.com/search?q=author%3Awooorm+committer-date%3A%222019-11-01..2021-06-01%22%5C\&type=Commits) 18 | * **Issues and PRs**: [325](https://github.com/search?q=author%3Awooorm+created%3A%222019-11-01..2021-06-01%22%5C\&type=Issues) 19 | * **Reviews**: [321](https://github.com/search?q=reviewed-by%3Awooorm+created%3A%222019-11-01..2021-01-01%22\&type=Issues) 20 | -------------------------------------------------------------------------------- /invoices/2021-07-02-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2021-07-02 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | ------------------ | ------------------------------ | ------------- | 10 | | unified collective | Development and support (June) | **$4,600.00** | 11 | 12 | *** 13 | 14 | These numbers are since the previous invoice, which was on 2021-06-01. 15 | 16 | * **Commits**: 17 | [615](https://github.com/search?q=author%3Awooorm+committer-date%3A%222021-06-01..2021-07-02%22%5C\&type=Commits) 18 | * **Issues and PRs**: [14](https://github.com/search?q=author%3Awooorm+created%3A%222021-06-01..2021-07-02%22%5C\&type=Issues) 19 | * **Reviews**: [21](https://github.com/search?q=reviewed-by%3Awooorm+created%3A%222021-06-01..2021-07-02%22\&type=Issues) 20 | -------------------------------------------------------------------------------- /invoices/2021-08-31-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2021-08-31 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | ------------------ | -------------------------------- | ------------- | 10 | | unified collective | Development and support (August) | **$4,600.00** | 11 | 12 | *** 13 | 14 | These numbers are since the previous invoice, which was on 2021-07-02. 15 | 16 | * **Commits**: 17 | [2084](https://github.com/search?q=author%3Awooorm+committer-date%3A%222021-07-02..2021-08-31%22\&type=Commits) 18 | * **Issues and PRs**: [35](https://github.com/search?q=author%3Awooorm+created%3A%222021-07-02..2021-08-31%22\&type=Issues) 19 | * **Reviews**: [67](https://github.com/search?q=reviewed-by%3Awooorm+created%3A%222021-07-02..2021-08-31%22\&type=Issues) 20 | -------------------------------------------------------------------------------- /invoices/2021-09-30-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2021-09-30 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | ------------------ | ----------------------------------- | ------------- | 10 | | unified collective | Development and support (September) | **$4,600.00** | 11 | 12 | *** 13 | 14 | These numbers are since the previous invoice, which was on 2021-08-31. 15 | 16 | * **Commits**: 17 | [247](https://github.com/search?q=author%3Awooorm+committer-date%3A%222021-08-31..2021-09-30%22) 18 | * **Issues and PRs**: [68](https://github.com/search?q=author%3Awooorm+created%3A%222021-08-31..2021-09-30%22) 19 | * **Reviews**: [36](https://github.com/search?q=reviewed-by%3Awooorm+created%3A%222021-08-31..2021-09-30%22) 20 | -------------------------------------------------------------------------------- /invoices/2021-10-31-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2021-10-31 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | ------------------ | --------------------------------- | ------------- | 10 | | unified collective | Development and support (October) | **$4,600.00** | 11 | 12 | *** 13 | 14 | These numbers are since the previous invoice, which was on 2021-09-30. 15 | 16 | * **Commits**: 17 | [458](https://github.com/search?q=author%3Awooorm+committer-date%3A%222021-09-30..2021-10-31%22) 18 | * **Issues and PRs**: [68](https://github.com/search?q=author%3Awooorm+created%3A%222021-09-30..2021-10-31%22) 19 | * **Reviews**: [46](https://github.com/search?q=reviewed-by%3Awooorm+created%3A%222021-09-30..2021-10-31%22) 20 | -------------------------------------------------------------------------------- /invoices/2021-11-30-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2021-11-30 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | ------------------ | ---------------------------------- | ------------- | 10 | | unified collective | Development and support (November) | **$4,600.00** | 11 | 12 | *** 13 | 14 | These numbers are since the previous invoice, which was on 2021-10-31. 15 | 16 | * **Commits**: 17 | [491](https://github.com/search?q=author%3Awooorm+committer-date%3A%222021-10-31..2021-11-30%22) 18 | * **Issues and PRs**: [49](https://github.com/search?q=author%3Awooorm+created%3A%222021-10-31..2021-11-30%22) 19 | * **Reviews**: [47](https://github.com/search?q=reviewed-by%3Awooorm+created%3A%222021-10-31..2021-11-30%22) 20 | -------------------------------------------------------------------------------- /invoices/2021-12-31-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2021-12-31 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | ------------------ | ---------------------------------- | ------------- | 10 | | unified collective | Development and support (December) | **$4,600.00** | 11 | 12 | *** 13 | 14 | These numbers are since the previous invoice, which was on 2021-11-30. 15 | 16 | * **Commits**: [222](https://github.com/search?q=author%3Awooorm+committer-date%3A%222021-11-30..2021-12-31%22) 17 | * **Issues and PRs**: [31](https://github.com/search?q=author%3Awooorm+created%3A%222021-11-30..2021-12-31%22) 18 | * **Reviews**: [78](https://github.com/search?q=reviewed-by%3Awooorm+created%3A%222021-11-30..2021-12-31%22) 19 | -------------------------------------------------------------------------------- /invoices/2022-01-31-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2022-01-31 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | ------------------ | --------------------------------- | ------------- | 10 | | unified collective | Development and support (January) | **$4,600.00** | 11 | 12 | *** 13 | 14 | These numbers are since the previous invoice, which was on 2021-12-31. 15 | 16 | * **Commits**: [184](https://github.com/search?q=author%3Awooorm+committer-date%3A%222021-12-31..2022-01-31%22) 17 | * **Issues and PRs**: [33](https://github.com/search?q=author%3Awooorm+created%3A%222021-12-31..2022-01-31%22) 18 | * **Reviews**: [33](https://github.com/search?q=reviewed-by%3Awooorm+created%3A%222021-12-31..2022-01-31%22) 19 | -------------------------------------------------------------------------------- /invoices/2022-03-31-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2022-03-31 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | ------------------ | ------------------------------- | ------------- | 10 | | unified collective | Development and support (March) | **$4,600.00** | 11 | 12 | *** 13 | 14 | These numbers are since the previous invoice, which was on 2022-01-31. 15 | 16 | * **Commits**: [222](https://github.com/search?q=author%3Awooorm+committer-date%3A%222022-01-31..2022-03-31%22) 17 | * **Issues and PRs**: [13](https://github.com/search?q=author%3Awooorm+created%3A%222022-01-31..2022-03-31%22) 18 | * **Reviews**: [152](https://github.com/search?q=reviewed-by%3Awooorm+created%3A%222022-01-31..2022-03-31%22) 19 | -------------------------------------------------------------------------------- /invoices/2022-04-30-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2022-04-30 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | ------------------ | ------------------------------- | ------------- | 10 | | unified collective | Development and support (April) | **$4,600.00** | 11 | 12 | *** 13 | 14 | These numbers are since the previous invoice, which was on 2022-03-31. 15 | 16 | * **Commits**: [241](https://github.com/search?q=author%3Awooorm+committer-date%3A%222022-03-31..2022-04-30%22) 17 | * **Issues and PRs**: [14](https://github.com/search?q=author%3Awooorm+created%3A%222022-03-31..2022-04-30%22) 18 | * **Reviews**: [30](https://github.com/search?q=reviewed-by%3Awooorm+created%3A%222022-03-31..2022-04-30%22) 19 | -------------------------------------------------------------------------------- /invoices/2022-07-17-jounqin.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2022-07-17 4 | * **Person**: Jiaren Liu ([@JounQin](https://github.com/JounQin)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | -------------------- | -------------------------------------------- | --------- | 10 | | unifiedjs/collective | eslint-mdx development and support v1 and v2 | **$5000** | 11 | 12 | *** 13 | 14 | These numbers are since the init commit, which was on 2019-07-29. 15 | 16 | * **Commits**: [220](https://github.com/search?l=\&q=author%3AJounQin+committer-date%3A%222019-07-29..2022-06-30%22+repo%3Amdx-js%2Feslint-mdx\&type=commits) 17 | * **Issues and PRs**: [99](https://github.com/search?l=\&q=author%3AJounQin+committer-date%3A%222019-07-29..2022-06-30%22+repo%3Amdx-js%2Feslint-mdx+is%3Aissue\&type=issues) 18 | * **Reviews**: [28](https://github.com/search?q=reviewed-by%3AJounQin+created%3A%222019-07-29..2022-06-30%22+repo%3Amdx-js%2Feslint-mdx) 19 | -------------------------------------------------------------------------------- /invoices/2023-01-31-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2023-01-31 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | ------------------ | --------------------------------- | ------------- | 10 | | unified collective | Development and support (January) | **$4,800.00** | 11 | 12 | *** 13 | 14 | The numbers for this month: 15 | 16 | * **Commits**: [1311](https://github.com/search?q=author%3Awooorm+committer-date%3A%222022-12-31..2023-01-31%22) 17 | * **Issues and PRs**: [4](https://github.com/search?q=author%3Awooorm+created%3A%222022-12-31..2023-01-31%22) 18 | * **Reviews**: [46](https://github.com/search?q=reviewed-by%3Awooorm+created%3A%222022-12-31..2023-01-31%22) 19 | 20 | The numbers since the previous invoice, on 2022-04-30. 21 | 22 | * **Commits**: [3957](https://github.com/search?q=author%3Awooorm+committer-date%3A%222022-04-30..2023-01-31%22) 23 | * **Issues and PRs**: [64](https://github.com/search?q=author%3Awooorm+created%3A%222022-04-30..2023-01-31%22) 24 | * **Reviews**: [247](https://github.com/search?q=reviewed-by%3Awooorm+created%3A%222022-04-30..2023-01-31%22) 25 | -------------------------------------------------------------------------------- /invoices/2023-03-31-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2023-03-31 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | ------------------ | ------------------------------- | ------------- | 10 | | unified collective | Development and support (March) | **$4,800.00** | 11 | 12 | *** 13 | 14 | The numbers for this month: 15 | 16 | * **Commits**: [433](https://github.com/search?q=author%3Awooorm+committer-date%3A%222023-01-31..2023-03-31%22\&type=commits) 17 | * **Issues and PRs**: [29](https://github.com/search?q=author%3Awooorm+created%3A%222023-01-31..2023-03-31%22\&type=issues) 18 | ) 19 | -------------------------------------------------------------------------------- /invoices/2023-04-30-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2023-04-30 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | ------------------ | ------------------------------- | ------------- | 10 | | unified collective | Development and support (April) | **$4,800.00** | 11 | -------------------------------------------------------------------------------- /invoices/2023-05-31-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2023-05-31 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | ------------------ | ----------------------------- | ------------- | 10 | | unified collective | Development and support (May) | **$4,800.00** | 11 | 12 | *** 13 | 14 | The numbers for this month: 15 | 16 | * **Commits**: [323](https://github.com/search?q=author%3Awooorm+committer-date%3A%222023-04-30..2023-05-31%22\&type=commits) 17 | * **Issues and PRs**: [7](https://github.com/search?q=author%3Awooorm+created%3A%222023-01-31..2023-03-31%22\&type=issues) 18 | -------------------------------------------------------------------------------- /invoices/2023-06-30-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2023-06-30 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | ------------------ | ------------------------------ | ------------- | 10 | | unified collective | Development and support (June) | **$4,800.00** | 11 | 12 | *** 13 | 14 | The numbers for this month: 15 | 16 | * **Commits**: [619](https://github.com/search?q=author%3Awooorm+committer-date%3A%222023-05-31..2023-06-30%22\&type=commits) 17 | * **Issues and PRs**: [12](https://github.com/search?q=author%3Awooorm+created%3A%222023-05-31..2023-06-30%22\&type=issues) 18 | ) 19 | -------------------------------------------------------------------------------- /invoices/2023-07-31-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2023-07-31 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | ------------------ | ------------------------------ | ------------- | 10 | | unified collective | Development and support (July) | **$4,800.00** | 11 | 12 | *** 13 | 14 | The numbers for this month: 15 | 16 | * **Commits**: [947](https://github.com/search?q=author%3Awooorm+committer-date%3A%222023-06-30..2023-07-31%22\&type=commits) 17 | -------------------------------------------------------------------------------- /invoices/2023-09-01-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2023-09-01 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | ------------------ | -------------------------------- | ------------- | 10 | | unified collective | Development and support (August) | **$4,800.00** | 11 | 12 | *** 13 | 14 | The numbers for this month: 15 | 16 | * **Commits**: [818](https://github.com/search?q=author%3Awooorm+committer-date%3A%222023-07-31..2023-09-01%22\&type=commits) 17 | -------------------------------------------------------------------------------- /invoices/2023-09-30-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2023-09-30 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | ------------------ | ----------------------------------- | ------------- | 10 | | unified collective | Development and support (September) | **$4,800.00** | 11 | 12 | *** 13 | 14 | The numbers for this month: 15 | 16 | * **Commits**: [1k](https://github.com/search?q=author%3Awooorm+committer-date%3A%222023-09-01..2023-09-30%22\&type=commits) 17 | -------------------------------------------------------------------------------- /invoices/2023-10-06-murderlon.md: -------------------------------------------------------------------------------- 1 | # Invoice: camomile 2 | 3 | * **Date**: 2023-10-06 4 | * **Person**: Merlijn Vos ([**@murderlon**](https://github.com/murderlon)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | -------- | --------------------- | ----------- | 10 | | camomile | Development, 36 hours | **$750.00** | 11 | 12 | *** 13 | 14 | As discussed in the [RFC][]: 15 | A new Node.js HTTP proxy to route images through SSL, 16 | compatible with unified plugins, 17 | to safely embed user content on the web. 18 | 19 | The new project: [`rehype/camomile`][camomile] 20 | 21 | [camomile]: https://github.com/rehypejs/camomile/ 22 | 23 | [rfc]: https://github.com/unifiedjs/rfcs/blob/main/text/0005-camo-image-proxy.md 24 | -------------------------------------------------------------------------------- /invoices/2023-10-31-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2023-10-31 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | ------------------ | -------------------------------- | ------------- | 10 | | unified collective | Development and support (August) | **$4,800.00** | 11 | 12 | *** 13 | 14 | The numbers for this month: 15 | 16 | * **Commits**: [128](https://github.com/search?q=author%3Awooorm+committer-date%3A%222023-09-30..2023-10-31%22\&type=commits) 17 | -------------------------------------------------------------------------------- /invoices/2024-07-31-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2024-07-31 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | ------------------ | ------------------------------ | ------------- | 10 | | unified collective | Development and support (July) | **$4,800.00** | 11 | 12 | *** 13 | 14 | The numbers for this month: 15 | 16 | * **Commits**: [155](https://github.com/search?q=author%3Awooorm+committer-date%3A%222024-06-30..2024-07-31%22\&type=commits) 17 | -------------------------------------------------------------------------------- /invoices/2024-09-02-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2024-09-02 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | ------------------ | -------------------------------- | ------------- | 10 | | unified collective | Development and support (August) | **$4,800.00** | 11 | 12 | *** 13 | 14 | The numbers for this month: 15 | 16 | * **Commits**: [145](https://github.com/search?q=author%3Awooorm+committer-date%3A%222024-07-31..2024-08-31%22\&type=commits) 17 | -------------------------------------------------------------------------------- /invoices/2024-10-01-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2024-10-01 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | ------------------ | ----------------------------------- | ------------- | 10 | | unified collective | Development and support (September) | **$4,800.00** | 11 | 12 | *** 13 | 14 | The numbers for this month: 15 | 16 | * **Commits**: [300](https://github.com/search?q=author%3Awooorm+committer-date%3A%222024-08-31..2024-09-30%22\&type=commits) 17 | -------------------------------------------------------------------------------- /invoices/2024-11-01-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2024-11-01 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | ------------------ | --------------------------------- | ------------- | 10 | | unified collective | Development and support (October) | **$4,800.00** | 11 | 12 | *** 13 | 14 | The numbers for this month: 15 | 16 | * **Commits**: [335](https://github.com/search?q=author%3Awooorm+committer-date%3A%222024-09-30..2024-10-31%22\&type=commits) 17 | -------------------------------------------------------------------------------- /invoices/2024-12-02-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2024-12-02 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | ------------------ | ---------------------------------- | ------------- | 10 | | unified collective | Development and support (November) | **$4,800.00** | 11 | 12 | *** 13 | 14 | The numbers for this month: 15 | 16 | * **Commits**: [258](https://github.com/search?q=author%3Awooorm+committer-date%3A%222024-10-31..2024-11-30%22\&type=commits) 17 | -------------------------------------------------------------------------------- /invoices/2025-02-03-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2025-02-03 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | ------------------ | --------------------------------- | ------------- | 10 | | unified collective | Development and support (January) | **$4,800.00** | 11 | 12 | *** 13 | 14 | The numbers for this month: 15 | 16 | * **Commits**: [283](https://github.com/search?q=author%3Awooorm+committer-date%3A%222024-12-31..2025-02-01%22\&type=commits\&s=committer-date\&o=desc) 17 | -------------------------------------------------------------------------------- /invoices/2025-03-05-wooorm.md: -------------------------------------------------------------------------------- 1 | # Invoice: unified collective 2 | 3 | * **Date**: 2025-03-05 4 | * **Person**: Titus Wormer ([**@wooorm**](https://github.com/wooorm)) 5 | 6 | ## Items 7 | 8 | | Item | Description | Total | 9 | | ------------------ | ---------------------------------- | ------------- | 10 | | unified collective | Development and support (February) | **$4,800.00** | 11 | 12 | *** 13 | 14 | The numbers for this month: 15 | 16 | * **Commits**: [297](https://github.com/search?q=author%3Awooorm+committer-date%3A%222025-01-31..2025-03-01%22&type=commits&s=committer-date&o=desc) 17 | -------------------------------------------------------------------------------- /members.md: -------------------------------------------------------------------------------- 1 | # Members policy 2 | 3 | This document describes the individuals in and around the unified collective. 4 | It describes the motions used to initiate how individuals are nominated and how 5 | they step down. 6 | Finally, it describes how accepted motions are enacted through playbooks for 7 | inviting, onboarding, awarding, succession, and offboarding. 8 | 9 | This document is developed by the unified collective core team. 10 | 11 | ## Table of contents 12 | 13 | * [Persons](#persons) 14 | * [Participation](#participation) 15 | * [Motions](#motions) 16 | * [Motion to nominate a contributor](#motion-to-nominate-a-contributor) 17 | * [Motion to nominate a maintainer](#motion-to-nominate-a-maintainer) 18 | * [Request to become a maintainer](#request-to-become-a-maintainer) 19 | * [Request to become a releaser](#request-to-become-a-releaser) 20 | * [Request to elect a lead](#request-to-elect-a-lead) 21 | * [Request to resign](#request-to-resign) 22 | * [Motion to prune](#motion-to-prune) 23 | * [Playbooks](#playbooks) 24 | * [Inviting](#inviting) 25 | * [Onboarding](#onboarding) 26 | * [Awarding](#awarding) 27 | * [Succession](#succession) 28 | * [Offboarding](#offboarding) 29 | 30 | ## Persons 31 | 32 | ```text 33 | +--------------------------------------------------------------------------+ 34 | | person | 35 | | +------------------------------------------------------+ | 36 | | | member | | 37 | | | +----------------------------------+ | | 38 | | | | maintainer | | | 39 | | +-------------+ | +-------------+ | +-------------+ +-------------+ | | | 40 | | | user | | | contributor | | | merger | | releaser | | | | 41 | | +-------------+ | +-------------+ | +-------------+ +-------------+ | | | 42 | | | +----------------------------------+ | | 43 | | +------------------------------------------------------+ | 44 | +--------------------------------------------------------------------------+ 45 | ``` 46 | 47 | A **person**, in the scope of collective governance, is any individual that 48 | participates in a space where the collective has a presence. 49 | 50 | Participation includes dealing in the projects governed by the collective (such 51 | as using, distributing, or selling), and activity such as code, comments, 52 | commits, edits, emails, issues, posts, pull requests, or tweets. 53 | 54 | Spaces includes any online or offline place such as email, GitHub, npm, or 55 | Twitter. 56 | 57 | Persons are further divided into two groups: users and members. 58 | A **member** is a person that is part of a team, a **user** is not. 59 | 60 | Members are further divided into two groups: contributors and maintainers. 61 | A **maintainer** is an active member whose significant and valuable 62 | participation spans the whole scope of the team and improves the longevity 63 | of the collective, a **contributor** is not. 64 | 65 | The set of contributors should be large; the ideal would be ten or more, as 66 | contributors can be contacted to voice their opinions on matters affecting the 67 | community, and could in the future become maintainers. 68 | 69 | In some cases, a contributor can be an invited **guest maintainer** on certain 70 | projects governed by an organization team. 71 | Guest maintainers have the same rights and responsibilities as normal 72 | maintainers (specifically mergers, not releasers), except that their 73 | participation focusses on one or a few projects instead of the whole 74 | organization. 75 | Guest maintainers do not have the voting rights that actual maintainers have 76 | and cannot nominate other maintainers. 77 | Guest maintainers should be the exception to the rule, and are invited through a 78 | *motion to grant governance*. 79 | 80 | The set of maintainers should be medium; the ideal would be more than three and 81 | less than ten, to spread the workload and avoid burdening or burning out any 82 | person. 83 | The set of maintainers of the moderation team should instead be small; the ideal 84 | would be two or three. 85 | 86 | Maintainers of the moderation and core teams are further limited in that they 87 | should not be on both teams at the same time to avoid conflicts of interest. 88 | 89 | Organization teams further differentiate between two types of maintainers: 90 | mergers and releasers. 91 | A **releaser** is a maintainer with the authority to release projects produced 92 | by the team, a **merger** is not. 93 | 94 | The set of releasers should be small; the ideal would be three or less, to limit 95 | access and reduce risk. 96 | 97 | Releasers are required to have an npm account. 98 | 99 | One maintainer of an organization team is elected as the team **lead**. 100 | This role must be fulfilled by a collective core team maintainer. 101 | 102 | ### Participation 103 | 104 | Some (but not all) examples of participation can be gathered through GitHub 105 | search, for example, like so: 106 | 107 | * [Find commits by a user in an org][search-commits] 108 | * [Find issues / PRs opened by a user in an org][search-issues] 109 | * [Find issues / PRs with comments by a user in an org][search-comments] 110 | * [Find PRs with reviews by a user in an org][search-reviews] 111 | 112 | > You can also [search in the entire collective][search-collective]. 113 | 114 | Typical participation of a member includes: 115 | 116 | * Asking questions 117 | * Reporting problems and requesting new features 118 | * Commenting on issues and pull requests 119 | * Triaging issues 120 | * Requesting motions 121 | 122 | Typical participation of an organization team maintainer includes: 123 | 124 | * Answering questions and helping novice contributors 125 | * Contributing code, non-code, and documentation changes that improve the 126 | scope of the team 127 | * Reviewing and merging pull requests 128 | * Participating in initiatives and discussions 129 | 130 | Maintainers are not required to contribute code. 131 | It is, however, required that maintainers have actively participated for a 132 | consistent and significant amount of time already. 133 | 134 | Typical participation of a moderation team maintainer includes: 135 | 136 | * Enforcing the code of conduct 137 | * Expelling members and blocking users 138 | 139 | Typical participation of a core team maintainer includes: 140 | 141 | * Focusing on overarching concerns 142 | * Voting to accept or dismiss motions 143 | * Enacting accepted motions 144 | * Communicating between all teams 145 | 146 | Typical participation of a lead includes: 147 | 148 | * Setting up a team 149 | * Ensuring initiatives are progressing at a reasonable rate 150 | 151 | ## Motions 152 | 153 | Motions are used to initiate changes in the roles people have based on their 154 | participation. 155 | 156 | This section describes who may request a motion (the movant), who may be 157 | nominated (the nominee), and who may vote (the voters). 158 | In some cases, the movant and nominee are the same individual. 159 | 160 | Furthermore, this section describes what happens when the vote dismisses a 161 | motion and what playbook is followed when it is accepted. 162 | 163 | This section describes motions where both the movant and nominee operate in 164 | *good-faith*. 165 | Additional policy is needed to define *bad-faith* scenarios. 166 | 167 | ### Motion to nominate a contributor 168 | 169 | A user (the nominee) is nominated by a member (the movant) to become a 170 | contributor on one or more team. 171 | Users are free to contact members beforehand to suggest their own nomination. 172 | 173 | A motion to nominate a contributor cannot be requested to collective teams. 174 | For collective teams, request a *motion to nominate a maintainer*. 175 | 176 | The movant must open an issue on `unifiedjs/collective` to request the motion. 177 | The movant should be convinced that the nominee is indeed an active contributor, 178 | and is therefore tasked to convince the collective core team to accept the 179 | motion, through proof that participation matches that of a contributor. 180 | Other than proof, the motion must include the full name, email address, GitHub 181 | handle, and npm handle (optional) of the nominee, and the teams the nominee is 182 | nominated for. 183 | 184 | Any collective core team maintainer may vote. 185 | 186 | When the motion is accepted, the lead of a team (if an organization team) or any 187 | maintainer (if a collective team), enacts the motion by following the *inviting* 188 | playbook. 189 | 190 | When the motion is dismissed, the nominee is ineligible to be nominated as a 191 | contributor to the relevant team(s) for six months. 192 | 193 | ### Motion to nominate a maintainer 194 | 195 | A person (the nominee) is nominated by a maintainer (the movant) to become a 196 | merger (in case of an organization team) or maintainer (in case of a collective 197 | team) on a single team. 198 | Contributors are free to contact maintainers beforehand to suggest their own 199 | nomination. 200 | 201 | The movant must open an issue on `unifiedjs/collective` to request the motion. 202 | The movant should be convinced that the nominee is indeed an active maintainer, 203 | and is therefore tasked with convincing the collective core team to accept the 204 | motion, through proof that participation matches that of a maintainer. 205 | The movant should include, if not already known, the npm handle of the nominee. 206 | 207 | Any collective core team maintainer may vote. 208 | 209 | When the motion is accepted, the lead of the team (if an organization team) or 210 | any maintainer (if a collective team), enacts the motion by following the 211 | *inviting* playbook (in case the person has not been invited before) and the 212 | *onboarding* playbook. 213 | 214 | When the motion is dismissed, the nominee is ineligible to be nominated as a 215 | maintainer to the team for six months. 216 | 217 | ### Request to become a maintainer 218 | 219 | > Also known as: *Motion to nominate a maintainer*. 220 | 221 | A contributor (the nominee and movant) who previously held the role of a 222 | maintainer may self-nominate to become a merger (in case of an organization 223 | team) or maintainer (in case of a collective team) on a single team. 224 | 225 | The movant must open an issue on `unifiedjs/collective` to request the motion. 226 | The movant is tasked with convincing the collective core team to accept the 227 | motion. 228 | The movant should include, if not already known, their npm handle. 229 | 230 | Any collective core team maintainer may vote. 231 | 232 | When the motion is accepted, the lead of the team (if an organization team) or 233 | any maintainer (if a collective team), enacts the motion by following the 234 | *onboarding* playbook. 235 | 236 | When the motion is dismissed, the nominee is ineligible to be nominated as a 237 | maintainer to the team for six months. 238 | 239 | ### Request to become a releaser 240 | 241 | > Also known as: *Motion to nominate a releaser*. 242 | 243 | In case of an organization team, a merger (the nominee and movant) may 244 | self-nominate to become a releaser on a team. 245 | 246 | The movant must open an issue on `unifiedjs/collective` to request the motion. 247 | The movant is tasked with convincing the collective core team to accept the 248 | motion. 249 | The movant must include, if not already known, their npm handle. 250 | 251 | Any collective core team maintainer may vote. 252 | 253 | When the motion is accepted, the lead of the team enacts the motion by following 254 | the *awarding* playbook. 255 | 256 | When the motion is dismissed, the nominee is ineligible to be nominated as a 257 | releaser to the team for six months. 258 | 259 | ### Request to elect a lead 260 | 261 | > Also known as: *Motion to elect a lead*. 262 | 263 | In case of an organization team, yearly, the lead (the movant) must open an 264 | issue on the team’s governance repository to notify maintainers that elections 265 | are coming up. 266 | Maintainers of the team that are interested in volunteering as lead but are not 267 | collective core team maintainers, may then move to become core team maintainers. 268 | 269 | When one month has passed, the movant must open another issue on the team’s 270 | governance repository to request a motion to elect a lead. 271 | The movant is tasked with compiling a list of nominees with all maintainers of 272 | the team, that are also collective core team maintainers, and are interested in 273 | volunteering as lead. 274 | The nominees may include the movant. 275 | 276 | Any maintainer of the team may vote. 277 | 278 | The motion cannot be dismissed. 279 | 280 | The motion is accepted immediately if there is only one nominee and otherwise 281 | after 14 days. 282 | The movant enacts the motion by following the *succession* playbook for the 283 | nominee with the most votes. 284 | 285 | ### Request to resign 286 | 287 | > Also known as: *Motion to be excused from duty*. 288 | 289 | Any maintainer (the movant and nominee) may request a motion to be excused from 290 | duty. 291 | 292 | The movant must open an issue on `unifiedjs/collective` to request the motion. 293 | It is discouraged to request to resign if the nominee is the lead, or the last 294 | maintainer of a team, before finding suitable replacement. 295 | The motion must include the new role the nominee wishes to have, which must 296 | require less participation that their current role (one of: merger, maintainer, 297 | or contributor). 298 | 299 | The motion cannot be dismissed. 300 | 301 | The motion is accepted. 302 | The lead of a team (if an organization team) or any maintainer (if a collective 303 | team), enacts the motion by following the *offboarding* playbook. 304 | The offboarding may take up to 45 days (in case of a collective team maintainer) 305 | or 7 days (in case of a releaser) if a suitable replacement needs to be found. 306 | 307 | ### Motion to prune 308 | 309 | The lead of a team (if an organization team) or any maintainer (if a collective 310 | team), known as the movant, may request a motion to prune a team. 311 | A motion to prune cannot be requested within six months of the previous motion 312 | to prune. 313 | 314 | The movant must open an issue on the team’s governance repository to request the 315 | motion. 316 | The motion asks current maintainers for their continued volunteering efforts. 317 | 318 | Any maintainer that responds affirmative remains on the team in their current 319 | role. 320 | 321 | The motion cannot be dismissed. 322 | 323 | The motion is accepted after 14 days. 324 | Maintainer that did not respond (the nominees) are treated as if they had 325 | requested a *motion to be excused from duty* with a role of `contributor`. 326 | The movant enacts the motion by following the *offboarding* playbook for the 327 | nominees. 328 | The offboarding may take up to 45 days (in case of a collective team maintainer) 329 | or 7 days (in case of a releaser) if suitable replacements needs to be found. 330 | After offboarding the nominees are immediately eligible to *request to become a 331 | maintainer* again. 332 | 333 | ## Playbooks 334 | 335 | Playbooks describe the steps the enactor and nominee(s) must follow to enact 336 | changes initiated through accepted motions. 337 | 338 | ### Inviting 339 | 340 | The *inviting* playbook is followed when a *motion to nominate a contributor*, 341 | and in some cases a *motion to nominate a maintainer* or a *motion to grant 342 | governance*, is accepted. 343 | The enactor of the playbook is a lead of a team (if an organization team) or any 344 | maintainer (if a collective team). 345 | The result of *inviting* is that a user (the nominee) becomes a contributor on 346 | one or more teams. 347 | 348 | * Nominee ensures 2FA is enabled on GitHub 349 | * Nominee confirms that they have read, understand, and agree to uphold the 350 | code of conduct 351 | * Enactor adds the nominee, if not already listed, to 352 | [`data/humans.yml`][humans] 353 | * Enactor adds the nominee to the respective teams as a `contributor` in 354 | [`data/teams.yml`][teams] 355 | * Tooling automatically invites the nominee and sets their [permissions][] on 356 | GitHub within 24 hours 357 | 358 | ### Onboarding 359 | 360 | The *onboarding* playbook is followed when a *motion to nominate a maintainer* 361 | is accepted. 362 | The enactor of the playbook is the lead of a team (if an organization team) or 363 | any maintainer (if a collective team). 364 | The result of *onboarding* is that a contributor (the nominee) becomes a 365 | maintainer on a team. 366 | 367 | * Enactor adds the npm handle of the nominee, if known and not already listed, 368 | to [`data/humans.yml`][humans] 369 | * Enactor changes the role of the nominee in the team from `contributor` to 370 | `merger` (if an organization team) or `maintainer` (if a collective team) in 371 | [`data/teams.yml`][teams] 372 | * Tooling automatically updates the nominee and changes their [permissions][] 373 | on GitHub, and invites the nominee and sets their permissions on npm, within 374 | 24 hours 375 | * Enactor and nominee should schedule a call to walk through relevant 376 | processes, documents, and expectations 377 | 378 | If the nominee is added to a collective team, the following steps additionally 379 | apply: 380 | 381 | * Enactor adds the nominee to OpenCollective 382 | * [**@wooorm**][wooorm] sets up an email address for the nominee and ensures 383 | the relevant collective email addresses are forwarded to it 384 | * Nominee confirms emails can be received 385 | 386 | ### Awarding 387 | 388 | The *awarding* playbook is followed when a *motion to nominate a releaser* is 389 | accepted. 390 | The enactor of the playbook is the lead of a team. 391 | The result of *awarding* is that a merger (the nominee) becomes a releaser on a 392 | team. 393 | 394 | * Nominee ensures 2FA is enabled on npm 395 | * Enactor adds the npm handle of the nominee, if not already listed, to 396 | [`data/humans.yml`][humans] 397 | * Enactor changes the role of the nominee in the team from `merger` to 398 | `releaser` in [`data/teams.yml`][teams] 399 | * Tooling automatically updates the nominee and changes their [permissions][] 400 | on GitHub and npm within 24 hours 401 | * Enactor and nominee should schedule a call to walk through relevant 402 | processes, documents, and expectations 403 | 404 | ### Succession 405 | 406 | The *succession* playbook is followed when a *motion to elect a lead* is 407 | accepted. 408 | The enactor of the playbook is the current lead of the team. 409 | The result of *succession* is that a maintainer (the nominee) becomes the lead 410 | of the team. 411 | 412 | If the nominee is not the enactor, the following steps are taken: 413 | 414 | * Enactor changes the `lead` field in [`data/teams.yml`][teams] to the GitHub 415 | handle of the nominee 416 | * Tooling automatically updates the enactor and nominee and changes their 417 | [permissions][] on GitHub within 24 hours. 418 | Enactor may have to manually perform destructive actions as reported by 419 | tooling 420 | * Enactor and nominee should schedule a call to walk through relevant 421 | processes, documents, and expectations 422 | 423 | ### Offboarding 424 | 425 | The *offboarding* playbook is followed when a *motion to be excused from duty*, 426 | and in some cases a *motion to prune*, is accepted. 427 | The enactor of the playbook is the lead of a team (if an organization team) or 428 | any maintainer (if a collective team). 429 | If the enactor is also the nominee (because the nominee is the last maintainer 430 | of a team), a collective core team maintainer is the enactor. 431 | The result of *offboarding* is that a maintainer (the nominee) becomes a merger, 432 | maintainer, or contributor on a team. 433 | 434 | Note that if the nominee is being excused from duty as a collective core team 435 | maintainer, they are also excused from duty as lead of any organization teams. 436 | 437 | * If nominee is being excused from duty as a lead, the collective core team 438 | appoints a guest lead. 439 | The guest lead is tasked with requesting a motion to elect a lead. 440 | This may take up to 45 days 441 | * If the nominee is being excused from duty as a collective moderation team 442 | maintainer, and the team is getting too small, the collective core team 443 | appoints a guest moderator. 444 | The guest moderator and remaining moderators are tasked with finding 445 | suitable replacement. 446 | This may take up to 45 days 447 | * If the nominee is being excused from duty as a releaser and the set of 448 | releasers on the team is getting too small, enactor raises a call for 449 | releasers to ask that current mergers request a *motion to nominate a 450 | releaser*. 451 | This may take up to 7 days 452 | * Enactor changes the role of the nominee in the respective teams to the 453 | approved role in [`data/teams.yml`][teams] 454 | * Tooling automatically updates the nominee and changes their [permissions][] 455 | on GitHub and npm within 24 hours. 456 | Enactor may have to manually perform destructive actions as reported by 457 | tooling 458 | 459 | If the nominee is removed from a collective team as a maintainer, the following 460 | steps additionally apply: 461 | 462 | * Enactor removes the nominee from OpenCollective 463 | * [**@wooorm**][wooorm] removes the nominee’s email address and ensures the 464 | relevant collective email addresses are no longer forwarded to them. 465 | 466 | 467 | 468 | [humans]: data/humans.yml 469 | 470 | [permissions]: permissions.md 471 | 472 | [search-collective]: https://github.com/search?q=org:unifiedjs+org:vfile+org:syntax-tree+org:remarkjs+org:rehypejs+org:retextjs+org:redotjs+org:micromark+org:mdx-js 473 | 474 | [search-comments]: https://github.com/search?type=Issues&o=desc&s=created&q=org:vfile+commenter:ChristianMurphy 475 | 476 | [search-commits]: https://github.com/search?type=Commits&o=desc&s=committer-date&q=org:syntax-tree+author:eush77 477 | 478 | [search-issues]: https://github.com/search?type=Issues&o=desc&s=created&q=org:remarkjs+author:ben-eb 479 | 480 | [search-reviews]: https://github.com/search?type=Issues&o=desc&s=created&q=org:unifiedjs+reviewed-by:Murderlon 481 | 482 | [teams]: data/teams.yml 483 | 484 | [wooorm]: https://github.com/wooorm 485 | -------------------------------------------------------------------------------- /moderation.md: -------------------------------------------------------------------------------- 1 | # Moderation policy 2 | 3 | This document describes how moderation occurs across the collective. 4 | It describes how people can handle code of conduct violations. 5 | Furthermore it describes the actions any maintainer, and specifically moderators 6 | (maintainers of the collective moderation team), can make. 7 | 8 | This document is developed by the unified collective moderation team and the 9 | unified collective core team. 10 | 11 | ## Table of contents 12 | 13 | * [Violations](#violations) 14 | * [Reporting](#reporting) 15 | * [Enforcement](#enforcement) 16 | * [Playbooks](#playbooks) 17 | * [Moderation](#moderation) 18 | * [Warning](#warning) 19 | * [Expulsion](#expulsion) 20 | * [Blocking](#blocking) 21 | 22 | ## Violations 23 | 24 | A **violation**, in the scope of collective governance, is any post that 25 | violates the [code of conduct][coc]. 26 | The collective moderation team decides what inappropriate behavior constitutes a 27 | violation. 28 | 29 | A post includes activity that can be moderated, such as code, comments, commits, 30 | edits, issues, posts, or pull requests, in a project governed by the collective. 31 | Posts additionally include activity that cannot be moderated, such as emails or 32 | tweets, from members of the collective. 33 | 34 | **Moderation**, in the scope of collective governance, includes actions such as 35 | editing, deleting, hiding, or locking one or more posts to address violations. 36 | Not all posts can be moderated. 37 | 38 | These actions are not considered moderation if they do not address violations, 39 | such as minor edits to fix formatting or typos, hiding outdated posts, or 40 | locking old issues. 41 | 42 | Persons should carefully consider the possible intent of the author of a 43 | violation. 44 | It may be that they made an error, are not familiar with the code of conduct, 45 | are unaware that something is inappropriate, or that cultural differences exist. 46 | In such cases, the author can be given an opportunity to correct the error they 47 | made. 48 | This does not excuse a violation, but sometimes making an author aware is better 49 | than enforcement. 50 | 51 | Violations should be reported and can result in enforcement such as moderation, 52 | warning, blocking, and expulsion. 53 | 54 | This policy does not restrict any individual blocking another individual from 55 | their personal GitHub account (or in another space, such as Twitter). 56 | A personal block is not considered enforcement of moderation. 57 | 58 | ### Reporting 59 | 60 | Anyone may report a violation. 61 | Members should report violations. 62 | Violations can be reported in the following ways: 63 | 64 | * In private, via the collective email address `moderation@unifiedjs.com` 65 | * In private, via email to one or more moderators 66 | * In public, via a new post in the same thread as the violation (mentioning 67 | `@unifiedjs/moderators`) 68 | 69 | Reporting in private is appropriate when the reporter does not feel comfortable 70 | directly or publicly making the request. 71 | Reports sent to `moderation@unifiedjs.com` are forwarded to all maintainers of 72 | the collective moderation team. 73 | 74 | Reports should contain as much information and context as possible, including 75 | the URL and a screenshot of the violation. 76 | Details may be modified to obscure obscene or offensive content. 77 | Quoting original content of a violation within a report is not a violation. 78 | However, discretion is advised when including such quotes in public reports. 79 | 80 | Members must not discuss specific details of reports in any public space. 81 | 82 | Violations are reported to track violations, their context, and the resulting 83 | enforcement, across the collective. 84 | Reports are also used to track continued violations across the collective. 85 | 86 | ### Enforcement 87 | 88 | Moderators may enforce moderation, warning, expulsion, and blocking. 89 | 90 | If the violation is from a user (an individual that is not a member), any 91 | maintainer may enforce moderation and blocking. 92 | 93 | Moderators may **moderate** any post, and maintainers may moderate a post from a 94 | user, by following (if possible) the *moderation* playbook. 95 | 96 | For extreme violations, moderators may **expel** any member by following the 97 | *expulsion* playbook, and moderators may **block** any person, and maintainers 98 | may block a user, by following the *blocking* playbook. 99 | 100 | Moderators must keep track of the violations (that are indeed offenses) of 101 | an offender. 102 | First and second offenses must result in following the *warning* playbook. 103 | A third offense, if offender is a member, must result in following the 104 | *expulsion* playbook. 105 | A third offense (or the fourth offense, if the offender is expelled) must result 106 | in following the *blocking* playbook. 107 | 108 | ## Playbooks 109 | 110 | Playbooks describe the steps an enactor must follow to enact enforcement of the 111 | code of conduct. 112 | 113 | ### Moderation 114 | 115 | The enactor of a *moderation* playbook is a maintainer. 116 | The offender is a person that authored a violation. 117 | The result of *moderation* is that a violation is no longer present. 118 | 119 | * Enactor ensures the violation is reported 120 | * If the offender is a member, the enactor should give the offender a 121 | reasonable opportunity to self-moderate the post. 122 | If the offender disagrees to self-moderate, the enactor can escalate to the 123 | collective moderation team, by following up on the report, while not 124 | continuing to enact moderation. 125 | Moderators can decide to continue enacting moderation 126 | * Enactor moderates the post, such as by editing, deleting, hiding, or locking 127 | * Enactor posts a notification within the original thread, mentioning the 128 | offender, that they are in violation of the code of conduct, what behavior 129 | was unacceptable, what changes were made to the post, and previously taken 130 | steps to resolve, to justify why moderation was warranted 131 | 132 | ### Warning 133 | 134 | The enactor of a *warning* playbook is a moderator (a maintainer of the 135 | collective moderation team). 136 | The offender is a person that authored a violation for the first or second time. 137 | The result of *warning* is that an offender is aware that their behavior is 138 | in violation of the code of conduct, that the code of conduct is enforced, 139 | and of future enforcements for continued violations. 140 | 141 | * Enactor posts a warning within the original thread, confirming the 142 | justification of why moderation was warranted, that this their first or 143 | second official warning, and how a third violation is enforced 144 | 145 | ### Expulsion 146 | 147 | The enactor of an *expulsion* playbook is a moderator (a maintainer of the 148 | collective moderation team). 149 | The offender is a member that authored an extreme or continued violation. 150 | The *expulsion* playbook is followed after (swift) moderation. 151 | The result of *expulsion* is that a member is excused from duty and removed from 152 | all teams. 153 | 154 | * Enactor ensures the violation is reported 155 | * Enactor coordinates with a maintainer of the collective core team to jointly 156 | and swiftly enact the *offboarding* playbook for all teams the offender 157 | is currently a member of, but instead of assigning a new role, removing them 158 | entirely 159 | * Enactor posts within the original thread, mentioning the offender, 160 | explaining what behavior was unacceptable, that this was the offender’s 161 | third violation or an extreme violation, and confirming that they are 162 | expelled from the collective 163 | 164 | Expulsion poses an imminent risk to the collective as it could cause the 165 | offender to act in extreme bad-faith and misuse the permissions they were 166 | granted. 167 | 168 | ### Blocking 169 | 170 | The enactor of a *blocking* playbook is a moderator (a maintainer of the 171 | collective moderation team) and in some cases a maintainer. 172 | The offender is a person that authored an extreme violation, or a continued 173 | third (or fourth) violation. 174 | The result of *blocking* is that an offender is forcefully removed from the 175 | spaces governed by the collective. 176 | 177 | * Enactor ensures the violation is reported 178 | * Enactor coordinates with a maintainer of the collective core team to jointly 179 | block the offender in the spaces governed by the collective, such as GitHub 180 | and Twitter 181 | * Enactor posts within the original thread, mentioning the offender, 182 | explaining what behavior was unacceptable, that this was the offender’s 183 | third/fourth violation or an extreme violation, and confirming that they are 184 | blocked from the collective 185 | 186 | GitHub provides an interface for blocking persons for 1, 3, 7, or 30 days, or 187 | indefinitely. 188 | This policy intentionally does not dictate whether blocking is temporary or 189 | indefinite, and leaves that up to moderators. 190 | 191 | 192 | 193 | [coc]: code-of-conduct.md 194 | -------------------------------------------------------------------------------- /organizations.md: -------------------------------------------------------------------------------- 1 | # Organizations policy 2 | 3 | This document describes how organizations are managed by an organization team 4 | and the collective teams. 5 | It makes several suggestions on how projects are maintained and describes how 6 | projects are managed. 7 | Furthermore, it describes how to initiate management of a project through 8 | informal initiatives or formal motions. 9 | Finally, it describes how accepted motions are enacted through playbooks for 10 | archival, removal, withdrawal, and granting. 11 | 12 | This document is developed by the unified collective core team. 13 | 14 | ## Table of contents 15 | 16 | * [Projects](#projects) 17 | * [Maintenance](#maintenance) 18 | * [Management](#management) 19 | * [Meta projects](#meta-projects) 20 | * [Motions](#motions) 21 | * [Motion to archive a project](#motion-to-archive-a-project) 22 | * [Motion to delete a project](#motion-to-delete-a-project) 23 | * [Motion to withdraw governance](#motion-to-withdraw-governance) 24 | * [Motion to grant governance](#motion-to-grant-governance) 25 | * [Playbooks](#playbooks) 26 | * [Archival](#archival) 27 | * [Removal](#removal) 28 | * [Withdrawal](#withdrawal) 29 | * [Granting](#granting) 30 | 31 | ## Projects 32 | 33 | Projects relating to the areas covered by the collective can be governed inside 34 | or outside of the collective: anyone can develop, maintain, manage, and 35 | self-govern projects. 36 | 37 | Projects can flourish whether they are governed by the collective or not. 38 | But wilting projects reflect badly on the collective as they provide a bad user 39 | experience. 40 | Signs of a wilting project are, for example, that issues are left unanswered or 41 | that dependencies are outdated. 42 | 43 | Maintainers of projects not governed by the collective can request a *motion to 44 | grant governance* to pass governance over to the collective. 45 | Maintainers of wilting projects typically grant governance as they no longer 46 | want to maintain those projects. 47 | Maintainers of flourishing projects typically make good candidates to become 48 | maintainers on an organization team. 49 | 50 | A **project**, in the scope of collective governance, is a single repository on 51 | GitHub governed by a team. 52 | 53 | All projects must be in a GitHub organization associated with an organization 54 | team. 55 | Typically, all projects inside a GitHub organization are governed by the 56 | associated organization team. 57 | However, in the case of the `unifiedjs` GitHub organization, some projects are 58 | governed by a collective team. 59 | 60 | A **package**, in the scope of collective governance, is a published asset 61 | originating from a project. 62 | Not every project contains a package. 63 | Some projects include multiple packages. 64 | Packages originating from a project governed by a team are governed by that 65 | team. 66 | 67 | Organizations define how they maintain their projects but the following section, 68 | *Maintenance*, gives a few suggestions. 69 | 70 | The collective defines how projects are managed in the *Management* section. 71 | 72 | Organizations can have **meta projects** that to discuss maintenance and 73 | management. 74 | Some meta projects are required by the collective, as described in the 75 | *Meta projects* section. 76 | 77 | ### Maintenance 78 | 79 | Any member may, on their own initiative, participate by triaging issues and pull 80 | requests. 81 | Triage is a process of sifting through all the things that can be worked on to 82 | select the few things that will be worked on. 83 | A helpful tool with triaging is [GitHub Labels][gh-labels]. 84 | The collective has tooling in place to ensure all projects have the same [set of 85 | labels][labels]. 86 | 87 | Any maintainer may, on their own initiative, participate by pushing directly to 88 | a project or merging any pull request, within the scope of their organization. 89 | Maintainers are trusted to use their judgment in deciding whether to do so. 90 | Maintainers should, however, create a pull request if the changes could warrant 91 | discussion or review, and wait to merge a pull request that makes a significant 92 | change until discussion has occurred. 93 | 94 | Any releaser may, on their own initiative, release a package. 95 | Releasers are trusted to use their judgment in deciding whether to do so. 96 | Releasers should, however, consider that quickly releasing backwards-compatible 97 | fixes and changes benefits users, but batching major changes together limits 98 | churn. 99 | 100 | Any moderator (a maintainer of the collective moderation team) may, on their own 101 | initiative, moderate a post. 102 | Moderators are trusted to use their judgment in deciding whether to do so. 103 | Moderators should, however, consider whether there are tangible grounds for 104 | moderation and the possible intent of the author. 105 | 106 | Core (maintainers of the collective core team) may not use their administrative 107 | permissions, except when explicitly allowed by collective governance 108 | documentation, or when edge-cases occur that are not yet covered by collective 109 | governance documentation. 110 | Core may, of course, participate as allowed by their other roles (such as that 111 | they may maintain a project if they are a maintainer on an organization team). 112 | 113 | ### Management 114 | 115 | Some persons may initiate the management of a project by requesting a relevant 116 | formal motion. 117 | Other management initiatives, such as creating a new project or moving a project 118 | into the collective, are intentionally informal. 119 | These informal initiatives still cause changes to the project if the project is 120 | thereafter subject to the governance policies of the collective. 121 | 122 | Any member may **create a new project**. 123 | This is an informal initiative and does not involve requesting a motion. 124 | Governance dictates that all members except for the team lead thereafter loose 125 | certain permissions on that project. 126 | 127 | Any member may **fork a project**. 128 | This is an informal initiative and does not involve requesting a motion. 129 | The collective does not govern the fork. 130 | 131 | Any person may **transfer a project into the collective**. 132 | Members may do this through an informal initiative that does not involve 133 | requesting a motion. 134 | Any person can do this through a formal initiative that involves a *motion to 135 | grant governance*. 136 | Governance dictates that persons thereafter loose certain permissions on that 137 | project. 138 | A formal motion can result in more permissions. 139 | 140 | Any member may request to **transfer a project from the collective**. 141 | This is a formal initiative that involves a *motion to withdraw governance*. 142 | 143 | Any member may request to **archive a project**. 144 | This is a formal initiative that involves a *motion to archive a project*. 145 | 146 | Any member may request to **delete a project**. 147 | This is a formal initiative that involves a *motion to delete a project*. 148 | 149 | ### Meta projects 150 | 151 | The collective dictates that organization teams set up several meta projects. 152 | These projects and their requirements are as follows: 153 | 154 | ###### `governance` 155 | 156 | The `governance` project documents how the organization is governed. 157 | The governance project links to different policies from the collective, and 158 | states where and how organization policies deviate. 159 | 160 | ###### `.github` 161 | 162 | The `.github` project contains community health files for the organization. 163 | This project has a special name supported by GitHub to provide default community 164 | health files for a whole organization. 165 | As unified collective organizations typically consists of many projects, having 166 | defaults makes sense. 167 | Other projects may overwrite these files. 168 | 169 | It should include the following health files: 170 | 171 | * `.github/ISSUE_TEMPLATE/*.md`: 172 | Templates that guide new issues ([example][c-issue]) 173 | * `.github/pull-request-template.md`: 174 | Template that guides new PRs ([example][c-pr]) 175 | * `code-of-conduct.md`: 176 | Copy of our [code of conduct][c-coc] 177 | * `contributing.md`: 178 | Docs that explain how to contribute ([example][c-contributing]) 179 | * `funding.yml`: 180 | Config file to display a sponsor button ([example][c-funding]) 181 | * `security.md`: 182 | Docs that explain how to report security issues ([example][c-security]) 183 | * `support.md`: 184 | Docs that explain how to get support ([example][c-support]) 185 | 186 | Furthermore, it should include a `readme.md`. 187 | 188 | ## Motions 189 | 190 | Motions are used to initiate certain changes to management of a project in the 191 | collective. 192 | 193 | This section describes who may request a motion (the movant) and who may vote 194 | (the voters). 195 | 196 | Furthermore, this section describes what happens when the vote dismisses the 197 | motion and what playbook is followed when it is accepted. 198 | 199 | ### Motion to archive a project 200 | 201 | A member (the movant) requests that a project is archived. 202 | 203 | The movant must open an issue on the team’s governance repository to formally 204 | request the motion. 205 | 206 | The movant is tasked with convincing the team to accept the motion. 207 | Any maintainer of the team may vote. 208 | 209 | When the motion is accepted, the lead of the team enacts the motion by following 210 | the *archival* playbook. 211 | 212 | Nothing happens when the motion is dismissed. 213 | 214 | ### Motion to delete a project 215 | 216 | A member (the movant) requests that a project is deleted. 217 | It is discouraged to request to delete a project, instead a *motion to archive a 218 | project* is preferred. 219 | 220 | The movant must open an issue on `unifiedjs/collective` to formally request the 221 | motion. 222 | 223 | The movant is tasked with convincing the team to accept the motion. 224 | Any collective core team maintainer may vote. 225 | 226 | When the motion is accepted, the lead of the team enacts the motion by following 227 | the *removal* playbook. 228 | 229 | Nothing happens when the motion is dismissed. 230 | 231 | ### Motion to withdraw governance 232 | 233 | A member (the movant) requests that a project is transferred from the 234 | collective. 235 | 236 | The movant must open an issue on `unifiedjs/collective` to formally request the 237 | motion. 238 | 239 | The movant is tasked with convincing the team to accept the motion. 240 | Any collective core team maintainer may vote. 241 | 242 | When the motion is accepted, the lead of the team enacts the motion by following 243 | the *withdrawal* playbook. 244 | 245 | Nothing happens when the motion is dismissed. 246 | 247 | ### Motion to grant governance 248 | 249 | A person (the movant) requests that a project is transferred to the collective. 250 | 251 | The movant must open an issue on the team’s governance repository to formally 252 | request the motion. 253 | The outside maintainer (the current owner of the project) must confirm that they 254 | agree with the proposed changes in governance. 255 | 256 | The movant is tasked with convincing the team to accept the motion. 257 | Any maintainer of the team may vote. 258 | 259 | When the motion is accepted, the lead of the team enacts the motion. 260 | If the outside maintainer is not a member of the team, the enactor first follows 261 | the *inviting* playbook. 262 | The enactor follows the *granting* playbook. 263 | 264 | When the motion is dismissed, the project is ineligible to be granted again for 265 | six months. 266 | 267 | ## Playbooks 268 | 269 | Playbooks describe the steps the enactor must follow to enact changes initiated 270 | through accepted motions. 271 | 272 | ### Archival 273 | 274 | The *archival* playbook is followed when a *motion to archive a project* is 275 | accepted. 276 | The enactor of the playbook is a lead of a team. 277 | The result of *archival* is that packages are deprecated and a repository is 278 | archived, because the project no longer maintained by the collective. 279 | 280 | * If the project includes published packages, enactor (or a by the enactor 281 | appointed releaser) deprecates them when needed 282 | * Enactor may close open issues and pull requests to notify persons that the 283 | project is no longer maintained 284 | * Enactor updates the repository description on GitHub to state that the 285 | project is no longer maintained 286 | * Enactor archives the repository on GitHub 287 | 288 | ### Removal 289 | 290 | The *removal* playbook is followed when a *motion to delete a project* is 291 | accepted. 292 | The enactor of the playbook is a lead of a team. 293 | The result of *removal* is that packages are deprecated and a repository is 294 | deleted. 295 | 296 | * If the project includes published packages, enactor (or a by the enactor 297 | appointed releaser) deprecates them when needed 298 | * Enactor deletes the repository on GitHub 299 | 300 | ### Withdrawal 301 | 302 | The *withdrawal* playbook is followed when a *motion to withdraw governance* is 303 | accepted. 304 | The enactor of the playbook is a lead of a team. 305 | The person is the proposed owner of the project. 306 | The result of *withdrawal* is that a project is no longer governed by the 307 | collective. 308 | 309 | * Enactor removes references to the unified collective from the project 310 | * Enactor transfers the project to person 311 | * If the project includes published packages, enactor (or a by the enactor 312 | appointed releaser) moves them from the organization to their own account, 313 | and invites person as a maintainer to all packages 314 | * If there are guest maintainers associated with the project, enactor removes 315 | them from [`github-tools`][gh-tools] 316 | 317 | ### Granting 318 | 319 | The *granting* playbook is followed when a *motion to grant governance* is 320 | accepted. 321 | The member is the current owner of the project. 322 | The enactor of the playbook is a lead of a team. 323 | The result of *granting* is that a project comes under governance of the 324 | collective. 325 | 326 | * Member transfers the project to enactor 327 | * If the project includes published packages, member invites 328 | [**@wooorm**][wooorm] as a maintainer to all packages 329 | * Enactor transfers the project to the organization 330 | * If the member is contributor on the team, enactor configures member as a 331 | guest maintainer in [`github-tools`][gh-tools] 332 | * Tooling will automatically update [permissions][] on GitHub and npm within 333 | 24 hours. 334 | Enactor may have to manually perform actions as reported by tooling 335 | * Enactor and member make sure the project matches other projects inside the 336 | organization, such as having a “Contributing” section, a proper license, 337 | etc. 338 | 339 | 340 | 341 | [c-coc]: code-of-conduct.md 342 | 343 | [c-contributing]: https://github.com/unifiedjs/.github/blob/main/contributing.md 344 | 345 | [c-funding]: https://github.com/unifiedjs/.github/blob/main/funding.yml 346 | 347 | [c-issue]: https://github.com/unifiedjs/.github/tree/main/.github/ISSUE_TEMPLATE 348 | 349 | [c-pr]: https://github.com/unifiedjs/.github/blob/main/.github/pull-request-template.md 350 | 351 | [c-security]: https://github.com/unifiedjs/.github/blob/main/security.md 352 | 353 | [c-support]: https://github.com/unifiedjs/.github/blob/main/support.md 354 | 355 | [gh-labels]: https://help.github.com/en/articles/about-labels 356 | 357 | [gh-tools]: https://github.com/unifiedjs/github-tools 358 | 359 | [labels]: https://github.com/unifiedjs/github-tools/labels 360 | 361 | [permissions]: permissions.md 362 | 363 | [wooorm]: https://github.com/wooorm 364 | -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "author": "Titus Wormer (wooorm.com)", 3 | "bugs": "https://github.com/unifiedjs/collective", 4 | "contributors": [ 5 | "Titus Wormer (wooorm.com)" 6 | ], 7 | "description": "Collective governance for unified", 8 | "devDependencies": { 9 | "@types/mdast": "^4.0.0", 10 | "mdast-comment-marker": "^3.0.0", 11 | "mdast-zone": "^6.0.0", 12 | "prettier": "^3.0.0", 13 | "remark-cli": "^12.0.0", 14 | "remark-preset-wooorm": "^11.0.0", 15 | "type-coverage": "^2.0.0", 16 | "typescript": "^5.0.0", 17 | "xo": "^0.60.0", 18 | "yaml": "^2.0.0" 19 | }, 20 | "keywords": [], 21 | "license": "CC-BY-4.0", 22 | "name": "collective", 23 | "prettier": { 24 | "bracketSpacing": false, 25 | "semi": false, 26 | "singleQuote": true, 27 | "tabWidth": 2, 28 | "trailingComma": "none", 29 | "useTabs": false 30 | }, 31 | "private": true, 32 | "remarkConfig": { 33 | "plugins": [ 34 | "remark-preset-wooorm", 35 | "./script/list-of-humans.js" 36 | ] 37 | }, 38 | "repository": "unifiedjs/collective", 39 | "scripts": { 40 | "build": "tsc --build --clean && tsc --build && type-coverage", 41 | "format": "remark --frail --quiet --output -- . && prettier --log-level warn --write -- . && xo --fix", 42 | "test": "npm run build && npm run format" 43 | }, 44 | "typeCoverage": { 45 | "atLeast": 100, 46 | "strict": true 47 | }, 48 | "type": "module", 49 | "version": "0.0.0", 50 | "xo": { 51 | "prettier": true 52 | } 53 | } 54 | -------------------------------------------------------------------------------- /permissions.md: -------------------------------------------------------------------------------- 1 | # Permissions policy 2 | 3 | This document describes the permissions that members of the collective have 4 | across several services. 5 | 6 | Whether to grant permissions is determined by optimizing for the following 7 | conflicting requirements: 8 | 9 | * Limiting access to reduce risk 10 | * Increasing access to improve the bus factor 11 | * Enabling persons to move forward without undue delay 12 | 13 | This document is developed by the unified collective core team. 14 | 15 | ## Table of contents 16 | 17 | * [GitHub](#github) 18 | * [GitHub organization](#github-organization) 19 | * [GitHub teams](#github-teams) 20 | * [npm](#npm) 21 | * [npm organization](#npm-organization) 22 | * [npm teams](#npm-teams) 23 | * [OpenCollective](#opencollective) 24 | * [Twitter](#twitter) 25 | * [Domains](#domains) 26 | * [Email](#email) 27 | * [License](#license) 28 | 29 | ## GitHub 30 | 31 | [GitHub][] permissions are automated in [`github-tools`][gh-tools]. 32 | 33 | Members are required to have a GitHub account. 34 | 35 | ### GitHub organization 36 | 37 | Maintainers of the collective core team are [**owners**][gh-org-perms] of all 38 | GitHub organizations. 39 | 40 | Maintainers of the collective moderation team are [**members**][gh-org-perms] of 41 | all GitHub organizations. 42 | 43 | Members of an organization team are [**members**][gh-org-perms] of their 44 | respective GitHub organization. 45 | 46 | ### GitHub teams 47 | 48 | The GitHub organization consists of GitHub teams: 49 | 50 | * `members` 51 | — includes members; maintained by the lead; [**triage**][gh-repo-perms] 52 | permissions 53 | * `contributors` 54 | — includes contributors; maintained by the lead; [**triage**][gh-repo-perms] 55 | permissions 56 | * `maintainers` 57 | — includes maintainers; maintained by the lead; [**write**][gh-repo-perms] 58 | permissions 59 | * `mergers` 60 | — includes mergers; maintained by the lead; [**write**][gh-repo-perms] 61 | permissions 62 | * `releasers` 63 | — includes releasers; maintained by the lead; [**maintain**][gh-repo-perms] 64 | permissions 65 | * `core` 66 | — includes collective core team maintainers; maintained by the lead; 67 | [**admin**][gh-repo-perms] permissions 68 | * `moderators` 69 | — includes collective moderation team maintainers; maintained by the lead; 70 | [**admin**][gh-repo-perms] permissions 71 | 72 | Maintainers of collective teams may not use their administrative permissions, 73 | except when explicitly allowed by collective governance documentation, or when 74 | edge-cases occur that are not yet covered by collective governance 75 | documentation. 76 | 77 | ## npm 78 | 79 | [npm][] permissions are automated in [`npm-tools`][npm-tools]. 80 | 81 | Releasers are required to have an npm account. 82 | Members without a known npm account are disregarded in this section. 83 | 84 | ### npm organization 85 | 86 | The lead of an organization team is an [**owner**][npm-org-perms] of their 87 | respective npm organization. 88 | 89 | Maintainers of the collective core team are [**admins**][npm-org-perms] of all 90 | npm organizations. 91 | 92 | Maintainers of an organization team are [**members**][npm-org-perms] of their 93 | respective npm organization. 94 | 95 | ### npm teams 96 | 97 | The npm organization consists of npm teams: 98 | 99 | * `mergers` 100 | — includes mergers; [**read-only**][npm-repo-perms] permissions 101 | * `releasers` 102 | — includes releasers; [**read-write**][npm-repo-perms] permissions 103 | 104 | ## OpenCollective 105 | 106 | The `unified` collective on [OpenCollective][] is governed by the collective. 107 | 108 | Maintainers of the collective core team are **admins** of the Collective. 109 | Maintainers of the collective moderation team are **core contributors** of the 110 | Collective. 111 | 112 | Maintainers of collective teams are required to be listed on OpenCollective. 113 | 114 | ## Twitter 115 | 116 | The [`unifiedjs`](https://twitter.com/unifiedjs) account on [Twitter][] is 117 | governed by the collective. 118 | It is owned by [**@wooorm**][wooorm] and [**@johno**][johno]. 119 | 120 | ## Domains 121 | 122 | The [`unifiedjs.com`](https://unifiedjs.com) and 123 | [`mdxjs.com`](https://mdxjs.com) domains are governed by the collective. 124 | They are respectively registered by [**@wooorm**][wooorm] and 125 | [**@johno**][johno]. 126 | 127 | ## Email 128 | 129 | Email is provided by [Mailgun][] and [**@wooorm**][wooorm] has access to it. 130 | The reason for this is financial in nature: it is free of charge. 131 | 132 | This provides us with collective email addresses that forward to actual email 133 | addresses, and functionality to send from an actual email client (such as Gmail) 134 | as a collective email address. 135 | 136 | Maintainers of collective teams have personal addresses: 137 | 138 | * `titus@unifiedjs.com` — [**@wooorm**][wooorm] 139 | * `john@unifiedjs.com` — [**@johno**][johno] 140 | * `christian@unifiedjs.com` — [**@ChristianMurphy**][christianmurphy] 141 | * `merlijn@unifiedjs.com` — [**@Murderlon**][murderlon] 142 | * `richard@unifiedjs.com` — [**@RichardLitt**][richardlitt] 143 | * `olivia@unifiedjs.com` — [**@komaeda**][komaeda] 144 | 145 | The following collective email addresses are in use: 146 | 147 | * `contact@unifiedjs.com` 148 | — forwards to maintainers of the collective core team 149 | * `security@unifiedjs.com` 150 | — forwards to maintainers of the collective core team 151 | * `moderation@unifiedjs.com` 152 | — forwards to maintainers of the collective moderation team 153 | 154 | Maintainers of collective teams are required to read emails sent to them and, 155 | when needed, to respond. 156 | 157 | ## License 158 | 159 | This work is licensed under a 160 | [Creative Commons Attribution 4.0 International License][license]. 161 | 162 | 163 | 164 | [christianmurphy]: https://github.com/ChristianMurphy 165 | 166 | [gh-org-perms]: https://help.github.com/en/articles/permission-levels-for-an-organization#permission-levels-for-an-organization 167 | 168 | [gh-repo-perms]: https://help.github.com/en/articles/repository-permission-levels-for-an-organization#repository-access-for-each-permission-level 169 | 170 | [gh-tools]: https://github.com/unifiedjs/github-tools 171 | 172 | [github]: https://github.com 173 | 174 | [johno]: https://github.com/johno 175 | 176 | [komaeda]: https://github.com/komaeda 177 | 178 | [license]: https://creativecommons.org/licenses/by/4.0/ 179 | 180 | [mailgun]: https://www.mailgun.com 181 | 182 | [murderlon]: https://github.com/Murderlon 183 | 184 | [npm]: https://www.npmjs.com 185 | 186 | [npm-org-perms]: https://docs.npmjs.com/org-roles-and-permissions 187 | 188 | [npm-repo-perms]: https://docs.npmjs.com/cli/access 189 | 190 | [npm-tools]: https://github.com/unifiedjs/npm-tools 191 | 192 | [opencollective]: https://opencollective.com 193 | 194 | [richardlitt]: https://github.com/RichardLitt 195 | 196 | [twitter]: https://twitter.com 197 | 198 | [wooorm]: https://github.com/wooorm 199 | -------------------------------------------------------------------------------- /readme.md: -------------------------------------------------------------------------------- 1 | # Collective governance 2 | 3 | The unified collective is a federated system of organizations, consisting in 4 | turn of projects, governed by the team members steering them. 5 | 6 | This project is maintained by the unified collective core team and describes how 7 | the collective is governed. 8 | 9 | This document describes the teams of the collective. 10 | Additional policies describe other aspects of governance in detail: 11 | 12 | * [`decisions.md`][decisions-policy] — how decisions are made 13 | * [`members.md`][members-policy] — how people participate 14 | * [`moderation.md`][moderation-policy] — how the code of conduct is enforced 15 | * [`organizations.md`][organizations-policy] — how organizations are managed 16 | * [`permissions.md`][permissions-policy] — the permissions members have 17 | 18 | ## Table of contents 19 | 20 | * [Teams](#teams) 21 | * [Organization teams](#organization-teams) 22 | * [unified team](#unified-team) 23 | * [remark team](#remark-team) 24 | * [rehype team](#rehype-team) 25 | * [retext team](#retext-team) 26 | * [redot team](#redot-team) 27 | * [mdx team](#mdx-team) 28 | * [micromark team](#micromark-team) 29 | * [syntax tree team](#syntax-tree-team) 30 | * [vfile team](#vfile-team) 31 | * [Collective teams](#collective-teams) 32 | * [Core team](#core-team) 33 | * [Moderation team](#moderation-team) 34 | * [Glossary](#glossary) 35 | * [Code of conduct](#code-of-conduct) 36 | * [Acknowledgements](#acknowledgements) 37 | * [License](#license) 38 | 39 | ## Teams 40 | 41 | ```text 42 | +-------------------------------------------------+ 43 | | COLLECTIVE | 44 | | core & moderation | 45 | | | 46 | | | 47 | | ORGANIZATIONS | 48 | | +-------------+ +-------------+ +-------------+ | 49 | | | unified | | remark | | rehype | | 50 | | +-------------+ +-------------+ +-------------+ | 51 | | +-------------+ +-------------+ +-------------+ | 52 | | | retext | | redot | | mdx | | 53 | | +-------------+ +-------------+ +-------------+ | 54 | | +-------------+ +-------------+ +-------------+ | 55 | | | micromark | | vfile | | syntax tree | | 56 | | +-------------+ +-------------+ +-------------+ | 57 | +-------------------------------------------------+ 58 | ``` 59 | 60 | The collective is governed by teams. 61 | Teams are scoped to one **organization** or the **collective**, respectively 62 | governing the **projects** or **organizations** under them. 63 | The [core][] and [moderation][] teams are special. 64 | 65 | Teams serve as leadership for their scope. 66 | They: 67 | 68 | * **Set the direction**: 69 | setting the values that are used when making decisions about tradeoffs, 70 | steering the scope toward specific directions, and leading the discussion 71 | for initiatives 72 | * **Shepherd initiatives**: 73 | making stakeholders (people who are strongly affected by decisions) aware of 74 | initiatives, teasing out design tradeoffs and alternatives, and helping 75 | build consensus 76 | * **Accept or reject issues, pull requests, and RFCs**: 77 | deciding on initiatives, whether small or substantial 78 | * **Nominate team members**: 79 | nominating individuals making significant and valuable contributions across 80 | to be part of the team 81 | 82 | Teams should be made up of: 83 | 84 | * **Area experts**: 85 | people who have a lot of interest and expertise in the area covered by the 86 | team, but who may be far less engaged with other areas of the collective 87 | * **Stakeholders**: 88 | people who are strongly affected by decisions in the area of the team, but 89 | who may not be experts in the design or implementation of that area 90 | 91 | How teams communicate internally and externally is left to each team to decide, 92 | but: 93 | 94 | * Discussion should take place as much as possible in public spaces, ideally 95 | on issues, pull requests, or GitHub discussions 96 | * Teams should actively seek out discussion and input from non-members 97 | 98 | ## Organization teams 99 | 100 | **Organization teams** are scoped to an organization and govern the projects 101 | under it. 102 | 103 | They have the same responsibilities as [all teams][all], and additionally: 104 | 105 | * **Escalate initiatives affecting the collective to a collective team** 106 | * **Implement accepted collective-level initiatives** 107 | * **Define policy on what form changes should take**: 108 | such as which can be a direct pull request or RFC, which need to be 109 | escalated, and which can be handled by the team itself 110 | 111 | Organization teams additionally include: 112 | 113 | * **Team lead**: 114 | person responsible for ensuring initiatives are progressing at a reasonable 115 | rate 116 | 117 | ### unified team 118 | 119 | The **unified team** is an *[organization][]* team responsible for 120 | [**@unifiedjs**](https://github.com/unifiedjs). 121 | 122 | 123 | 124 | #### Members 125 | 126 | ##### Releasers 127 | 128 | * Remco Haszing 129 | ([**@remcohaszing**](https://github.com/remcohaszing)) 130 | \ 131 | * Titus Wormer 132 | ([**@wooorm**](https://github.com/wooorm)) 133 | \ 134 | (**lead**) 135 | 136 | ##### Mergers 137 | 138 | * Christian Murphy 139 | ([**@ChristianMurphy**](https://github.com/ChristianMurphy)) 140 | \ 141 | * John Otander 142 | ([**@johno**](https://github.com/johno)) 143 | \ 144 | * Joun Qin 145 | ([**@JounQin**](https://github.com/JounQin)) 146 | \ 147 | * Junyoung Choi 148 | ([**@Rokt33r**](https://github.com/Rokt33r)) 149 | \ 150 | * Merlijn Vos 151 | ([**@Murderlon**](https://github.com/Murderlon)) 152 | \ 153 | 154 | #### Contributors 155 | 156 | * Mudit Ameta 157 | ([**@zeusdeux**](https://github.com/zeusdeux)) 158 | \ 159 | * Stephan Schneider 160 | ([**@zcei**](https://github.com/zcei)) 161 | \ 162 | * Victor Felder 163 | ([**@vhf**](https://github.com/vhf)) 164 | \ 165 | 166 | 167 | 168 | ### remark team 169 | 170 | The **remark team** is an *[organization][]* team responsible for 171 | [**@remarkjs**](https://github.com/remarkjs). 172 | 173 | 174 | 175 | #### Members 176 | 177 | ##### Releasers 178 | 179 | * John Otander 180 | ([**@johno**](https://github.com/johno)) 181 | \ 182 | * Remco Haszing 183 | ([**@remcohaszing**](https://github.com/remcohaszing)) 184 | \ 185 | * Titus Wormer 186 | ([**@wooorm**](https://github.com/wooorm)) 187 | \ 188 | (**lead**) 189 | 190 | ##### Mergers 191 | 192 | * Christian Murphy 193 | ([**@ChristianMurphy**](https://github.com/ChristianMurphy)) 194 | \ 195 | * Jonathan Haines 196 | ([**@BarryThePenguin**](https://github.com/BarryThePenguin)) 197 | \ 198 | * Joun Qin 199 | ([**@JounQin**](https://github.com/JounQin)) 200 | \ 201 | * Junyoung Choi 202 | ([**@Rokt33r**](https://github.com/Rokt33r)) 203 | \ 204 | * Keith McKnight 205 | ([**@kmck**](https://github.com/kmck)) 206 | \ 207 | * Marouane Fazouane 208 | ([**@fazouane-marouane**](https://github.com/fazouane-marouane)) 209 | \ 210 | * Merlijn Vos 211 | ([**@Murderlon**](https://github.com/Murderlon)) 212 | \ 213 | * Victor Felder 214 | ([**@vhf**](https://github.com/vhf)) 215 | \ 216 | * Zeke Sikelianos 217 | ([**@zeke**](https://github.com/zeke)) 218 | \ 219 | 220 | #### Contributors 221 | 222 | * Mudit Ameta 223 | ([**@zeusdeux**](https://github.com/zeusdeux)) 224 | \ 225 | * Nikita Sobolev 226 | ([**@sobolevn**](https://github.com/sobolevn)) 227 | \ 228 | 229 | 230 | 231 | ### rehype team 232 | 233 | The **rehype team** is an *[organization][]* team responsible for 234 | [**@rehypejs**](https://github.com/rehypejs). 235 | 236 | 237 | 238 | #### Members 239 | 240 | ##### Releasers 241 | 242 | * Keith McKnight 243 | ([**@kmck**](https://github.com/kmck)) 244 | \ 245 | * Remco Haszing 246 | ([**@remcohaszing**](https://github.com/remcohaszing)) 247 | \ 248 | * Titus Wormer 249 | ([**@wooorm**](https://github.com/wooorm)) 250 | \ 251 | (**lead**) 252 | 253 | ##### Mergers 254 | 255 | * Christian Murphy 256 | ([**@ChristianMurphy**](https://github.com/ChristianMurphy)) 257 | \ 258 | * John Otander 259 | ([**@johno**](https://github.com/johno)) 260 | \ 261 | * Joun Qin 262 | ([**@JounQin**](https://github.com/JounQin)) 263 | \ 264 | * Merlijn Vos 265 | ([**@Murderlon**](https://github.com/Murderlon)) 266 | \ 267 | 268 | #### Contributors 269 | 270 | * Victor Felder 271 | ([**@vhf**](https://github.com/vhf)) 272 | \ 273 | 274 | 275 | 276 | ### retext team 277 | 278 | The **retext team** is an *[organization][]* team responsible for 279 | [**@retextjs**](https://github.com/retextjs). 280 | 281 | 282 | 283 | #### Members 284 | 285 | ##### Releasers 286 | 287 | * Titus Wormer 288 | ([**@wooorm**](https://github.com/wooorm)) 289 | \ 290 | (**lead**) 291 | 292 | ##### Mergers 293 | 294 | * Merlijn Vos 295 | ([**@Murderlon**](https://github.com/Murderlon)) 296 | \ 297 | 298 | #### Contributors 299 | 300 | * Richard Littauer 301 | ([**@RichardLitt**](https://github.com/RichardLitt)) 302 | \ 303 | 304 | 305 | 306 | ### redot team 307 | 308 | The **redot team** is an *[organization][]* team responsible for 309 | [**@redotjs**](https://github.com/redotjs). 310 | 311 | 312 | 313 | #### Members 314 | 315 | ##### Releasers 316 | 317 | * Christian Murphy 318 | ([**@ChristianMurphy**](https://github.com/ChristianMurphy)) 319 | \ 320 | (**lead**) 321 | * Titus Wormer 322 | ([**@wooorm**](https://github.com/wooorm)) 323 | \ 324 | 325 | ##### Mergers 326 | 327 | None. 328 | 329 | 330 | 331 | ### mdx team 332 | 333 | The **mdx team** is an *[organization][]* team responsible for 334 | [**@mdx-js**](https://github.com/mdx-js). 335 | 336 | 337 | 338 | #### Members 339 | 340 | ##### Releasers 341 | 342 | * John Otander 343 | ([**@johno**](https://github.com/johno)) 344 | \ 345 | (**lead**) 346 | * Remco Haszing 347 | ([**@remcohaszing**](https://github.com/remcohaszing)) 348 | \ 349 | * Tim Neutkens 350 | ([**@timneutkens**](https://github.com/timneutkens)) 351 | \ 352 | * Titus Wormer 353 | ([**@wooorm**](https://github.com/wooorm)) 354 | \ 355 | 356 | ##### Mergers 357 | 358 | * Christopher Biscardi 359 | ([**@ChristopherBiscardi**](https://github.com/ChristopherBiscardi)) 360 | \ 361 | * Joun Qin 362 | ([**@JounQin**](https://github.com/JounQin)) 363 | \ 364 | * Laurie Barth 365 | ([**@laurieontech**](https://github.com/laurieontech)) 366 | * Sidhartha Chatterjee 367 | ([**@sidharthachatterjee**](https://github.com/sidharthachatterjee)) 368 | \ 369 | 370 | #### Contributors 371 | 372 | * Adam Morse 373 | ([**@mrmrs**](https://github.com/mrmrs)) 374 | \ 375 | * Ahmad Awais 376 | ([**@ahmadawais**](https://github.com/ahmadawais)) 377 | \ 378 | * Brent Jackson 379 | ([**@jxnblk**](https://github.com/jxnblk)) 380 | \ 381 | * Guillermo Rauch 382 | ([**@rauchg**](https://github.com/rauchg)) 383 | \ 384 | * Jessica Stokes 385 | ([**@ticky**](https://github.com/ticky)) 386 | \ 387 | * Stephan Schneider 388 | ([**@zcei**](https://github.com/zcei)) 389 | \ 390 | 391 | 392 | 393 | ### micromark team 394 | 395 | The **micromark team** is an *[organization][]* team responsible for 396 | [**@micromark**](https://github.com/micromark). 397 | 398 | 399 | 400 | #### Members 401 | 402 | ##### Releasers 403 | 404 | * Titus Wormer 405 | ([**@wooorm**](https://github.com/wooorm)) 406 | \ 407 | (**lead**) 408 | 409 | ##### Mergers 410 | 411 | * John Otander 412 | ([**@johno**](https://github.com/johno)) 413 | \ 414 | * Joun Qin 415 | ([**@JounQin**](https://github.com/JounQin)) 416 | \ 417 | * Marouane Fazouane 418 | ([**@fazouane-marouane**](https://github.com/fazouane-marouane)) 419 | \ 420 | * Merlijn Vos 421 | ([**@Murderlon**](https://github.com/Murderlon)) 422 | \ 423 | * Remco Haszing 424 | ([**@remcohaszing**](https://github.com/remcohaszing)) 425 | \ 426 | 427 | #### Contributors 428 | 429 | * Mudit Ameta 430 | ([**@zeusdeux**](https://github.com/zeusdeux)) 431 | \ 432 | * Stephan Schneider 433 | ([**@zcei**](https://github.com/zcei)) 434 | \ 435 | * Victor Felder 436 | ([**@vhf**](https://github.com/vhf)) 437 | \ 438 | 439 | 440 | 441 | ### syntax tree team 442 | 443 | The **syntax tree team** is an *[organization][]* team responsible for 444 | [**@syntax-tree**](https://github.com/syntax-tree). 445 | 446 | 447 | 448 | #### Members 449 | 450 | ##### Releasers 451 | 452 | * Keith McKnight 453 | ([**@kmck**](https://github.com/kmck)) 454 | \ 455 | * Titus Wormer 456 | ([**@wooorm**](https://github.com/wooorm)) 457 | \ 458 | (**lead**) 459 | 460 | ##### Mergers 461 | 462 | * Christian Murphy 463 | ([**@ChristianMurphy**](https://github.com/ChristianMurphy)) 464 | \ 465 | * Jonathan Haines 466 | ([**@BarryThePenguin**](https://github.com/BarryThePenguin)) 467 | \ 468 | * Joun Qin 469 | ([**@JounQin**](https://github.com/JounQin)) 470 | \ 471 | * Merlijn Vos 472 | ([**@Murderlon**](https://github.com/Murderlon)) 473 | \ 474 | * Remco Haszing 475 | ([**@remcohaszing**](https://github.com/remcohaszing)) 476 | \ 477 | 478 | 479 | 480 | ### vfile team 481 | 482 | The **vfile team** is an *[organization][]* team responsible for 483 | [**@vfile**](https://github.com/vfile). 484 | 485 | 486 | 487 | #### Members 488 | 489 | ##### Releasers 490 | 491 | * Titus Wormer 492 | ([**@wooorm**](https://github.com/wooorm)) 493 | \ 494 | (**lead**) 495 | 496 | ##### Mergers 497 | 498 | * Christian Murphy 499 | ([**@ChristianMurphy**](https://github.com/ChristianMurphy)) 500 | \ 501 | * Joun Qin 502 | ([**@JounQin**](https://github.com/JounQin)) 503 | \ 504 | * Junyoung Choi 505 | ([**@Rokt33r**](https://github.com/Rokt33r)) 506 | \ 507 | * Remco Haszing 508 | ([**@remcohaszing**](https://github.com/remcohaszing)) 509 | \ 510 | 511 | #### Contributors 512 | 513 | * Olivia Hugger 514 | ([**@komaeda**](https://github.com/komaeda)) 515 | \ 516 | 517 | 518 | 519 | ## Collective teams 520 | 521 | **Collective teams** are scoped to the whole collective and govern the 522 | organizations under it. 523 | 524 | They have the same responsibilities as [all teams][all], and additionally: 525 | 526 | * **De-escalate initiatives to organization teams** 527 | * **Focus on overarching concerns**: 528 | they are specifically designed to take a *global* view of the collective, to 529 | make sure the pieces are fitting together in a coherent way 530 | 531 | ### Core team 532 | 533 | The **core team** is a *[collective][]* team responsible for governing all 534 | other teams. 535 | This team does not have a lead and, to limit conflicts of interest, **should** 536 | not include **[moderation team][moderation]** members. 537 | 538 | They: 539 | 540 | * **Set the direction and vision for the collective across organizations**: 541 | setting the core values that are used when making decisions about tradeoffs, 542 | steering the collective toward specific directions, and leading the 543 | discussion for **major** initiatives 544 | * **Spin up or shut down teams**: 545 | creating teams around new (temporary) areas and dissolving teams when their 546 | area is complete 547 | * **Accept or reject motions**: 548 | deciding on initiatives involving people and destructive actions on projects 549 | * **Follow playbooks**: 550 | following certain steps to enact accepted motions 551 | 552 | 553 | 554 | #### Members 555 | 556 | * Christian Murphy 557 | ([**@ChristianMurphy**](https://github.com/ChristianMurphy)) 558 | \ 559 | * John Otander 560 | ([**@johno**](https://github.com/johno)) 561 | \ 562 | * Merlijn Vos 563 | ([**@Murderlon**](https://github.com/Murderlon)) 564 | \ 565 | * Titus Wormer 566 | ([**@wooorm**](https://github.com/wooorm)) 567 | \ 568 | 569 | #### Contributors 570 | 571 | * Richard Littauer 572 | ([**@RichardLitt**](https://github.com/RichardLitt)) 573 | \ 574 | * Stephan Schneider 575 | ([**@zcei**](https://github.com/zcei)) 576 | \ 577 | 578 | 579 | 580 | ### Moderation team 581 | 582 | The **moderation team** is a *[collective][]* team responsible for enforcing the 583 | code of conduct. 584 | This team does not have a lead and, to limit conflicts of interest, **should** 585 | not include **[core team][core]** members. 586 | 587 | 588 | 589 | #### Members 590 | 591 | * Olivia Hugger 592 | ([**@komaeda**](https://github.com/komaeda)) 593 | \ 594 | * Richard Littauer 595 | ([**@RichardLitt**](https://github.com/RichardLitt)) 596 | \ 597 | 598 | 599 | 600 | ## Glossary 601 | 602 | ###### Collective 603 | 604 | The collective is unified as a whole with the [organization][dfn-organization]s 605 | under it and the [project][dfn-project]s under them. 606 | 607 | ###### Organization 608 | 609 | An organization is a collection of [project][dfn-project]s around a shared area 610 | typically hosted in a GitHub organization. 611 | 612 | ###### Project 613 | 614 | A project is a single repository on GitHub governed by a team. 615 | 616 | ###### Initiative 617 | 618 | An initiative is a (proposed) change. 619 | 620 | ## Code of conduct 621 | 622 | We follow the Contributor Covenant [code of conduct][coc]. 623 | Please read it, as you agree to abide by it by interacting with the collective 624 | spaces (includes any online or offline place such as email, GitHub, npm, or 625 | Twitter). 626 | 627 | ## Acknowledgements 628 | 629 | This project is inspired by the [Rust governance proposal][rust], the [Node 630 | governance docs][node], the [Node admin project][node-admin], the [Electron 631 | governance docs][electron], and [Django’s dissolving of core][django]. 632 | 633 | ## License 634 | 635 | This work is licensed under a 636 | [Creative Commons Attribution 4.0 International License][license]. 637 | 638 | 639 | 640 | [all]: #teams 641 | 642 | [coc]: code-of-conduct.md 643 | 644 | [collective]: #collective-teams 645 | 646 | [core]: #core-team 647 | 648 | [decisions-policy]: decisions.md 649 | 650 | [dfn-organization]: #organization 651 | 652 | [dfn-project]: #project 653 | 654 | [django]: https://github.com/django/deps/blob/HEAD/accepted/0010-new-governance.rst 655 | 656 | [electron]: https://github.com/electron/governance 657 | 658 | [license]: https://creativecommons.org/licenses/by/4.0/ 659 | 660 | [members-policy]: members.md 661 | 662 | [moderation]: #moderation-team 663 | 664 | [moderation-policy]: moderation.md 665 | 666 | [node]: https://github.com/nodejs/node/blob/HEAD/GOVERNANCE.md 667 | 668 | [node-admin]: https://github.com/nodejs/admin 669 | 670 | [organization]: #organization-teams 671 | 672 | [organizations-policy]: organizations.md 673 | 674 | [permissions-policy]: permissions.md 675 | 676 | [rust]: https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md 677 | -------------------------------------------------------------------------------- /script/list-of-humans.js: -------------------------------------------------------------------------------- 1 | /** 2 | * @import {BlockContent, ListItem, List, PhrasingContent, Root} from 'mdast' 3 | * @import {Plugin} from 'unified' 4 | */ 5 | 6 | /** 7 | * @typedef {'contributor' | 'merger' | 'maintainer' | 'releaser'} Role 8 | * 9 | * @typedef Team 10 | * @property {string} name 11 | * @property {boolean | undefined} [collective] 12 | * @property {string | undefined} [lead] 13 | * @property {Record} humans 14 | * 15 | * @typedef Human 16 | * @property {string} name 17 | * @property {string} email 18 | * @property {string} url 19 | * @property {string} github 20 | * @property {string | undefined} [npm] 21 | */ 22 | 23 | import assert from 'node:assert/strict' 24 | import fs from 'node:fs/promises' 25 | import yaml from 'yaml' 26 | import {zone} from 'mdast-zone' 27 | import {commentMarker} from 'mdast-comment-marker' 28 | 29 | /** @type {Array} */ 30 | const humans = yaml.parse( 31 | String(await fs.readFile(new URL('../data/humans.yml', import.meta.url))) 32 | ) 33 | /** @type {Array} */ 34 | const teams = yaml.parse( 35 | String(await fs.readFile(new URL('../data/teams.yml', import.meta.url))) 36 | ) 37 | 38 | const own = {}.hasOwnProperty 39 | 40 | /** @type {Plugin<[], Root>} */ 41 | export default function listOfHumans() { 42 | return function (tree, file) { 43 | zone(tree, 'humans', function (start, nodes, end) { 44 | const parameters = commentMarker(start)?.parameters || {} 45 | const shift = Number(parameters.shift) || 0 46 | const name = parameters.team 47 | 48 | if (!name) { 49 | file.fail('Missing team attribute in humans marker', start) 50 | } 51 | 52 | const team = teams.find((s) => s.name === name) 53 | 54 | if (!team) { 55 | file.fail('Missing definition for team `' + name + '`', start) 56 | return 57 | } 58 | 59 | /** @type {Array} */ 60 | const content = [ 61 | { 62 | type: 'heading', 63 | // @ts-expect-error: fine. 64 | depth: 1 + shift, 65 | children: [{type: 'text', value: 'Members'}] 66 | } 67 | ] 68 | /** @type {Partial>>} */ 69 | const byRole = {} 70 | /** @type {string} */ 71 | let human 72 | 73 | for (human in team.humans) { 74 | if (own.call(team.humans, human)) { 75 | const role = team.humans[human] 76 | const list = byRole[role] 77 | if (Array.isArray(list)) { 78 | list.push(human) 79 | } else { 80 | byRole[role] = [human] 81 | } 82 | } 83 | } 84 | 85 | if (team.collective) { 86 | content.push( 87 | byRole.maintainer 88 | ? list(team, byRole.maintainer) 89 | : {type: 'paragraph', children: [{type: 'text', value: 'None.'}]} 90 | ) 91 | } else { 92 | content.push( 93 | { 94 | type: 'heading', 95 | // @ts-expect-error: fine. 96 | depth: 2 + shift, 97 | children: [{type: 'text', value: 'Releasers'}] 98 | }, 99 | byRole.releaser 100 | ? list(team, byRole.releaser) 101 | : {type: 'paragraph', children: [{type: 'text', value: 'None.'}]}, 102 | { 103 | type: 'heading', 104 | depth: 2 + shift, 105 | children: [{type: 'text', value: 'Mergers'}] 106 | }, 107 | byRole.merger 108 | ? list(team, byRole.merger) 109 | : {type: 'paragraph', children: [{type: 'text', value: 'None.'}]} 110 | ) 111 | } 112 | 113 | if (byRole.contributor) { 114 | content.push( 115 | { 116 | type: 'heading', 117 | // @ts-expect-error: fine. 118 | depth: 1 + shift, 119 | children: [{type: 'text', value: 'Contributors'}] 120 | }, 121 | list(team, byRole.contributor) 122 | ) 123 | } 124 | 125 | return [start].concat(content, end) 126 | }) 127 | } 128 | } 129 | 130 | /** 131 | * @param {Team} team 132 | * @param {Array} users 133 | * @returns {List} 134 | */ 135 | function list(team, users) { 136 | return { 137 | type: 'list', 138 | ordered: false, 139 | spread: false, 140 | children: users 141 | .map((github) => { 142 | const human = humans.find((p) => p.github === github) 143 | assert(human, 'expected human') 144 | return human 145 | }) 146 | .sort((a, b) => { 147 | return a.name.localeCompare(b.name) 148 | }) 149 | .map((human) => { 150 | /** @type {Array} */ 151 | const content = [ 152 | {type: 'text', value: human.name + '\n('}, 153 | { 154 | type: 'link', 155 | url: 'https://github.com/' + human.github, 156 | children: [ 157 | { 158 | type: 'strong', 159 | children: [{type: 'text', value: '@' + human.github}] 160 | } 161 | ] 162 | }, 163 | {type: 'text', value: ')'} 164 | ] 165 | 166 | if (human.email) { 167 | content.push({type: 'text', value: '\n<' + human.email + '>'}) 168 | } 169 | 170 | if (human.github === team.lead) { 171 | content.push( 172 | {type: 'text', value: '\n('}, 173 | {type: 'strong', children: [{type: 'text', value: 'lead'}]}, 174 | {type: 'text', value: ')'} 175 | ) 176 | } 177 | 178 | /** @type {ListItem} */ 179 | const result = { 180 | type: 'listItem', 181 | children: [{type: 'paragraph', children: content}] 182 | } 183 | 184 | return result 185 | }) 186 | } 187 | } 188 | -------------------------------------------------------------------------------- /tsconfig.json: -------------------------------------------------------------------------------- 1 | { 2 | "compilerOptions": { 3 | "checkJs": true, 4 | "customConditions": ["development"], 5 | "declarationMap": true, 6 | "declaration": true, 7 | "emitDeclarationOnly": true, 8 | "exactOptionalPropertyTypes": true, 9 | "lib": ["es2020"], 10 | "module": "node16", 11 | "strict": true, 12 | "target": "es2020" 13 | }, 14 | "exclude": ["coverage/", "node_modules/"], 15 | "include": ["**/*.js"] 16 | } 17 | --------------------------------------------------------------------------------