Janssen Triage Process and labels#
Triage process is used to quickly screen and categorise new issues and PRs. Aim is to determine characteristics of new PRs/issues and take quick actions if possible.
Triage process is a contineous process. As new issues/PRs come in, the community initiates discussions, add labels, ask for more details. This process does not wait for triage call or a meeting to be called.
Community holds triage calls at a regular cadence. Triage calls are mainly utilised to discuss issue/PR where concensus is not yet reached and to pick up anything which is not yet triaged. It is encouraged to complete triage outside of triage call to improve velocity.
Stages in triage process:#
| Name | Description |
|---|---|
| Needs triage | When a new issue or PR is created, it is automatically labeled as needs-triage. The label indicates that this issue is missing some of the metadata. Metadata such as the missing owner. Or the owner needs to add metadata labels for effort, priority, kind and component. Once these labels are added, the owner should remove this label and add ready-for-triage label. |
| Ready for triage | This label indicates that the issue has enough information and can be triaged. |
| Triaged | All issues/PRs with the label ready-for-triage will be reviewed by core members of the community who have permission to add triaged label. Reviewer reviews issue/PR to check if the issue/PR is fully triaged and can be added to backlog without discussion on triage call. At this point, the label triaged is added and the label ready-for-triage is removed. |
We expect most of the isseus and PRs will be able to follow above path and quickly move out of triage process without waiting for triage call. Issues/PRs which still doesn't have triaged label, or has needs-discussion label, will be discussed during triage call.
Labels#
Github labels help us annotate issues/PRs with additional data. Janssen community uses labels, as detailed below, to communicate information and help making decisions about issues/PRs.
Communication labels#
These labels communicate status of current triage process for an issue/PR or indicate where community contribution is required. Most of communication labels would be replaced by other labels as triage process progresses and issue enters active development. For example, help wanted label would be removed once issue gets under active development and a community members takes ownership of the issue. Below is the list of labels which fall under this category:
| Label | Indicates That |
|---|---|
needs-triage |
issue/PR needs triaging |
ready-for-triage |
that sufficient details has been added to the issue/PR in form of labels and is ready for triage review |
triaged |
Issue/PR is fully triaged |
needs-information |
Indicates that creator needs to add more information to issue/PR in order to be meaningfully triaged. When adding this label, also comment on the issue about what information is needed |
needs-discussion |
Indicates that issue needs discussion during triage meeting. When adding this label, also comment on the issue about what is it that demands discussion on this issue |
good first issue |
Indicates to the community that this issue suitable for first time contributor |
help wanted |
Indicates to the community that this issue has complexity which is suitable for contribution from any external contributor |
Metadata labels#
These labels enrich issue/PR with metadata that will help during triage process and active development. These labels may not be removed from issue/PR, though value of labels may change as development progresses. For example, effort label may change from effort-3 to effort-8 as we understand issue in more detail. Below is the list of labels in this category:
| Label | Indicates That | Details |
|---|---|---|
comp-<module> |
Major Janssen components needing change in order to fix this issue/PR. For example, if this issue/PR would require change in files under fido2 module (under jans/fido2) , then apply comp-jans-fido2 label |
e.g comp-jans-auth-server,comp-jans-fido2, |
area-<concern> |
Cross-cutting concerns involved in fixing this issue/PR. For example, if changes introduced by this issue/PR will need changes in documentation and need to be mentioned in release notes as well, then apply area-documentation, area-release-notes. area-CI should be applied when changes are required in artifacts relevent to automation, CI build infrastructure or release management process. An example of such artifact would be Github workflow scripts located under .github/workflows |
Labels available: area-documentation, area-release-notes, area-CI |
kind-bug |
Issue/PR is a bug in existing functionality | |
kind-enhancement |
Issue/PR is an enhancement to an existing functionality | |
kind-feature |
Issue/PR is new feature request | |
kind-question |
Issue/PR is a question that can be addressed via pointers to documentation or user education | |
kind-duplicate |
Issue/PR is a duplicate of existing issue/PR. Original issue should be mentioned in the comments using Duplicate of reply | |
kind-dependencies |
Fix for Issue/PR pertains to external dependencies | |
effort-1 |
Relative effort required for completion | |
effort-2 |
Relative effort required for completion | |
effort-3 |
Relative effort required for completion | |
effort-5 |
Relative effort required for completion | |
effort-8 |
Relative effort required for completion | |
effort-13 |
Relative effort required for completion | |
effort-21 |
Relative effort required for completion | |
priority-0 |
An issue that causes a full outage, breakage, or major function unavailability for everyone, without any known workaround. The issue must be fixed immediately, taking precedence over all other work. Should receive updates at least once per day. | |
priority-1 |
An issue that significantly impacts a large percentage of users; if there is a workaround it is partial or overly painful. The issue should be resolved before the next release. | |
priority-2 |
The issue is important to a large percentage of users, with a workaround. Issues that are significantly ugly or painful (especially first-use or install-time issues). Issues with workarounds that would otherwise be P0 or P1. | |
priority-3 |
An issue that is relevant to core functions, but does not impede progress. Important, but not urgent. | |
priority-4 |
A relatively minor issue that is not relevant to core functions, or relates only to the attractiveness or pleasantness of use of the system. Good to have but not necessary changes/fixes. | |
priority-5 |
The team acknowledges the request but (due to any number of reasons) does not plan to work on or accept contributions for this request. The issue remains open for discussion. |
Bot labeling methodology#
The following labels are automatically assigned to Issues and PRs in GitHub following the schema provided in this file.
| Label | Method |
|---|---|
comp-<module> |
The bot will detect from the title the component between the parentheses. feat(jans-auth-server): detect will result in the label comp-jans-auth-server added to the issue or PR. In a PR these labels are also detected by modified files path |
area-<concern> |
The bot will detect from the title the area appropriate. ci: adding something new to our ci will result in the label area-CI added to the issue or PR. In a PR these labels are also detected by modified files path. |
kind-bug |
The bot will detect this from the conventional commit written title |
kind-enhancement |
The bot will detect this from the conventional commit written title |
kind-feature |
The bot will detect this from the conventional commit written title |
kind-question |
Issue/PR is a question that can be addressed via pointers to documentation or user education |
kind-dependencies |
The bot will detect this from the conventional commit written title |
Created: 2022-01-27
