forked from ArchipelagoMW/Archipelago
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Docs: Triage role expectations documentation.
- Loading branch information
Showing
1 changed file
with
100 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,100 @@ | ||
| # Triage Role Expectations | ||
|
|
||
| Users with Triage-level access are selected contributors who can proactively label/triage issues and pull requests | ||
| without write access to the Archipelago repository. | ||
|
|
||
| Triage users are not necessarily official members of the Archipelago organization, for the list of core maintainers, | ||
| please reference [ArchipelagoMW Members](https://github.com/orgs/ArchipelagoMW/people) page. | ||
|
|
||
| ## Access Permissions | ||
|
|
||
| Triage users have the following permissions: | ||
|
|
||
| * Apply/dismiss labels on all issues and pull requests. | ||
| * Close, reopen, and assign all issues and pull requests. | ||
| * Mark issues and pull requests as duplicate. | ||
| * Request pull request reviews from repository members. | ||
| * Hide comments in issues or pull requests from public view. | ||
| * Hidden comments are not deleted and can be reversed by another triage user or repository member with write access. | ||
| * And all other standard permissions granted to regular GitHub users. | ||
|
|
||
| For more details on permissions granted by the Triage role, see | ||
| [GitHub's Role Documentation](https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization). | ||
|
|
||
| ## Expectations | ||
|
|
||
| Users with triage-level permissions have no expectation to review code, but, if desired, to review pull requests/issues | ||
| and apply the relevant labels and ping any relevant [code owners](./CODEOWNERS) for review. Triage users are also not | ||
| expected to close others' issues or pull requests without strong reason to do so (with exception of `meta: invalid` or | ||
| `meta: duplicate` scenarios, which are listed below). When in doubt, defer to a core maintainer. | ||
|
|
||
| Triage users are not "moderators" for others' issues or pull requests. However, they may voice their opinions/feedback | ||
| on issues or pull requests, just the same as any other GitHub user contributing to Archipelago. | ||
|
|
||
| ## Labeling | ||
|
|
||
| As of the time of writing this document, there are 15 distinct labels that can be applied to issues and pull requests. | ||
|
|
||
| ### Affects | ||
|
|
||
| These labels notate if certain issues or pull requests affect critical aspects of Archipelago that may require specific | ||
| review. Multiple of these labels can be used in a single issue or pull request if relevant. | ||
|
|
||
| * `affects: core` is to be applied on any issues/PRs that may affect core Archipelago functionality and should have | ||
| additional scrutiny by pull request reviewers. | ||
| * Core is defined as any files not contained in the `WebHostLib` directory or individual world implementations | ||
| directories inside the `worlds` directory, not including `worlds/generic`. | ||
| * `affects: webhost` is to be applied on any issues/PRs that may affect the core WebHost portion of Archipelago. In | ||
| general, this is anything being modified inside the `WebHostLib` directory or `WebHost.py` file. | ||
| * `affects: release/blocker` is to be applied for any issues/PRs that may either negatively impact (issues) or propose | ||
| to resolve critical issues (pull requests) that affect the current or next official release of Archipelago and should be | ||
| given top priority for review. | ||
|
|
||
| ### Is | ||
|
|
||
| These labels notate what kinds of changes are being made or proposed in issues or pull requests. Multiple of these | ||
| labels can be used in a single issue or pull request if relevant, but at least one of these labels should be applied on | ||
| all pull requests and issues. | ||
|
|
||
| * `is: bug/fix` is to be applied on any issues/PRs that report or resolve an issue in core, web, or individual world | ||
| implementations. | ||
| * `is: documentation` is to be applied on any issues/PRs that relate to adding, updating, or removing documentation in | ||
| core, web, or individual world implementations without modifying actual code. | ||
| * `is: enhancement` is to be applied on any issues/PRs that relate to adding, modifying, or removing functionality in | ||
| core, web, or individual world implementations. | ||
| * `is: refactor/cleanup` is to be applied on any issues/PRs that relate to reorganizing existing code to improve | ||
| readability or performance without adding, modifying, or removing functionality or fixing known regressions. | ||
| * `is: maintenance` is to be applied on any issues/PRs that don't modify logic, refactor existing code, change features. | ||
| This is typically reserved for pull requests that need to update dependencies or increment version numbers without | ||
| resolving existing issues. | ||
| * `is: new game` is to be applied to any pull requests that introduce a new game for the first time to the `worlds` | ||
| directory. | ||
| * Issues should not be opened and classified with `is: new game`, and instead should be directed to the | ||
| #future-game-design channel in Archipelago for opening suggestions. If they are opened, they should be labeled | ||
| with `meta: invalid` and closed. | ||
| * Pull requests for new games should only have this label, as enhancement, documentation, bug/fix, refactor, and | ||
| possibly maintenance is implied. | ||
|
|
||
| ### Meta | ||
|
|
||
| These labels allow additional quick meta information for contributors or reviewers for issues and pull requests. They | ||
| have specific situations where they should be applied. | ||
|
|
||
| * `meta: duplicate` is to be applied to any issues/PRs that are duplicate of another issue/PR that was already opened. | ||
| * These should also be immediately closed afterwards after directing to the original request. | ||
| * `meta: invalid` is to be applied to any issues/PRs that do not relate to Archipelago or are inappropriate for | ||
| discussion on GitHub. | ||
| * These should also be immediately closed afterwards. | ||
| * `meta: help wanted` is to be applied to any issues/PRs that require additional attention for whatever reason. | ||
| * These should also include a comment describing what kind of help is requested when the label is added. | ||
| * Some common reasons include, but are not limited to: Breaking API changes that require developer input/testing or | ||
| pull requests with large line changes that need additional reviewers to be reviewed effectively. | ||
| * This label may require some programming experience and familiarity with Archipelago source to determine if | ||
| additional help is warranted. | ||
| * `meta: good first issue` is to be applied to any issues that may be a good starting ground for new contributors to try | ||
| and tackle. | ||
| * This label might require some programming experience and familiarity with Archipelago source to determine if an | ||
| issue is a "good first issue". | ||
| * `meta: wontfix` is to be applied for any issues/PRs that are opened that will not be actioned because it's out of | ||
| scope or determined to not be an issue. | ||
| * This should be reserved for use by a world's codeowner(s) on its relevant world or by core maintainers. |