nhcarrigan/docs
2
0
Fork 0
generated from nhcarrigan/template
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: last wave of tweaks

Browse Source
This commit is contained in:
Naomi Carrigan
2025-01-22 21:19:03 -08:00
parent a7d906e150
commit 7e3a9f64ac
10 changed files with 53 additions and 110 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
src/content/docs/dev/contributing.md
View File

@ -172,7 +172,7 @@ If you encounter any issues during setup:
2. Search for similar issues in the project's issue tracker.
3. If the problem persists, open a new issue with detailed information about the problem and steps to reproduce it.
You can also reach out to us in our Discord server: https://chat.nhcarrigan.com
You can also reach out to us on our forum: https://forum.nhcarrigan.com
## 4. Claiming an Issue
@ -357,7 +357,7 @@ Before submitting a pull request:
1. Ensure all tests pass.
1. Review your changes and commit history.
If you're unsure about any part of the process or need help, don't hesitate to ask in our [chat server](https://chat.nhcarrigan.com). Our community is here to support you!
If you're unsure about any part of the process or need help, don't hesitate to ask in our [forum](https://forum.nhcarrigan.com). Our community is here to support you!
## 6. Submitting a Pull Request

57
src/content/docs/dev/labels.md
View File

@ -8,7 +8,7 @@ We use very specific labels to help categorise our issues. This page explains wh
These are the most important. These labels indicate who is encouraged to make a pull request to resolve the issue.
### 1.1. `good first issue`
### 1.1. `contribute: good first issue`
#### 1.1.1. Purpose
@ -22,7 +22,7 @@ Does not require prior knowledge of the codebase. Issues with this label should
Contributors are responsible for ensuring their work complies with the project's licensing terms and contribution guidelines.
### 1.2. `help wanted`
### 1.2. `contribute: help wanted`
#### 1.2.1. Purpose
@ -36,7 +36,7 @@ Typically assumes prior experience with the codebase. As such, issues may not in
Contributors should review and adhere to the project's contribution guidelines and code of conduct before submitting work on these issues.
### 1.3. `🔒 staff only`
### 1.3. `contribute: staff only`
#### 1.3.1. Purpose
@ -58,7 +58,7 @@ Labels are assigned based on the project maintainers' best judgment but may not
These labels indicate the scope of the work required to resolve the issue.
### 2.1. `💻 aspect: code`
### 2.1. `aspect: code`
#### 2.1.1. Purpose
@ -72,7 +72,7 @@ Involves direct modification to the project's source code. Familiarity with the
Contributors must ensure their code changes comply with the project's coding standards, license terms, and any applicable software patents or copyrights.
### 2.2. `🤖 aspect: dx`
### 2.2. `aspect: dx`
#### 2.2.1. Purpose
@ -86,7 +86,7 @@ May include changes to automated tests, development dependencies, build processe
Changes to tooling or dependencies must be compatible with the project's overall licensing strategy and not introduce conflicts with existing terms.
### 2.3. `🕹 aspect: interface`
### 2.3. `aspect: interface`
#### 2.3.1. Purpose
@ -100,7 +100,7 @@ May require changes in the code, particularly in front-end components. Can inclu
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.
### 2.4. `📄 aspect: text`
### 2.4. `aspect: text`
#### 2.4.1. Purpose
@ -122,7 +122,7 @@ Aspect labels are assigned based on the primary focus of the issue but may not e
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.
### 3.1. `⭐ goal: addition`
### 3.1. `goal: addition`
#### 3.1.1. Purpose
@ -136,7 +136,7 @@ Typically involves creating new code files. Understanding of how different modul
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.
### 3.2. `🛠 goal: fix`
### 3.2. `goal: fix`
#### 3.2.1. Purpose
@ -150,7 +150,7 @@ Typically involves editing code within existing files. Scope should be kept to t
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).
### 3.3. `✨ goal: improvement`
### 3.3. `goal: improvement`
#### 3.3.1. Purpose
@ -172,7 +172,7 @@ While goal labels provide guidance on the nature of the task, the actual work re
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.
### 4.1. `🟥 priority: critical`
### 4.1. `priority: critical`
#### 4.1.1. Purpose
@ -186,7 +186,7 @@ Require urgent resolution to restore project functionality. Experience with the
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).
### 4.2. `🟧 priority: high`
### 4.2. `priority: high`
#### 4.2.1. Purpose
@ -200,7 +200,7 @@ Not critical for current project operation but blocking future progress. Require
May involve compliance deadlines or contractual obligations that need to be met. Could impact project timelines, potentially affecting agreements with stakeholders or clients.
### 4.3. `🟨 priority: medium`
### 4.3. `priority: medium`
#### 4.3.1. Purpose
@ -214,7 +214,7 @@ Important for project improvement but not critical for current functionality. Sh
May involve improvements to user experience or accessibility, which could have legal implications if neglected long-term. Could relate to optimizations that affect performance guarantees or service level agreements.
### 4.4. `🟩 priority: low`
### 4.4. `priority: low`
#### 4.4.1. Purpose
@ -228,7 +228,7 @@ Desirable improvements or minor issues that don't significantly impact project f
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.
### 4.5. `🟪 priority: none`
### 4.5. `priority: none`
#### 4.5.1. Purpose
@ -250,7 +250,7 @@ Priority labels reflect the project maintainers' current assessment and may be s
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. `status: awaiting triage`
#### 5.1.1. Purpose
@ -264,7 +264,7 @@ Should be applied to issues when they are opened.
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.
### 5.2. `🚧 status: blocked`
### 5.2. `status: blocked`
#### 5.2.1. Purpose
@ -273,11 +273,12 @@ Indicates issues with a planned resolution that depend on the completion of anot
#### 5.2.2. Characteristics
Not yet ready for work but expected to be addressed in the future.
#### 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.
### 5.3. `⛔️ status: discarded`
### 5.3. `status: discarded`
#### 5.3.1. Purpose
@ -291,7 +292,7 @@ Typically applied to feature requests that don't align with project goals.
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.
### 5.4. `🙅 status: discontinued`
### 5.4. `status: discontinued`
#### 5.4.1. Purpose
@ -305,7 +306,7 @@ Indicates no new features will be added, but bug fixes and support continue.
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. `status: label work required`
#### 5.5.1. Purpose
@ -319,7 +320,7 @@ May have ongoing discussions but lack appropriate classification.
Proper labeling is crucial for efficient project management and may have implications for compliance tracking and reporting. Establish clear guidelines for labeling to ensure consistency and avoid potential misunderstandings.
### 5.6. `🏁 status: ready for dev`
### 5.6. `status: ready for dev`
#### 5.6.1. Purpose
@ -333,7 +334,7 @@ May have an assigned contributor who has expressed interest.
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. `status: ticket work required`
#### 5.7.1. Purpose
@ -355,7 +356,7 @@ Status labels reflect the current assessment of the project team and may change
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. `talk: discussion`
#### 6.1.1. Purpose
@ -369,7 +370,7 @@ Ongoing dialogue between maintainers, contributors, and/or users. May involve de
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.
### 6.2. `❓ talk: question`
### 6.2. `talk: question`
#### 6.2.1. Purpose
@ -391,7 +392,7 @@ Conversation labels indicate ongoing dialogue and do not guarantee that an issue
Pull Request (PR) labels are used to indicate the current status of pull requests and guide contributors through the review and merge process.
### 7.1. `⚠️ pull: merge conflict`
### 7.1. `pull: merge conflict`
#### 7.1.1. Purpose
@ -405,7 +406,7 @@ Conflicts need to be resolved before the PR can be reviewed or merged. May requi
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).
### 7.2. `🔍 pull: ready for review`
### 7.2. `pull: ready for review`
#### 7.2.1. Purpose
@ -419,7 +420,7 @@ PR has been submitted as complete and ready for evaluation. Maintainers should p
Ensure contributors understand that "ready for review" doesn't guarantee acceptance or merging. Maintain clear review criteria and communicate them to contributors.
### 7.3. `⏫ pull: requires update`
### 7.3. `pull: requires update`
#### 7.3.1. Purpose
@ -439,7 +440,7 @@ The presence of these labels does not guarantee that a pull request will be merg
## 8. Continuous Improvement
We encourage all project participants to provide feedback on our labeling system. If you have suggestions for improvements or notice any inconsistencies, please reach out to us in our [chat server](https://chat.nhcarrigan.com).
We encourage all project participants to provide feedback on our labeling system. If you have suggestions for improvements or notice any inconsistencies, please reach out to us in our [forums](https://forum.nhcarrigan.com).
## 9. Legal Notice