generated from nhcarrigan/template
feat: add new labels
This commit is contained in:
+365
-181
@@ -6,443 +6,627 @@ We use very specific labels to help categorise our issues. This page explains wh
|
||||
|
||||
## 1. Contribution Labels
|
||||
|
||||
These are the most important. These labels indicate who is encouraged to make a pull request to resolve the issue.
|
||||
These are the most important. These labels indicate who is encouraged to make a pull request to resolve the issue. All contributions are limited to our volunteer staff team members.
|
||||
|
||||
### 1.1. `contribute: good first issue`
|
||||
|
||||
#### 1.1.1. Purpose
|
||||
|
||||
Identifies issues suitable for contributors who are new to the project.
|
||||
Identifies issues suitable for team members who are learning a new codebase.
|
||||
|
||||
#### 1.1.2. Characteristics
|
||||
|
||||
Does not require prior knowledge of the codebase. Issues with this label should include a detailed description of the implementation process.
|
||||
Does not require prior knowledge of the codebase. Issues with this label should include a detailed description of the implementation process to help team members get familiar with the project structure.
|
||||
|
||||
#### 1.1.3. Expectations
|
||||
|
||||
Contributors are responsible for ensuring their work complies with the project's licensing terms and contribution guidelines.
|
||||
Team members are responsible for ensuring their work complies with the project's licensing terms and contribution guidelines.
|
||||
|
||||
### 1.2. `contribute: help wanted`
|
||||
|
||||
#### 1.2.1. Purpose
|
||||
|
||||
Indicates issues open for contribution from any interested party.
|
||||
Indicates issues open for any team member to grab and work on.
|
||||
|
||||
#### 1.2.2. Characteristics
|
||||
|
||||
Typically assumes prior experience with the codebase. As such, issues may not include a detailed implementation description.
|
||||
Open to all volunteer staff team members. May assume some familiarity with the codebase, and issues may not include a detailed implementation description.
|
||||
|
||||
#### 1.2.3. Expectations
|
||||
|
||||
Contributors should review and adhere to the project's contribution guidelines and code of conduct before submitting work on these issues.
|
||||
Team members should review and adhere to the project's contribution guidelines and code of conduct before submitting work on these issues.
|
||||
|
||||
### 1.3. `contribute: staff only`
|
||||
|
||||
#### 1.3.1. Purpose
|
||||
|
||||
Designates issues restricted to project maintainers or staff due to specific access requirements.
|
||||
Designates issues restricted to executive leadership due to specific access requirements or strategic decisions.
|
||||
|
||||
#### 1.3.2. Characteristics
|
||||
|
||||
Requires access to production infrastructure for proper testing and implementation. As such, limited to authorised project maintainers and staff.
|
||||
Requires executive-level access, decision-making authority, or involves strategic project direction. Limited to authorised executive leadership team members.
|
||||
|
||||
#### 1.3.3. Expectations
|
||||
|
||||
Staff members working on these issues must adhere to all relevant confidentiality agreements, data protection policies, and internal security protocols.
|
||||
Executive leadership members working on these issues must adhere to all relevant confidentiality agreements, data protection policies, and internal security protocols.
|
||||
|
||||
### 1.4. Disclaimer
|
||||
|
||||
Labels are assigned based on the project maintainers' best judgement but may not guarantee the exact level of difficulty or access requirements for every contributor. Contributors should use their discretion and communicate with project maintainers if they have any doubts about their ability to address an issue or comply with any associated legal requirements.
|
||||
Labels are assigned based on the project maintainers' best judgement but may not guarantee the exact level of difficulty or access requirements for every team member. Team members should use their discretion and communicate with project maintainers if they have any doubts about their ability to address an issue or comply with any associated legal requirements.
|
||||
|
||||
## 2. Aspect Labels
|
||||
## 2. Points Labels
|
||||
|
||||
These labels indicate the scope of the work required to resolve the issue.
|
||||
Points labels indicate the complexity and effort required to resolve an issue. This helps with capacity planning and workload distribution across the team.
|
||||
|
||||
### 2.1. `aspect: code`
|
||||
### 2.1. `points: 1`
|
||||
|
||||
#### 2.1.1. Purpose
|
||||
|
||||
Identifies issues requiring changes to the project's codebase.
|
||||
Identifies very simple issues that require minimal effort and complexity.
|
||||
|
||||
#### 2.1.2. Characteristics
|
||||
|
||||
Involves direct modification to the project's source code. Familiarity with the languages and libraries used is expected.
|
||||
Straightforward tasks that can typically be completed quickly. Examples include minor text corrections, simple configuration changes, or very small bug fixes.
|
||||
|
||||
#### 2.1.3. Expectations
|
||||
|
||||
Contributors must ensure their code changes comply with the project's coding standards, license terms, and any applicable software patents or copyrights.
|
||||
Team members should be able to complete these issues with minimal review time. These are ideal for quick wins and maintaining project momentum.
|
||||
|
||||
### 2.2. `aspect: dx`
|
||||
### 2.2. `points: 2`
|
||||
|
||||
#### 2.2.1. Purpose
|
||||
|
||||
Indicates issues related to improving the project's tooling and development workflow.
|
||||
Designates simple issues that require a bit more thought or investigation.
|
||||
|
||||
#### 2.2.2. Characteristics
|
||||
|
||||
May include changes to automated tests, development dependencies, build processes, etc. Understanding of the development workflows is expected.
|
||||
Slightly more complex than 1-point issues but still relatively straightforward. May involve understanding a small portion of the codebase or making changes across a few files.
|
||||
|
||||
#### 2.2.3. Expectations
|
||||
|
||||
Changes to tooling or dependencies must be compatible with the project's overall licensing strategy and not introduce conflicts with existing terms.
|
||||
These issues should be approachable for most team members and can serve as good learning opportunities.
|
||||
|
||||
### 2.3. `aspect: interface`
|
||||
### 2.3. `points: 3`
|
||||
|
||||
#### 2.3.1. Purpose
|
||||
|
||||
Designates issues that affect the end-user's experience with the project.
|
||||
Indicates moderate complexity issues that require more substantial work.
|
||||
|
||||
#### 2.3.2. Characteristics
|
||||
|
||||
May require changes in the code, particularly in front-end components. Can include visual modifications like CSS changes or image updates. Understanding of the end-user experience expected.
|
||||
Requires understanding multiple parts of the codebase or implementing features with several components. May involve testing, documentation, and coordination with other parts of the system.
|
||||
|
||||
#### 2.3.3. Expectations
|
||||
|
||||
Contributors must ensure they have the necessary rights to any visual assets introduced or modified. Changes should comply with accessibility standards and regulations where applicable.
|
||||
Team members should have some familiarity with the codebase before tackling these issues. May require more thorough review and testing.
|
||||
|
||||
### 2.4. `aspect: text`
|
||||
### 2.4. `points: 5`
|
||||
|
||||
#### 2.4.1. Purpose
|
||||
|
||||
Identifies issues related to the project's documentation.
|
||||
Identifies complex issues that require significant effort and expertise.
|
||||
|
||||
#### 2.4.2. Characteristics
|
||||
|
||||
Typically does not require code changes. Proficiency in technical writing is a must.
|
||||
Involves substantial changes to the codebase, multiple components, or deep understanding of system architecture. May require refactoring, architectural decisions, or integration with external systems.
|
||||
|
||||
#### 2.4.3. Expectations
|
||||
|
||||
Contributors must ensure the accuracy of the information provided in documentation updates. Documentation changes should adhere to any applicable style guides and licensing terms.
|
||||
These issues typically require experienced team members and may involve multiple review cycles. Proper planning and discussion may be necessary before implementation.
|
||||
|
||||
### 2.5. Disclaimer
|
||||
### 2.5. `points: 8`
|
||||
|
||||
Aspect labels are assigned based on the primary focus of the issue but may not encompass all potential areas of impact. Contributors are encouraged to consider potential cross-aspect effects of their work and discuss these with project maintainers when in doubt. The project maintainers reserve the right to reassign aspect labels or request additional changes if the submitted work does not align with the intended scope of the issue.
|
||||
#### 2.5.1. Purpose
|
||||
|
||||
## 3. Goal Labels
|
||||
Designates very complex issues that require extensive work and deep expertise.
|
||||
|
||||
These labels indicate the primary objective of the issue, reflecting our project's modular approach. They help contributors understand the nature and scope of the changes they'll be making.
|
||||
#### 2.5.2. Characteristics
|
||||
|
||||
### 3.1. `goal: addition`
|
||||
Major features, significant refactoring, or complex architectural changes. Often involves multiple team members or requires breaking down into smaller sub-tasks.
|
||||
|
||||
#### 2.5.3. Expectations
|
||||
|
||||
These issues should be carefully planned and may need to be broken down into smaller, manageable pieces. Typically assigned to experienced team members with relevant expertise.
|
||||
|
||||
### 2.6. `points: 13`
|
||||
|
||||
#### 2.6.1. Purpose
|
||||
|
||||
Indicates extremely complex issues that represent major undertakings.
|
||||
|
||||
#### 2.6.2. Characteristics
|
||||
|
||||
Epic-level work that significantly impacts the project. Often requires breaking down into multiple smaller issues or involves substantial architectural changes.
|
||||
|
||||
#### 2.6.3. Expectations
|
||||
|
||||
These issues should always be broken down into smaller, trackable pieces. Requires careful planning, coordination, and likely involvement from multiple team members or executive leadership.
|
||||
|
||||
### 2.7. Disclaimer
|
||||
|
||||
Points are assigned based on the project maintainers' assessment of complexity and effort required. Actual time and effort may vary based on individual team member experience, unexpected complications, or changing requirements. Points should be used as a guide for planning and capacity management, not as strict time estimates.
|
||||
|
||||
## 3. Time Labels
|
||||
|
||||
Time labels indicate the expected number of days a developer should allocate for working on an issue. These help with sprint planning and workload management.
|
||||
|
||||
### 3.1. `time: <1 day`
|
||||
|
||||
#### 3.1.1. Purpose
|
||||
|
||||
Identifies issues that involve adding a new feature to the project.
|
||||
Identifies issues that can be completed in less than one day of focused work.
|
||||
|
||||
#### 3.1.2. Characteristics
|
||||
|
||||
Typically involves creating new code files. Understanding of how different modules in the project integrate with each other is expected.
|
||||
Quick fixes, minor updates, or simple tasks that don't require extensive development time. Typically aligns with 1-2 point issues.
|
||||
|
||||
#### 3.1.3. Expectations
|
||||
|
||||
Contributors must ensure that new features do not infringe on existing patents or copyrights. New code should be compatible with the project's existing license. If introducing third-party libraries or dependencies, their licenses must be compatible with the project's license.
|
||||
These issues should be completable within a single work session. Ideal for maintaining project momentum and addressing quick wins.
|
||||
|
||||
### 3.2. `goal: fix`
|
||||
### 3.2. `time: 1 day`
|
||||
|
||||
#### 3.2.1. Purpose
|
||||
|
||||
Designates issues aimed at fixing bugs in the project.
|
||||
Designates issues that require approximately one full day of development work.
|
||||
|
||||
#### 3.2.2. Characteristics
|
||||
|
||||
Typically involves editing code within existing files. Scope should be kept to the specific bug - separate contributions should be made for unrelated bugs.
|
||||
Moderate tasks that can be completed in a focused day of work. May include some investigation, implementation, and basic testing.
|
||||
|
||||
#### 3.2.3. Expectations
|
||||
|
||||
Bug fixes should not introduce new legal issues or licensing conflicts. Contributors should document the nature of the bug and the fix for future reference and potential legal compliance (e.g., security vulnerabilities).
|
||||
Team members should be able to complete these issues within a single day, accounting for review time and potential minor revisions.
|
||||
|
||||
### 3.3. `goal: improvement`
|
||||
### 3.3. `time: 2-3 days`
|
||||
|
||||
#### 3.3.1. Purpose
|
||||
|
||||
Indicates issues that expand upon or enhance existing features.
|
||||
Indicates issues requiring two to three days of development effort.
|
||||
|
||||
#### 3.3.2. Characteristics
|
||||
|
||||
Usually involves adding code to existing files. Scope should be kept to the existing feature.
|
||||
More substantial work that involves multiple components, thorough testing, or deeper investigation. May require coordination with other team members.
|
||||
|
||||
#### 3.3.3. Expectations
|
||||
|
||||
Improvements should maintain compatibility with existing licenses and legal obligations. If the improvement significantly changes the functionality, consider if additional legal reviews or updates to user agreements are necessary.
|
||||
These issues should be planned across multiple days, allowing time for implementation, testing, review cycles, and potential revisions.
|
||||
|
||||
### 3.4. Disclaimer
|
||||
### 3.4. `time: 4-5 days`
|
||||
|
||||
While goal labels provide guidance on the nature of the task, the actual work required may vary or expand beyond the initial scope. Contributors are encouraged to communicate with project maintainers if they believe a different approach or additional changes are necessary to achieve the goal. The project maintainers reserve the right to request modifications or additional work to ensure that contributions align with the project's goals, standards, and legal requirements.
|
||||
#### 3.4.1. Purpose
|
||||
|
||||
## 4. Priority Labels
|
||||
Identifies issues that require approximately one week of development work.
|
||||
|
||||
Priority labels indicate the importance assigned to specific issues by the project maintainers. These labels help guide resource allocation and set expectations for resolution timeframes.
|
||||
#### 3.4.2. Characteristics
|
||||
|
||||
### 4.1. `priority: critical`
|
||||
Complex features or significant changes that require careful implementation, extensive testing, and multiple review cycles.
|
||||
|
||||
#### 3.4.3. Expectations
|
||||
|
||||
These issues should be allocated sufficient time for thorough development and review. May benefit from breaking down into smaller sub-tasks for better tracking.
|
||||
|
||||
### 3.5. `time: 1-2 weeks`
|
||||
|
||||
#### 3.5.1. Purpose
|
||||
|
||||
Designates issues requiring one to two weeks of focused development effort.
|
||||
|
||||
#### 3.5.2. Characteristics
|
||||
|
||||
Major features or substantial refactoring that requires careful planning, implementation across multiple areas, and comprehensive testing.
|
||||
|
||||
#### 3.5.3. Expectations
|
||||
|
||||
These issues should be carefully planned and may need to be broken down into smaller, trackable milestones. Requires coordination and regular check-ins with the team.
|
||||
|
||||
### 3.6. `time: >2 weeks`
|
||||
|
||||
#### 3.6.1. Purpose
|
||||
|
||||
Indicates issues that require more than two weeks of development work.
|
||||
|
||||
#### 3.6.2. Characteristics
|
||||
|
||||
Epic-level work or major architectural changes that significantly impact the project. Often involves multiple team members and extensive planning.
|
||||
|
||||
#### 3.6.3. Expectations
|
||||
|
||||
These issues must be broken down into smaller, manageable pieces. Require careful project management, regular milestones, and coordination across the team.
|
||||
|
||||
### 3.7. Disclaimer
|
||||
|
||||
Time estimates are based on typical development scenarios and may vary based on individual team member experience, unexpected complications, review cycles, or changing requirements. Time labels should be used as a guide for planning and should be adjusted based on actual progress and circumstances.
|
||||
|
||||
## 4. Aspect Labels
|
||||
|
||||
These labels indicate the scope of the work required to resolve the issue.
|
||||
|
||||
### 4.1. `aspect: code`
|
||||
|
||||
#### 4.1.1. Purpose
|
||||
|
||||
Identifies issues requiring immediate attention due to their severe impact on project usability.
|
||||
Identifies issues requiring changes to the project's codebase.
|
||||
|
||||
#### 4.1.2. Characteristics
|
||||
|
||||
Require urgent resolution to restore project functionality. Experience with the project is a must, to avoid delays from long review processes.
|
||||
Involves direct modification to the project's source code. Familiarity with the languages and libraries used is expected.
|
||||
|
||||
#### 4.1.3. Expectations
|
||||
|
||||
May involve security vulnerabilities or critical bugs that could lead to legal liabilities if not addressed promptly. Resolution of these issues may need to be reported to relevant stakeholders or authorities in certain cases (e.g., data protection regulators for security breaches).
|
||||
Contributors must ensure their code changes comply with the project's coding standards, license terms, and any applicable software patents or copyrights.
|
||||
|
||||
### 4.2. `priority: high`
|
||||
### 4.2. `aspect: dx`
|
||||
|
||||
#### 4.2.1. Purpose
|
||||
|
||||
Designates important issues that, while not preventing basic functionality, are impeding further development.
|
||||
Indicates issues related to improving the project's tooling and development workflow.
|
||||
|
||||
#### 4.2.2. Characteristics
|
||||
|
||||
Not critical for current project operation but blocking future progress. Require prompt attention to unblock development efforts.
|
||||
May include changes to automated tests, development dependencies, build processes, etc. Understanding of the development workflows is expected.
|
||||
|
||||
#### 4.2.3. Expectations
|
||||
|
||||
May involve compliance deadlines or contractual obligations that need to be met. Could impact project timelines, potentially affecting agreements with stakeholders or clients.
|
||||
Changes to tooling or dependencies must be compatible with the project's overall licensing strategy and not introduce conflicts with existing terms.
|
||||
|
||||
### 4.3. `priority: medium`
|
||||
### 4.3. `aspect: interface`
|
||||
|
||||
#### 4.3.1. Purpose
|
||||
|
||||
Indicates issues that need resolution as soon as possible but are not blocking other development.
|
||||
Designates issues that affect the end-user's experience with the project.
|
||||
|
||||
#### 4.3.2. Characteristics
|
||||
|
||||
Important for project improvement but not critical for current functionality. Should be addressed in a timely manner but with less urgency than high-priority issues.
|
||||
May require changes in the code, particularly in front-end components. Can include visual modifications like CSS changes or image updates. Understanding of the end-user experience expected.
|
||||
|
||||
#### 4.3.3. Expectations
|
||||
|
||||
May involve improvements to user experience or accessibility, which could have legal implications if neglected long-term. Could relate to optimisations that affect performance guarantees or service level agreements.
|
||||
Contributors must ensure they have the necessary rights to any visual assets introduced or modified. Changes should comply with accessibility standards and regulations where applicable.
|
||||
|
||||
### 4.4. `priority: low`
|
||||
### 4.4. `aspect: text`
|
||||
|
||||
#### 4.4.1. Purpose
|
||||
|
||||
Represents issues that should be resolved but are not considered urgent.
|
||||
Identifies issues related to the project's documentation.
|
||||
|
||||
#### 4.4.2. Characteristics
|
||||
|
||||
Desirable improvements or minor issues that don't significantly impact project functionality.
|
||||
Typically does not require code changes. Proficiency in technical writing is a must.
|
||||
|
||||
#### 4.4.3. Expectations
|
||||
|
||||
While not urgent, neglecting these issues over time could lead to technical debt or gradual degradation of project quality, potentially affecting long-term compliance or user satisfaction.
|
||||
Contributors must ensure the accuracy of the information provided in documentation updates. Documentation changes should adhere to any applicable style guides and licensing terms.
|
||||
|
||||
### 4.5. `priority: none`
|
||||
### 4.5. Disclaimer
|
||||
|
||||
#### 4.5.1. Purpose
|
||||
Aspect labels are assigned based on the primary focus of the issue but may not encompass all potential areas of impact. Contributors are encouraged to consider potential cross-aspect effects of their work and discuss these with project maintainers when in doubt. The project maintainers reserve the right to reassign aspect labels or request additional changes if the submitted work does not align with the intended scope of the issue.
|
||||
|
||||
Identifies "nice-to-have" issues that are not essential for project functionality or immediate development goals.
|
||||
## 5. Goal Labels
|
||||
|
||||
#### 4.5.2. Characteristics
|
||||
These labels indicate the primary objective of the issue, reflecting our project's modular approach. They help contributors understand the nature and scope of the changes they'll be making.
|
||||
|
||||
Not critical enough to dedicate maintainer time for resolution. Often left for community contributors or future consideration.
|
||||
|
||||
#### 4.5.3. Expectations
|
||||
|
||||
While not prioritised, maintainers should periodically review these issues to ensure they haven't become more significant over time, potentially accruing legal or compliance risks.
|
||||
|
||||
### 4.6. Disclaimer
|
||||
|
||||
Priority labels reflect the project maintainers' current assessment and may be subject to change. The presence of a lower-priority label does not diminish the importance of the issue or the value of contributions addressing it. Contributors should communicate with maintainers if they believe an issue's priority should be reassessed due to new information or changing circumstances.
|
||||
|
||||
## 5. Status Labels
|
||||
|
||||
Status labels indicate the current stage of an issue in the project lifecycle. These labels help manage workflow and set expectations for contributors and users.
|
||||
|
||||
### 5.1. `status: awaiting triage`
|
||||
### 5.1. `goal: addition`
|
||||
|
||||
#### 5.1.1. Purpose
|
||||
|
||||
Identifies newly created issues that have not yet been reviewed by the maintainer team.
|
||||
Identifies issues that involve adding a new feature to the project.
|
||||
|
||||
#### 5.1.2. Characteristics
|
||||
|
||||
Should be applied to issues when they are opened.
|
||||
Typically involves creating new code files. Understanding of how different modules in the project integrate with each other is expected.
|
||||
|
||||
#### 5.1.3. Expectations
|
||||
|
||||
Contributors should be aware that engaging with these issues is at their own discretion, as the project team has not yet evaluated them. Maintainers should establish a reasonable timeframe for initial triage to manage expectations and potential liability.
|
||||
Contributors must ensure that new features do not infringe on existing patents or copyrights. New code should be compatible with the project's existing license. If introducing third-party libraries or dependencies, their licenses must be compatible with the project's license.
|
||||
|
||||
### 5.2. `status: blocked`
|
||||
### 5.2. `goal: fix`
|
||||
|
||||
#### 5.2.1. Purpose
|
||||
|
||||
Indicates issues with a planned resolution that depend on the completion of another issue.
|
||||
Designates issues aimed at fixing bugs in the project.
|
||||
|
||||
#### 5.2.2. Characteristics
|
||||
|
||||
Not yet ready for work but expected to be addressed in the future.
|
||||
Typically involves editing code within existing files. Scope should be kept to the specific bug - separate contributions should be made for unrelated bugs.
|
||||
|
||||
#### 5.2.3. Expectations
|
||||
|
||||
Maintainers should clearly document dependencies to avoid potential conflicts or misunderstandings. Regular review of blocked issues is advisable to prevent indefinite delays that could impact project timelines or contractual obligations.
|
||||
Bug fixes should not introduce new legal issues or licensing conflicts. Contributors should document the nature of the bug and the fix for future reference and potential legal compliance (e.g., security vulnerabilities).
|
||||
|
||||
### 5.3. `status: discarded`
|
||||
### 5.3. `goal: improvement`
|
||||
|
||||
#### 5.3.1. Purpose
|
||||
|
||||
Designates issues that the project team does not intend to resolve.
|
||||
Indicates issues that expand upon or enhance existing features.
|
||||
|
||||
#### 5.3.2. Characteristics
|
||||
|
||||
Typically applied to feature requests that don't align with project goals.
|
||||
Usually involves adding code to existing files. Scope should be kept to the existing feature.
|
||||
|
||||
#### 5.3.3. Expectations
|
||||
|
||||
Clearly communicate the rationale for discarding issues to manage user expectations and maintain transparency. Ensure that discarded issues don't conflict with any promised features or contractual obligations.
|
||||
Improvements should maintain compatibility with existing licenses and legal obligations. If the improvement significantly changes the functionality, consider if additional legal reviews or updates to user agreements are necessary.
|
||||
|
||||
### 5.4. `status: discontinued`
|
||||
### 5.4. Disclaimer
|
||||
|
||||
#### 5.4.1. Purpose
|
||||
While goal labels provide guidance on the nature of the task, the actual work required may vary or expand beyond the initial scope. Contributors are encouraged to communicate with project maintainers if they believe a different approach or additional changes are necessary to achieve the goal. The project maintainers reserve the right to request modifications or additional work to ensure that contributions align with the project's goals, standards, and legal requirements.
|
||||
|
||||
Applies to feature requests for projects in maintenance mode.
|
||||
## 6. Priority Labels
|
||||
|
||||
#### 5.4.2. Characteristics
|
||||
Priority labels indicate the importance assigned to specific issues by the project maintainers. These labels help guide resource allocation and set expectations for resolution timeframes.
|
||||
|
||||
Indicates no new features will be added, but bug fixes and support continue.
|
||||
|
||||
#### 5.4.3. Expectations
|
||||
|
||||
Clearly communicate the project's maintenance status to manage user expectations and potential liability. Ensure that discontinuation doesn't breach any ongoing support agreements or licenses.
|
||||
|
||||
### 5.5. `status: label work required`
|
||||
|
||||
#### 5.5.1. Purpose
|
||||
|
||||
Indicates issues that need proper labelling and categorisation.
|
||||
|
||||
#### 5.5.2. Characteristics
|
||||
|
||||
May have ongoing discussions but lack appropriate classification.
|
||||
|
||||
#### 5.5.3. Expectations
|
||||
|
||||
Proper labelling is crucial for efficient project management and may have implications for compliance tracking and reporting. Establish clear guidelines for labelling to ensure consistency and avoid potential misunderstandings.
|
||||
|
||||
### 5.6. `status: ready for dev`
|
||||
|
||||
#### 5.6.1. Purpose
|
||||
|
||||
Signifies issues that are ready for contribution.
|
||||
|
||||
#### 5.6.2. Characteristics
|
||||
|
||||
May have an assigned contributor who has expressed interest.
|
||||
|
||||
#### 5.6.3. Expectations
|
||||
|
||||
Clearly communicate contribution guidelines and any legal requirements (e.g., Contributor Covenant) to potential contributors. Ensure that collaborative efforts are managed in compliance with project licenses and contributor agreements.
|
||||
|
||||
### 5.7. `status: ticket work required`
|
||||
|
||||
#### 5.7.1. Purpose
|
||||
|
||||
Indicates issues lacking sufficient information for proper triage.
|
||||
|
||||
#### 5.7.2. Characteristics
|
||||
|
||||
Often paired with Conversation Labels for further clarification.
|
||||
|
||||
#### 5.7.3. Expectations
|
||||
|
||||
Establish clear guidelines for required information to avoid potential misunderstandings or misdirected efforts. Be mindful of data privacy when requesting additional information from issue reporters.
|
||||
|
||||
### 5.8. Disclaimer
|
||||
|
||||
Status labels reflect the current assessment of the project team and may change as circumstances evolve. While the project team strives to maintain accurate status labels, contributors and users should communicate with maintainers if they notice any discrepancies or have questions about an issue's status.
|
||||
|
||||
## 6. Conversation Labels
|
||||
|
||||
Conversation labels indicate that an issue has received initial maintainer attention but requires further discussion or information before proceeding. These labels help manage communication and ensure all necessary information is gathered before taking action.
|
||||
|
||||
### 6.1. `talk: discussion`
|
||||
### 6.1. `priority: critical`
|
||||
|
||||
#### 6.1.1. Purpose
|
||||
|
||||
Identifies issues that are under active discussion but have not yet been accepted for resolution.
|
||||
Identifies issues requiring immediate attention due to their severe impact on project usability.
|
||||
|
||||
#### 6.1.2. Characteristics
|
||||
|
||||
Ongoing dialogue between maintainers, contributors, and/or users. May involve debates about feature requests, implementation strategies, or project direction.
|
||||
Require urgent resolution to restore project functionality. Experience with the project is a must, to avoid delays from long review processes.
|
||||
|
||||
#### 6.1.3. Expectations
|
||||
|
||||
Ensure discussions remain constructive and adhere to the project's code of conduct. Be cautious about making commitments or promises during discussions that could create legal obligations. Document key decisions and rationales to maintain transparency and provide a record for future reference.
|
||||
May involve security vulnerabilities or critical bugs that could lead to legal liabilities if not addressed promptly. Resolution of these issues may need to be reported to relevant stakeholders or authorities in certain cases (e.g., data protection regulators for security breaches).
|
||||
|
||||
### 6.2. `talk: question`
|
||||
### 6.2. `priority: high`
|
||||
|
||||
#### 6.2.1. Purpose
|
||||
|
||||
Indicates issues waiting on additional information from the author for proper triage.
|
||||
Designates important issues that, while not preventing basic functionality, are impeding further development.
|
||||
|
||||
#### 6.2.2. Characteristics
|
||||
|
||||
Requires clarification or more details from the issue creator. Cannot proceed with triage or resolution until the requested information is provided.
|
||||
Not critical for current project operation but blocking future progress. Require prompt attention to unblock development efforts.
|
||||
|
||||
#### 6.2.3. Expectations
|
||||
|
||||
Clearly communicate what information is needed and why it's necessary. Be mindful of data privacy when requesting additional information. Establish and communicate timeframes for expected responses to manage the issue lifecycle efficiently.
|
||||
May involve compliance deadlines or contractual obligations that need to be met. Could impact project timelines, potentially affecting agreements with stakeholders or clients.
|
||||
|
||||
### 6.3. Disclaimer
|
||||
### 6.3. `priority: medium`
|
||||
|
||||
Conversation labels indicate ongoing dialogue and do not guarantee that an issue will be implemented or resolved in a specific manner. Participants should understand that project priorities and decisions may change based on new information or project direction.
|
||||
#### 6.3.1. Purpose
|
||||
|
||||
## 7. Pull Request Labels
|
||||
Indicates issues that need resolution as soon as possible but are not blocking other development.
|
||||
|
||||
Pull Request (PR) labels are used to indicate the current status of pull requests and guide contributors through the review and merge process.
|
||||
#### 6.3.2. Characteristics
|
||||
|
||||
### 7.1. `pull: merge conflict`
|
||||
Important for project improvement but not critical for current functionality. Should be addressed in a timely manner but with less urgency than high-priority issues.
|
||||
|
||||
#### 6.3.3. Expectations
|
||||
|
||||
May involve improvements to user experience or accessibility, which could have legal implications if neglected long-term. Could relate to optimisations that affect performance guarantees or service level agreements.
|
||||
|
||||
### 6.4. `priority: low`
|
||||
|
||||
#### 6.4.1. Purpose
|
||||
|
||||
Represents issues that should be resolved but are not considered urgent.
|
||||
|
||||
#### 6.4.2. Characteristics
|
||||
|
||||
Desirable improvements or minor issues that don't significantly impact project functionality.
|
||||
|
||||
#### 6.4.3. Expectations
|
||||
|
||||
While not urgent, neglecting these issues over time could lead to technical debt or gradual degradation of project quality, potentially affecting long-term compliance or user satisfaction.
|
||||
|
||||
### 6.5. `priority: none`
|
||||
|
||||
#### 6.5.1. Purpose
|
||||
|
||||
Identifies "nice-to-have" issues that are not essential for project functionality or immediate development goals.
|
||||
|
||||
#### 6.5.2. Characteristics
|
||||
|
||||
Not critical enough to dedicate maintainer time for resolution. Often left for future consideration or when team capacity allows.
|
||||
|
||||
#### 6.5.3. Expectations
|
||||
|
||||
While not prioritised, maintainers should periodically review these issues to ensure they haven't become more significant over time, potentially accruing legal or compliance risks.
|
||||
|
||||
### 6.6. Disclaimer
|
||||
|
||||
Priority labels reflect the project maintainers' current assessment and may be subject to change. The presence of a lower-priority label does not diminish the importance of the issue or the value of contributions addressing it. Contributors should communicate with maintainers if they believe an issue's priority should be reassessed due to new information or changing circumstances.
|
||||
|
||||
## 7. Status Labels
|
||||
|
||||
Status labels indicate the current stage of an issue in the project lifecycle. These labels help manage workflow and set expectations for contributors and users.
|
||||
|
||||
### 7.1. `status: awaiting triage`
|
||||
|
||||
#### 7.1.1. Purpose
|
||||
|
||||
Indicates that the pull request has conflicts with the target branch.
|
||||
Identifies newly created issues that have not yet been reviewed by the maintainer team.
|
||||
|
||||
#### 7.1.2. Characteristics
|
||||
|
||||
Conflicts need to be resolved before the PR can be reviewed or merged. May require action from the original contributor or project maintainers.
|
||||
Should be applied to issues when they are opened.
|
||||
|
||||
#### 7.1.3. Expectations
|
||||
|
||||
Clearly communicate the responsibility for resolving conflicts (e.g., whether it's the contributor's or maintainer's role). Ensure that conflict resolution doesn't introduce unintended changes or legal issues (e.g., license conflicts).
|
||||
Contributors should be aware that engaging with these issues is at their own discretion, as the project team has not yet evaluated them. Maintainers should establish a reasonable timeframe for initial triage to manage expectations and potential liability.
|
||||
|
||||
### 7.2. `pull: ready for review`
|
||||
### 7.2. `status: blocked`
|
||||
|
||||
#### 7.2.1. Purpose
|
||||
|
||||
Signifies that the pull request is not in draft mode and is awaiting maintainer review.
|
||||
Indicates issues with a planned resolution that depend on the completion of another issue.
|
||||
|
||||
#### 7.2.2. Characteristics
|
||||
|
||||
PR has been submitted as complete and ready for evaluation. Maintainers should prioritise reviewing these PRs.
|
||||
Not yet ready for work but expected to be addressed in the future.
|
||||
|
||||
#### 7.2.3. Expectations
|
||||
|
||||
Ensure contributors understand that "ready for review" doesn't guarantee acceptance or merging. Maintain clear review criteria and communicate them to contributors.
|
||||
Maintainers should clearly document dependencies to avoid potential conflicts or misunderstandings. Regular review of blocked issues is advisable to prevent indefinite delays that could impact project timelines or contractual obligations.
|
||||
|
||||
### 7.3. `pull: requires update`
|
||||
### 7.3. `status: discarded`
|
||||
|
||||
#### 7.3.1. Purpose
|
||||
|
||||
Indicates that the maintainer team has requested changes to the pull request.
|
||||
Designates issues that the project team does not intend to resolve.
|
||||
|
||||
#### 7.3.2. Characteristics
|
||||
|
||||
Feedback has been provided, and updates are needed before further review or merging. Requires action from the contributor to address the requested changes.
|
||||
Typically applied to feature requests that don't align with project goals.
|
||||
|
||||
#### 7.3.3. Expectations
|
||||
|
||||
Clearly communicate the rationale for discarding issues to manage user expectations and maintain transparency. Ensure that discarded issues don't conflict with any promised features or contractual obligations.
|
||||
|
||||
### 7.4. `status: discontinued`
|
||||
|
||||
#### 7.4.1. Purpose
|
||||
|
||||
Applies to feature requests for projects in maintenance mode.
|
||||
|
||||
#### 7.4.2. Characteristics
|
||||
|
||||
Indicates no new features will be added, but bug fixes and support continue.
|
||||
|
||||
#### 7.4.3. Expectations
|
||||
|
||||
Clearly communicate the project's maintenance status to manage user expectations and potential liability. Ensure that discontinuation doesn't breach any ongoing support agreements or licenses.
|
||||
|
||||
### 7.5. `status: label work required`
|
||||
|
||||
#### 7.5.1. Purpose
|
||||
|
||||
Indicates issues that need proper labelling and categorisation.
|
||||
|
||||
#### 7.5.2. Characteristics
|
||||
|
||||
May have ongoing discussions but lack appropriate classification.
|
||||
|
||||
#### 7.5.3. Expectations
|
||||
|
||||
Proper labelling is crucial for efficient project management and may have implications for compliance tracking and reporting. Establish clear guidelines for labelling to ensure consistency and avoid potential misunderstandings.
|
||||
|
||||
### 7.6. `status: ready for dev`
|
||||
|
||||
#### 7.6.1. Purpose
|
||||
|
||||
Signifies issues that are ready for contribution.
|
||||
|
||||
#### 7.6.2. Characteristics
|
||||
|
||||
May have an assigned contributor who has expressed interest.
|
||||
|
||||
#### 7.6.3. Expectations
|
||||
|
||||
Clearly communicate contribution guidelines and any legal requirements (e.g., Contributor Covenant) to potential contributors. Ensure that collaborative efforts are managed in compliance with project licenses and contributor agreements.
|
||||
|
||||
### 7.7. `status: ticket work required`
|
||||
|
||||
#### 7.7.1. Purpose
|
||||
|
||||
Indicates issues lacking sufficient information for proper triage.
|
||||
|
||||
#### 7.7.2. Characteristics
|
||||
|
||||
Often paired with Conversation Labels for further clarification.
|
||||
|
||||
#### 7.7.3. Expectations
|
||||
|
||||
Establish clear guidelines for required information to avoid potential misunderstandings or misdirected efforts. Be mindful of data privacy when requesting additional information from issue reporters.
|
||||
|
||||
### 7.8. Disclaimer
|
||||
|
||||
Status labels reflect the current assessment of the project team and may change as circumstances evolve. While the project team strives to maintain accurate status labels, contributors and users should communicate with maintainers if they notice any discrepancies or have questions about an issue's status.
|
||||
|
||||
## 8. Conversation Labels
|
||||
|
||||
Conversation labels indicate that an issue has received initial maintainer attention but requires further discussion or information before proceeding. These labels help manage communication and ensure all necessary information is gathered before taking action.
|
||||
|
||||
### 8.1. `talk: discussion`
|
||||
|
||||
#### 8.1.1. Purpose
|
||||
|
||||
Identifies issues that are under active discussion but have not yet been accepted for resolution.
|
||||
|
||||
#### 8.1.2. Characteristics
|
||||
|
||||
Ongoing dialogue between maintainers, contributors, and/or users. May involve debates about feature requests, implementation strategies, or project direction.
|
||||
|
||||
#### 8.1.3. Expectations
|
||||
|
||||
Ensure discussions remain constructive and adhere to the project's code of conduct. Be cautious about making commitments or promises during discussions that could create legal obligations. Document key decisions and rationales to maintain transparency and provide a record for future reference.
|
||||
|
||||
### 8.2. `talk: question`
|
||||
|
||||
#### 8.2.1. Purpose
|
||||
|
||||
Indicates issues waiting on additional information from the author for proper triage.
|
||||
|
||||
#### 8.2.2. Characteristics
|
||||
|
||||
Requires clarification or more details from the issue creator. Cannot proceed with triage or resolution until the requested information is provided.
|
||||
|
||||
#### 8.2.3. Expectations
|
||||
|
||||
Clearly communicate what information is needed and why it's necessary. Be mindful of data privacy when requesting additional information. Establish and communicate timeframes for expected responses to manage the issue lifecycle efficiently.
|
||||
|
||||
### 8.3. Disclaimer
|
||||
|
||||
Conversation labels indicate ongoing dialogue and do not guarantee that an issue will be implemented or resolved in a specific manner. Participants should understand that project priorities and decisions may change based on new information or project direction.
|
||||
|
||||
## 9. Pull Request Labels
|
||||
|
||||
Pull Request (PR) labels are used to indicate the current status of pull requests and guide contributors through the review and merge process.
|
||||
|
||||
### 9.1. `pull: merge conflict`
|
||||
|
||||
#### 9.1.1. Purpose
|
||||
|
||||
Indicates that the pull request has conflicts with the target branch.
|
||||
|
||||
#### 9.1.2. Characteristics
|
||||
|
||||
Conflicts need to be resolved before the PR can be reviewed or merged. May require action from the original contributor or project maintainers.
|
||||
|
||||
#### 9.1.3. Expectations
|
||||
|
||||
Clearly communicate the responsibility for resolving conflicts (e.g., whether it's the contributor's or maintainer's role). Ensure that conflict resolution doesn't introduce unintended changes or legal issues (e.g., license conflicts).
|
||||
|
||||
### 9.2. `pull: ready for review`
|
||||
|
||||
#### 9.2.1. Purpose
|
||||
|
||||
Signifies that the pull request is not in draft mode and is awaiting maintainer review.
|
||||
|
||||
#### 9.2.2. Characteristics
|
||||
|
||||
PR has been submitted as complete and ready for evaluation. Maintainers should prioritise reviewing these PRs.
|
||||
|
||||
#### 9.2.3. Expectations
|
||||
|
||||
Ensure contributors understand that "ready for review" doesn't guarantee acceptance or merging. Maintain clear review criteria and communicate them to contributors.
|
||||
|
||||
### 9.3. `pull: requires update`
|
||||
|
||||
#### 9.3.1. Purpose
|
||||
|
||||
Indicates that the maintainer team has requested changes to the pull request.
|
||||
|
||||
#### 9.3.2. Characteristics
|
||||
|
||||
Feedback has been provided, and updates are needed before further review or merging. Requires action from the contributor to address the requested changes.
|
||||
|
||||
#### 9.3.3. Expectations
|
||||
|
||||
Clearly document requested changes to maintain transparency and avoid misunderstandings. Consider setting timeframes for updates to manage the PR lifecycle effectively.
|
||||
|
||||
### 7.4. Disclaimer
|
||||
### 9.4. Disclaimer
|
||||
|
||||
The presence of these labels does not guarantee that a pull request will be merged. All contributions must still meet the project's quality standards, guidelines, and legal requirements.
|
||||
|
||||
## 8. Continuous Improvement
|
||||
## 10. Continuous Improvement
|
||||
|
||||
We encourage all project participants to provide feedback on our labelling system. If you have suggestions for improvements or notice any inconsistencies, please reach out to us in our [Discord community](https://chat.nhcarrigan.com).
|
||||
|
||||
## 9. Legal Notice
|
||||
## 11. Legal Notice
|
||||
|
||||
This labels documentation is provided for informational purposes and to facilitate project management. It does not constitute a legal agreement. All contributions to the project must comply with the project's license, contributor agreement (if applicable), and relevant laws and regulations.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user