Skip to content

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
Ready for triage For all issues/PRs with needs-triage label, Maintainers/committers
will assign a suitable active community member as owner to
start evaluating issue/PR . Owner and community will evaluate
merit and characteristics of issue/PR asynchronously and assign approapriate labels.
When owner believes that sufficient details have been added
and there is concensus, the owner would remove
needs-triage label and apply label ready-for-triage.
Triaged All issues/PRs with 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, label triaged is added and 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 |


Last update: 2022-06-15
Created: 2022-01-27