Skip to content

Commit

Permalink
docs: formalized v1 maintenance docs
Browse files Browse the repository at this point in the history
  • Loading branch information
JoshuaKGoldberg committed Dec 3, 2023
1 parent b872154 commit 1aabf91
Show file tree
Hide file tree
Showing 13 changed files with 370 additions and 22 deletions.
29 changes: 29 additions & 0 deletions docs/Maintenance.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -12,3 +12,32 @@ We keep it in the open for visibility into our processes.
If you're reading this as a new maintainer: welcome!
We're happy to have you! ❤️‍🔥
:::

## Governance

We follow a loose governance model that covers roles on the maintenance team and their associated responsibilities.
We see a few major benefits from doing so:

- We want it to be clear how & why we do the things we do _(especially around compensation and expectations around roles)_
- We want community input to make sure we're doing things the right way & focusing on truly useful improvements
- As we add to the processes over time, it'll be easier to make those changes clear & reviewable by everyone

The following pages are a rough "v1.x" of our governance.
We do our best to roughly adhere to this model - though at times we may shortcut tasks if there is no downside in doing so.

### Changes to Governance

Any changes to this document will be posted for open discussion on the [typescript-eslint GitHub Discussions](https://github.com/typescript-eslint/typescript-eslint/discussions) and kept open for at least one month.
The discussion will be shared at the beginning, middle, and end of that month on Discord and all our social media accounts.

## Providing Feedback

We're always receptive to suggestions on how to improve our processes!
For general feedback, we'd suggest posting in the [`#TODO` channel on Discord](https://discord.gg/TODO).
We can help you turn that into a GitHub discussion.

:::note
Please be kind: open source governance is an unsolved challenge.
We might not know what impractical or non-ideal things we're doing.
If there's anything sensitive you don't feel comfortable talking about in public, you can always DM or email one of the maintainers privately.
:::
177 changes: 177 additions & 0 deletions docs/maintenance/Contributor_Tiers.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,177 @@
---
id: contributor-tiers
title: Contributor Tiers
---

These tiers of contributors, committers, and maintainers roughly reflect how we've worked the past several years.

<table>
<thead>
<tr>
<th>Tier</th>
<th>Entry Requirements</th>
<th>Monthly Expectations</th>
<th>Monthly Reimbursement</th>
</tr>
</thead>
<tbody>
<tr>
<th>Contributor</th>
<td>1 point</td>
<td>
<em>(none)</em>
</td>
<td>
<em>(none)</em>
</td>
</tr>
<tr>
<th>Code Contributor</th>
<td>1 point in pull requests</td>
<td>
<em>(none)</em>
</td>
<td>
<em>(none)</em>
</td>
</tr>
<tr>
<th>Committer</th>
<td>
~5 points in issues
<br />
~5 points in pull requests
<br />
~15 points total
<br />2 of 4 consecutive active months
</td>
<td>~10 points</td>
<td>~1 share / active month</td>
</tr>
<tr>
<th>Maintainer</th>
<td>
~10 points in issues
<br />
~10 points in pull requests
<br />
~30 points total
<br />3 of 6 active months
</td>
<td>~20 points</td>
<td>~2 shares / active month</td>
</tr>
</tbody>
</table>

:::note
We treat everything here as approximate numbers.
We're a small enough team to informally discuss changes ad hoc and allow off-by-one-or-two months.
:::

## Pointing

Although it's impossible to accurately estimate software projects, we want to roughly establish expectations of effort+time spent on the tiers.
These are all rough estimations and should be taken as approximate starting guides to consider.

We treat both the creation and review of issues and PRs along the rough scale of:

<table>
<thead>
<tr>
<th>Size</th>
<th>Description</th>
<th>Points</th>
<th>Examples</th>
</tr>
</thead>
<tbody>
<tr>
<th>Trivial</th>
<td>Small typos or single-file bugfixes</td>
<td>1</td>
<td>
<a href="https://github.com/typescript-eslint/typescript-eslint/issues/6976">
#6976
</a>
, <a href="https://github.com/typescript-eslint/typescript-eslint/issues/6992">#6992</a>
</td>
</tr>
<tr>
<th>Straightforward</th>
<td>2-3 files at most, with minimal logical changes</td>
<td>2</td>
<td>
<a href="https://github.com/typescript-eslint/typescript-eslint/issues/6780">
#6780
</a>
, <a href="https://github.com/typescript-eslint/typescript-eslint/issues/6910">#6910</a>
</td>
</tr>
<tr>
<th>Large</th>
<td>Multi-file logical changes that require real review+thought</td>
<td>3</td>
<td>
<a href="https://github.com/typescript-eslint/typescript-eslint/issues/6107">
#6107
</a>
, <a href="https://github.com/typescript-eslint/typescript-eslint/issues/6907">#6907</a>
</td>
</tr>
<tr>
<th>Unusual</th>
<td>Dozen+ file logical changes that require deep investigation</td>
<td>≥5*</td>
<td>
<a href="https://github.com/typescript-eslint/typescript-eslint/issues/6084">
#6084
</a>
, <a href="https://github.com/typescript-eslint/typescript-eslint/issues/6777">#6777</a>
</td>
</tr>
</tbody>
</table>

> \*Unusually large efforts may be >5 points at maintainer discretion depending on time spent.
Any other activities (e.g. responding to Discord threads, working on upstream dependencies, …) should be treated as gaining points equal to their nearest equivalent point task in terms of complexity and effort.

## Advancement

Each tier corresponds to a role on Discord.
When you first hit a tier, you can post in the [`#contributing` channel on Discord](https://discord.gg/TODO).

We will confirm privately that you've hit the intent of the contribution tiers.
We'll then grant you the role on Discord and profusely thank you for everything you've done. ❤️

### Recognition

Depending on the tier you reach, you can also provide information for the [Team page](./Team.mdx):

- Contributor and Code Contributor: Preferred photo, name, social media handles
- Committer and Maintainer: ~2 paragraph bio of yourself

See existing bios for examples of what to put.

:::note
You can decline to opt into the Discord role or site recognition, and you can always opt out after the fact.
Nothing is mandatory.
We just like including recognition as thanks to the community for working with us. 💕
:::

## Reimbursement

Team members will be reimbursed the minimum of their activity level and their tier.
Each month:

- Committers and maintainers who hit their expectation receive their full shares
- Committers and maintainers who hit roughly half their expectation receive half shares

Reimbursements are generally handled through [our Open Collective page](https://opencollective.com/typescript-eslint).

### Community Reimbursements

Contributors who contribute nontrivial changes in a month (roughly ≥5 points and at least one _Large_ item) may be privately nominated at any time by a committer or maintainer to be reimbursed at the equivalent shares.

Our intention is to always do this for contributors who submit _Large_ or greater contributions and don't need significant assistance in getting them merged.
4 changes: 4 additions & 0 deletions docs/maintenance/Governance.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
---
id: governance
title: Governance
---
17 changes: 14 additions & 3 deletions docs/maintenance/Issues.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -13,6 +13,17 @@ It's imperative we give them a positive, uplifting experience.
If you're ever unsure on any part of issue management, don't hesitate to loop in a maintainer that has more context to help!
:::

## Governance

Per the scales from [Contribution Tiers > Pointing](./Contributor_Tiers.mdx#pointing):

- Straightforward: at reviewer discretion, may be marked as approved by any committer or maintainer.
This includes docs enhancements, bug fixes, and feature additions.
- Non-straightforward: may be marked as approved with either two committer approvals or one maintainer approval.
These include significant internal refactors and non-breaking public API changes.
- "Unusual"-categorized: require a public discussion followed by two maintainer approvals.
These include significant refactors with cross-project and public API ramifications.

## Issue Flow

:::note
Expand Down Expand Up @@ -135,6 +146,6 @@ Every so often, we like to [search for open issues `awaiting response`](https://
Our flow for issues that have been waiting for >=1 month is:

1. Ping the author with a message like the _Checking In_ template
2. Add the `stale` label to the issue
3. Wait 2 weeks
4. If they still haven't responded, close the issue with a message like the _Pruning Stale Issue_ template
1. Add the `stale` label to the issue
1. Wait 2 weeks
1. If they still haven't responded, close the issue with a message like the _Pruning Stale Issue_ template
11 changes: 11 additions & 0 deletions docs/maintenance/Pull_Requests.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -13,6 +13,17 @@ It's imperative we give them a positive, uplifting experience.
If you're ever unsure on any part of PR reviews, don't hesitate to loop in a maintainer that has more context to help!
:::

## Governance

Per the scales from [Contribution Tiers > Pointing](./Contributor_Tiers.mdx#pointing):

- Straightforward: Aat reviewer discretion, may be merged with a single approval by any committer or maintainer.
This includes docs enhancements, bug fixes, and feature additions.
- Non-straightforward: may be merged with either two committer approvals or one maintainer approval.
These include multi-package internal refactors and non-breaking public API changes.
- "Unusual"-categorized: require two maintainer approvals.
These include significant refactors with cross-project and public API ramifications.

## PR Flow

:::note
Expand Down
Original file line number Diff line number Diff line change
@@ -1,9 +1,18 @@
---
id: major-release-steps
title: Major Release Steps
id: releases
title: Releases
---

## 1. Pre-Release Preparation
[Users > Releases](../users/Releases.mdx) describes how our automatic releases are done.
There is generally no maintenance activity we need to take for the weekly releases.

However, there are two kinds of releases we infrequently go through that each require manual effort.

## Major Releases

Per [Users > Releases > Major Releases](../users/Releases.mdx#major-releases), we infrequently release major versions with accumulated breaking changes.

### 1. Pre-Release Preparation

1. Create a milestone by the name of the release [example: [Milestone 6.0.0](https://github.com/typescript-eslint/typescript-eslint/milestone/8)].
1. If an issue for changes to recommended rule configs doesn't yet exist, create one [example: [Changes to the `recommended` sets for 5.0.0](https://github.com/typescript-eslint/typescript-eslint/issues/5900)].
Expand All @@ -18,7 +27,7 @@ title: Major Release Steps
- Its publish command should be `npx lerna publish premajor --loglevel=verbose --canary --exact --force-publish --yes --dist-tag rc-v${major}`.
- Merge this into `main` once reviewed and rebase the `v${major}` branch.

## 2. Merging Breaking Changes
### 2. Merging Breaking Changes

1. Send a PR from `v${major}` to `main` [example: [v6.0.0](https://github.com/typescript-eslint/typescript-eslint/pull/5886)].
1. Change all [breaking change PRs](https://github.com/typescript-eslint/typescript-eslint/issues?q=is%3Aissue+is%3Aopen+label%3A%22breaking+change%22) to target the `v${major}` branch.
Expand All @@ -34,11 +43,21 @@ _Non_-breaking changes can be merged to `main` or the major branch.
They don't need any special treatment.
:::

## 3. Releasing the Version
### 3. Releasing the Version

1. Discuss with the maintainers to be ready for an [out-of-band](#out-of-band) release. Doing this manually helps ensure someone is on-hand to action any issues that might arise from the major release.
1. Discuss with the maintainers to be ready for an [out-of-band](#out-of-band-releases) release. Doing this manually helps ensure someone is on-hand to action any issues that might arise from the major release.
1. Prepare the release notes. Lerna will automatically generate the release notes on GitHub, however this will be disorganized and unhelpful for users. We need to reorganize the release notes so that breaking changes are placed at the top to make them most visible. If any migrations are required, we must list the steps to make it easy for users.
- Example release notes: [`v5.0.0`](https://github.com/typescript-eslint/typescript-eslint/releases/tag/v5.0.0), [`v4.0.0`](https://github.com/typescript-eslint/typescript-eslint/releases/tag/v4.0.0), [`v3.0.0`](https://github.com/typescript-eslint/typescript-eslint/releases/tag/v3.0.0)
1. Finally, tweet the release on the `@tseslint` twitter with a link to the GitHub release. Make sure you include additional information about the highlights of the release!

- Example release notes: [`v5.0.0`](https://github.com/typescript-eslint/typescript-eslint/releases/tag/v5.0.0), [`v4.0.0`](https://github.com/typescript-eslint/typescript-eslint/releases/tag/v4.0.0), [`v3.0.0`](https://github.com/typescript-eslint/typescript-eslint/releases/tag/v3.0.0)
## Out-of-Band Releases

1. Finally, tweet the release on the `@tseslint` twitter with a link to the GitHub release. Make sure you include additional information about the highlights of the release!
Per [Users > Releases > Out-of-Band Releases](../users/Releases.mdx#out-of-band-releases), we may manually trigger a new release for a rare emergency such as a critical regression.
If that happens:

1. Mention in any relevant issue(s) that you intend to release an out-of-band release
1. Post in a private maintenance Discord channel that you're working on it
1. Send a pull request resolving the issue(s)
1. Waiting up to a day (as reasonable) for approval before merging the PR
1. Trigger the [TODO](https://github.com/TODO) workflow to cause a new release
1. Post back in those same issue(s) with a link to the newly released version(s)
45 changes: 45 additions & 0 deletions docs/maintenance/Team.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
---
id: team
title: Team
---

import { TeamBioList } from '@site/src/components/team/TeamBioList';

## Maintainers

<TeamBioList
bios={[
{
description: 'Lorem ipsum.',
photo: '',
name: 'Brad Zacher',
},
{
description: 'Lorem ipsum.',
photo: '',
name: 'James Henry',
},
{
description: 'Lorem ipsum.',
photo: '',
name: 'Josh Goldberg',
},
]}
/>

## Committers

<TeamBioList
bios={[
{
description: 'Lorem ipsum.',
photo: '',
name: 'Armano2',
},
{
description: 'Lorem ipsum.',
photo: '',
name: 'Joshua Chen',
},
]}
/>
Original file line number Diff line number Diff line change
Expand Up @@ -31,7 +31,7 @@ Whenever you discover any new areas of work that are blocked by dropping an old
1. Upgrade the root `package.json` `devDependency` to the latest ESLint
1. Add the new major version to the explicit `peerDependency` versions
1. Check [`eslint-visitor-keys`](https://www.npmjs.com/package/eslint-visitor-keys) for a new version to be upgraded to as well.
1. Update [Users > Dependency Versions > ESLint](../users/Dependency_Versions.mdx#eslint)
1. Update [Users > Dependency Versions > ESLint](../../users/Dependency_Versions.mdx#eslint)

### Removing Support for an Old ESLint Version

Expand All @@ -42,7 +42,7 @@ Whenever you discover any new areas of work that are blocked by dropping an old
- `/eslint.*5/i`
- `/todo.*eslint.*5/i`
- `/todo.*eslint/i`
1. Update [Users > Dependency Versions > ESLint](../users/Dependency_Versions.mdx#eslint)
1. Update [Users > Dependency Versions > ESLint](../../users/Dependency_Versions.mdx#eslint)

See [chore: drop support for ESLint v6](https://github.com/typescript-eslint/typescript-eslint/pull/5972) for reference.

Expand Down Expand Up @@ -115,7 +115,7 @@ A single PR can remove support for old TypeScript versions as a breaking change:
1. Update the root `package.json` `devDependency`
1. Update the `SUPPORTED_TYPESCRIPT_VERSIONS` constant in `warnAboutTSVersion.ts`
1. Update the `versions` constant in `version-check.ts`
1. Update [Users > Dependency Versions > TypeScript](../users/Dependency_Versions.mdx#typescript)
1. Update [Users > Dependency Versions > TypeScript](../../users/Dependency_Versions.mdx#typescript)
1. Search for source code comments (excluding `CHANGELOG.md` files) that mention a now-unsupported version of TypeScript.
- For example, to remove support for v4.3, searches might include:
- `4.3`
Expand Down
2 changes: 1 addition & 1 deletion docs/users/Dependency_Versions.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -55,4 +55,4 @@ See: [Packages > Parser > `warnOnUnsupportedTypeScriptVersion`](../packages/Pars

## Dependant Version Upgrades

See [Maintenance > Dependent Version Upgrades](../maintenance/Dependency_Version_Upgrades.mdx) for maintenance steps to update these versions.
See [Maintenance > Dependent Version Upgrades](../maintenance/pull-requests/Dependency_Version_Upgrades.mdx) for maintenance steps to update these versions.

0 comments on commit 1aabf91

Please sign in to comment.