feat: we do even more things (#20)

### Explanation _No response_ ### Issue Closes #18 ### Attestations - [ ] I have read and agree to the [Code of Conduct](https://docs.nhcarrigan.com/community/coc/) - [ ] I have read and agree to the [Community Guidelines](https://docs.nhcarrigan.com/community/guide/). - [ ] My contribution complies with the [Contributor Covenant](https://docs.nhcarrigan.com/dev/covenant/). ### Dependencies - [ ] I have pinned the dependencies to a specific patch version. ### Style - [ ] I have run the linter and resolved any errors. - [ ] My pull request uses an appropriate title, matching the conventional commit standards. - [ ] My scope of feat/fix/chore/etc. correctly matches the nature of changes in my pull request. ### Tests - [ ] My contribution adds new code, and I have added tests to cover it. - [ ] My contribution modifies existing code, and I have updated the tests to reflect these changes. - [ ] All new and existing tests pass locally with my changes. - [ ] Code coverage remains at or above the configured threshold. ### Documentation _No response_ ### Versioning _No response_ Reviewed-on: #20 Co-authored-by: Naomi Carrigan <commits@nhcarrigan.com> Co-committed-by: Naomi Carrigan <commits@nhcarrigan.com>
2025-12-18 05:21:22 +01:00
parent d0401ad611
commit c5a329d104
24 changed files with 632 additions and 279 deletions
@@ -236,7 +236,12 @@ We offer several email addresses for specific types of inquiries. Please use the
 ### 5.2. Billing and Financial Matters
- Email: billing@nhcarrigan.com
+:::tip[Preferred Method]{icon=message}
 We encourage you to use the **#billing-questions** Discord forum channel for billing inquiries. This allows for public discussion and faster responses. If you need to share sensitive financial information, you can ask staff to make your thread private, or contact us via email for complete confidentiality.
 :::
 - **Discord Forum:** `#billing-questions` (preferred for most inquiries)
 - Email: billing@nhcarrigan.com (for highly sensitive financial information requiring complete confidentiality)
 - Use for:
  - Questions about payments or invoices
  - Inquiries about outstanding balances
@@ -245,6 +250,11 @@ We offer several email addresses for specific types of inquiries. Please use the
 ### 5.3. Technical Support
 :::tip[Preferred Method]{icon=message}
 We encourage you to use the **#technical-support** Discord forum channel for support inquiries. This allows for public discussion and faster responses. If you need to share sensitive information, you can ask staff to make your thread private, or contact us via email for complete confidentiality.
 :::
 - **Discord Forum:** `#technical-support` (preferred for most inquiries)
 - Email: support@nhcarrigan.com
 - Use for:
  - Assistance with using our software or services
@@ -253,7 +263,14 @@ We offer several email addresses for specific types of inquiries. Please use the
 ### 5.4. Privacy Concerns
- Email: privacy@nhcarrigan.com
+:::tip[Preferred Method]{icon=message}
 We encourage you to use our **Privacy Request Form** for privacy-related requests: https://forms.nhcarrigan.com/o/docs/forms/qEJgBWGDfyHv6x51VU9aVX/4
 This form helps ensure we collect all necessary information to process your request efficiently and in compliance with applicable data protection laws.
 :::
 - **Privacy Request Form** (Preferred): https://forms.nhcarrigan.com/o/docs/forms/qEJgBWGDfyHv6x51VU9aVX/4
 - Email: privacy@nhcarrigan.com (for general privacy questions or if you prefer email)
 - Use for:
  - Questions about our privacy policy
  - Requests for data access or deletion
@@ -262,7 +279,15 @@ We offer several email addresses for specific types of inquiries. Please use the
 ### 5.5. Security Matters
- Email: security@nhcarrigan.com
+:::tip[Preferred Method]{icon=message}
 We encourage you to use our **Security Vulnerability Report Form** for reporting security vulnerabilities: https://forms.nhcarrigan.com/o/docs/forms/wgdbBkS4tjCGoVZTqtmMNx/4
 This form helps ensure we collect all necessary information to investigate and address security issues efficiently and securely.
 :::
 - **Security Vulnerability Report Form** (Preferred): https://forms.nhcarrigan.com/o/docs/forms/wgdbBkS4tjCGoVZTqtmMNx/4
 - **Public Security Reports:** View aggregated and sanitized security vulnerability reports for all our products at: https://security.nhcarrigan.com/report/
 - Email: security@nhcarrigan.com (for general security questions or if you prefer email)
 - Use for:
  - Reporting security vulnerabilities
  - Questions about our security practices
@@ -270,7 +295,12 @@ We offer several email addresses for specific types of inquiries. Please use the
 ### 5.6. Legal Inquiries
- Email: legal@nhcarrigan.com
+:::tip[Preferred Method]{icon=message}
 We encourage you to use the **#legal-notices** Discord forum channel for legal inquiries. This allows for public discussion and transparency. If you need to share sensitive legal information, you can ask staff to make your thread private, or contact us via email for urgent matters requiring immediate confidentiality.
 :::
 - **Discord Forum:** `#legal-notices` (preferred for most inquiries)
 - Email: legal@nhcarrigan.com (for urgent legal matters requiring immediate confidentiality)
 - Use for:
  - Legal questions or concerns
  - Copyright or trademark issues
@@ -288,7 +318,12 @@ We offer several email addresses for specific types of inquiries. Please use the
 ### 5.8. Press/Media Inquiries
- Email: press@nhcarrigan.com
+:::tip[Preferred Method]{icon=message}
 We encourage you to use the **#press-inquiries** Discord forum channel for media inquiries. This allows for public discussion and community visibility. If you need to share sensitive information, you can ask staff to make your thread private, or contact us via email for highly sensitive media matters requiring complete confidentiality.
 :::
 - **Discord Forum:** `#press-inquiries` (preferred for most inquiries)
 - Email: press@nhcarrigan.com (for highly sensitive media matters requiring complete confidentiality)
 - Use for:
  - Requesting comment regarding news
  - Scheduling interviews for your media outlet
@@ -305,7 +340,12 @@ We offer several email addresses for specific types of inquiries. Please use the
 ### 5.10. Marketing Inquiries
- Email: marketing@nhcarrigan.com
+:::tip[Preferred Method]{icon=message}
 We encourage you to use the **#marketing-proposals** Discord forum channel for marketing inquiries. This allows for public discussion and community input. If you need to share highly confidential business information, you can ask staff to make your thread private, or contact us via email for proposals requiring complete privacy.
 :::
 - **Discord Forum:** `#marketing-proposals` (preferred for most inquiries)
 - Email: marketing@nhcarrigan.com (for highly confidential business proposals requiring complete privacy)
 - Use for:
  - Marketing collaboration proposals
  - Brand partnership opportunities
@@ -323,7 +363,12 @@ We offer several email addresses for specific types of inquiries. Please use the
 ### 5.12. Partnerships
- Email: partners@nhcarrigan.com
+:::tip[Preferred Method]{icon=message}
 We encourage you to use the **#partnership-requests** Discord forum channel for partnership inquiries. This allows for public discussion and community input on potential partnerships. If you need to share sensitive business information, you can ask staff to make your thread private, or contact us via email if you need complete confidentiality from the start.
 :::
 - **Discord Forum:** `#partnership-requests` (preferred for most inquiries)
 - Email: partners@nhcarrigan.com (if you need complete confidentiality from the start)
 - Use for:
  - Requesting a collaboration between our organisation and yours
  - Sponsorship opportunities for our work
@@ -62,6 +62,12 @@ The Company reserves the right to refuse any project or contract that it determi
 ### 4.3. Continuous Monitoring
 :::tip[Heads Up!]{icon=pen}
 The policy or policies in this section are still a work in progress. We have not yet implemented the necessary infrastructure to comply with this section.
 We are working very hard to get them in place as soon as possible. If you would like to help, consider [applying to join our team!](https://forms.nhcarrigan.com/o/docs/forms/mCxDu3snk9TzFiDjrT4Vc8/4)
 :::
 The Company shall continuously monitor the environmental impact of its ongoing operations and projects, making adjustments as necessary to remain aligned with its sustainability goals.
 ## 5. Legal and Ethical Compliance
@@ -217,10 +217,10 @@ Community Members are required to:
 #### 5.1.1. Available Reporting Methods
 Community Members can report Code of Conduct violations through the following channels:
 - **Incident Report Form** (Preferred): Submit reports through our official Incident Report Form: https://forms.nhcarrigan.com/o/docs/forms/t7CYeYS4uyUuLiKFatoEvs/4
 - **Discord Reporting**: Type `@Moderator` in any channel to alert Community Leaders
 - **Direct Communication**: Contact any Community Leader through private messages
 - **Email Contact**: Submit reports to contact@nhcarrigan.com
 - **Anonymous Reporting**: Use designated anonymous reporting forms where available
 #### 5.1.2. Information to Include in Reports
 Effective reports should include:
@@ -60,6 +60,12 @@ This Policy operates within our comprehensive legal and policy framework, incorp
 #### 2.1.2. Scheduled Feedback Collection
 :::tip[Heads Up!]{icon=pen}
 The policy or policies in this section are still a work in progress. We have not yet implemented the necessary infrastructure to comply with this section.
 We are working very hard to get them in place as soon as possible. If you would like to help, consider [applying to join our team!](https://forms.nhcarrigan.com/o/docs/forms/mCxDu3snk9TzFiDjrT4Vc8/4)
 :::
 **Monthly Community Input Sessions:**
 - Structured community meetings focused on specific policy areas or community improvements
 - Rotating focus areas ensuring comprehensive coverage of community operations and policies
@@ -242,6 +248,35 @@ When immediate policy changes are necessary for community safety:
 - **Advocacy training and resources** empowering community members to effectively participate in governance and change processes
 - **Community campaign support** for democratic initiatives that build broad community support for positive changes
 #### 5.1.3. Demographic Self-Identification
 **Voluntary Self-Identification Process:**
 - **Anonymous demographic self-identification form** enabling community members to voluntarily share demographic information to help us understand community diversity and identify participation barriers
 - **New member onboarding requirement** all new community members are encouraged to complete the self-identification form when joining the community
 - **Annual demographic update** all community members are encouraged to complete the self-identification form at the start of each calendar year to measure demographic trends and changes over time
 - **Complete anonymity** all responses are completely anonymous and aggregated for statistical analysis only; individual responses cannot be linked to specific community members
 **Purpose and Use:**
 - **Demographic diversity assessment** understanding the diversity of our community across various dimensions including age, geographic location, language, gender identity, sexual orientation, race/ethnicity, disability status, neurodivergence, and socioeconomic background
 - **Participation barrier identification** identifying barriers to engagement affecting different demographic groups
 - **Feedback system evaluation** ensuring feedback systems and participation opportunities effectively reach and engage diverse community members
 - **Accessibility improvement** measuring progress toward inclusive representation and identifying areas where accessibility and accommodation efforts need enhancement
 - **Trend measurement** tracking demographic changes and trends over time to understand community evolution
 **Privacy and Confidentiality:**
 - **Complete anonymity** no identifying information is collected; responses cannot be linked to individual community members
 - **Aggregated analysis only** all data is used only in aggregate form for statistical analysis and community improvement purposes
 - **Voluntary participation** participation is completely voluntary; all questions include a "Prefer not to answer" option
 - **Secure data handling** all demographic data is stored securely and handled in accordance with our Privacy Policy and applicable data protection laws
 **Self-Identification Form:**
 Community members can complete the anonymous self-identification form at: https://forms.nhcarrigan.com/o/docs/forms/p7fkz5yJN9GKrQjw5zhX6U/4
 **Completion Requirements:**
 - **New members:** All new community members are encouraged to complete the self-identification form as part of the onboarding process
 - **Annual updates:** All community members are encouraged to complete the self-identification form at the start of each calendar year (January) to help us measure demographic trends and changes over time
 - **Voluntary nature:** While completion is encouraged, participation remains completely voluntary and anonymous
 ### 5.2. Crisis and Emergency Community Consultation
 #### 5.2.1. Emergency Response Input
@@ -280,6 +315,12 @@ When immediate policy changes are necessary for community safety:
 #### 6.1.2. Community-Wide Response Communication
 :::tip[Heads Up!]{icon=pen}
 The policy or policies in this section are still a work in progress. We have not yet implemented the necessary infrastructure to comply with this section.
 We are working very hard to get them in place as soon as possible. If you would like to help, consider [applying to join our team!](https://forms.nhcarrigan.com/o/docs/forms/mCxDu3snk9TzFiDjrT4Vc8/4)
 :::
 **Public Feedback Summaries:**
 - **Monthly summary reports** highlighting community feedback themes, concerns, and suggestions received
 - **Response action reports** detailing how community feedback has influenced policies, decisions, and community improvements
@@ -311,6 +311,12 @@ Nomination form can be found at https://forms.nhcarrigan.com/o/docs/forms/to2oFo
 #### 6.2.2. Representative Recognition Outcomes
 :::tip[Heads Up!]{icon=pen}
 The policy or policies in this section are still a work in progress. We have not yet implemented the necessary infrastructure to comply with this section.
 We are working very hard to get them in place as soon as possible. If you would like to help, consider [applying to join our team!](https://forms.nhcarrigan.com/o/docs/forms/mCxDu3snk9TzFiDjrT4Vc8/4)
 :::
 **Demographic Equity Monitoring:**
 - Regular assessment of recognition distribution across different community demographic groups
 - Proactive outreach to ensure recognition opportunities reach all community segments
@@ -389,6 +395,12 @@ Nomination form can be found at https://forms.nhcarrigan.com/o/docs/forms/to2oFo
 #### 9.1.1. Continuous Improvement Process
 :::tip[Heads Up!]{icon=pen}
 The policy or policies in this section are still a work in progress. We have not yet implemented the necessary infrastructure to comply with this section.
 We are working very hard to get them in place as soon as possible. If you would like to help, consider [applying to join our team!](https://forms.nhcarrigan.com/o/docs/forms/mCxDu3snk9TzFiDjrT4Vc8/4)
 :::
 **Monthly Program Assessment:**
 - Recognition programme effectiveness evaluation and participant satisfaction assessment
 - Recognition distribution analysis to ensure equity and inclusive representation
@@ -153,6 +153,11 @@ You can also reach out to us in our Discord community: https://chat.nhcarrigan.c
 ### 4.1. Finding an Issue
 **For Team Members:** All properly triaged tickets that are ready to be worked on are available on our **Staff Tickets** project board: https://git.nhcarrigan.com/nhcarrigan/-/projects/2
 Team members should refer to this project board to find tickets that are ready for work.
 **For All Contributors:**
 1. Navigate to the project's issue tracker.
 2. Browse open issues or use filters to find tasks that interest you.
 3. Read the issue description thoroughly to understand the requirements and context.
@@ -6,443 +6,633 @@ 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.
+### 5.1. `goal: addition`
 #### 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.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.
+### 6.1. `priority: critical`
 #### 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.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. Finding Ready-to-Work Tickets
 All properly triaged tickets with the `status: ready for dev` label are available on our **Staff Tickets** project board: https://git.nhcarrigan.com/nhcarrigan/-/projects/2
 Team members should refer to this project board to find tickets that are ready to be worked on.
 #### 7.6.4. 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.
@@ -446,6 +446,12 @@ When handling data through our services:
 ### 8.1. Monitoring and Detection
 :::tip[Heads Up!]{icon=pen}
 The policy or policies in this section are still a work in progress. We have not yet implemented the necessary infrastructure to comply with this section.
 We are working very hard to get them in place as soon as possible. If you would like to help, consider [applying to join our team!](https://forms.nhcarrigan.com/o/docs/forms/mCxDu3snk9TzFiDjrT4Vc8/4)
 :::
 We employ various methods to monitor compliance with this AUP:
 **(a)** **Automated Monitoring**: Automated systems to detect prohibited activities;
@@ -664,6 +670,8 @@ For questions about this AUP:
 To report policy violations:
 **Incident Report Form** (Preferred): Submit reports through our official Incident Report Form: https://forms.nhcarrigan.com/o/docs/forms/t7CYeYS4uyUuLiKFatoEvs/4
 **Email:** abuse@nhcarrigan.com
 **Subject Line:** Policy Violation Report - [Service/Platform]
@@ -24,7 +24,6 @@ This Community Support Policy establishes the framework for how community member
 This policy applies to all forms of support exchange within our community platforms, including:
 - Discord channels and direct messages
 - Forums and discussion boards
 - Reddit community spaces
 - Social media interactions
 - GitHub collaborative spaces
@@ -63,7 +62,7 @@ This policy applies to all forms of support exchange within our community platfo
 - Assistance with community projects and initiatives
 - Collaborative problem-solving on shared challenges
 - Skill sharing and mentorship opportunities
- Accessibility assistance and accommodation support
+- Accessibility assistance and accommodation support (request accommodations via our [Accessibility Accommodation Request Form](https://forms.nhcarrigan.com/o/docs/forms/2FXY87PB6aaMHspcnXYCZX/4))
 - Platform-specific guidance and orientation
 #### 2.1.2. Specialised Support Areas
@@ -101,7 +100,6 @@ This policy applies to all forms of support exchange within our community platfo
 #### 2.2.1. Identifying Appropriate Support Channels
 **Platform-Specific Guidelines:**
 - **Discord**: Use designated support channels (#general-support, #tech-help) or reach out to trusted community members
 - **Discord Forums**: Create posts in appropriate forum channels with clear, descriptive titles
 - **Reddit**: Utilise community-specific support threads and appropriate flair
 - **GitHub**: Use issue templates for bug reports, feature requests, and technical support
@@ -137,6 +135,12 @@ This policy applies to all forms of support exchange within our community platfo
 #### 2.2.3. Emergency and Crisis Support
 :::tip[Heads Up!]{icon=pen}
 The policy or policies in this section are still a work in progress. We have not yet implemented the necessary infrastructure to comply with this section.
 We are working very hard to get them in place as soon as possible. If you would like to help, consider [applying to join our team!](https://forms.nhcarrigan.com/o/docs/forms/mCxDu3snk9TzFiDjrT4Vc8/4)
 :::
 **Important Limitations:**
 - Community members are **NOT** mental health professionals
 - Peer support does **NOT** replace professional mental health services
@@ -312,7 +316,7 @@ This policy applies to all forms of support exchange within our community platfo
 **Designated Support Channels:**
 - **#support**: General questions and peer support requests
 - **#support-ticket**: Technical assistance and troubleshooting
- **#accessibility**: Accessibility-related assistance and resources
+- **#accessibility**: Accessibility-related assistance and resources (for accommodation requests, use our [Accessibility Accommodation Request Form](https://forms.nhcarrigan.com/o/docs/forms/2FXY87PB6aaMHspcnXYCZX/4))
 - **Identity-specific channels**: Support spaces for specific communities and identities
 **Direct Message Guidelines:**
@@ -242,6 +242,12 @@ Prohibited misinformation and deceptive practices include:
 ### 4.1. Multi-Layered Moderation System
 :::tip[Heads Up!]{icon=pen}
 The policy or policies in this section are still a work in progress. We have not yet implemented the necessary infrastructure to comply with this section.
 We are working very hard to get them in place as soon as possible. If you would like to help, consider [applying to join our team!](https://forms.nhcarrigan.com/o/docs/forms/mCxDu3snk9TzFiDjrT4Vc8/4)
 :::
 Our moderation approach employs multiple layers:
 **(a)** **Automated Detection**: AI and machine learning systems for initial content screening;
@@ -454,7 +460,7 @@ Effective reports should include:
 ### 6.3. Community Moderation Programme
-We may establish community moderation programmes that include:
+We establish community moderation programmes that include:
 **(a)** **Volunteer Moderators**: Community volunteers who help with content moderation;
@@ -578,6 +584,12 @@ Appeal decisions may result in:
 ### 8.1. Transparency Reporting
 :::tip[Heads Up!]{icon=pen}
 The policy or policies in this section are still a work in progress. We have not yet implemented the necessary infrastructure to comply with this section.
 We are working very hard to get them in place as soon as possible. If you would like to help, consider [applying to join our team!](https://forms.nhcarrigan.com/o/docs/forms/mCxDu3snk9TzFiDjrT4Vc8/4)
 :::
 We are committed to transparency in our moderation practices through:
 **(a)** **Moderation Reports**: Regular reports on moderation activities and statistics;
@@ -276,6 +276,12 @@ Our reporting obligations vary by jurisdiction and may include:
 ### 4.4. Emergency Contact Protocols
 :::tip[Heads Up!]{icon=pen}
 The policy or policies in this section are still a work in progress. We have not yet implemented the necessary infrastructure to comply with this section.
 We are working very hard to get them in place as soon as possible. If you would like to help, consider [applying to join our team!](https://forms.nhcarrigan.com/o/docs/forms/mCxDu3snk9TzFiDjrT4Vc8/4)
 :::
 For immediate emergencies, we maintain:
 **(a)** **Emergency Services:** Direct contact information for emergency services in major jurisdictions;
@@ -296,6 +302,12 @@ For immediate emergencies, we maintain:
 ## 5. RESOURCES AND REFERRALS
 :::tip[Heads Up!]{icon=pen}
 The policy or policies in this section are still a work in progress. We have not yet implemented the necessary infrastructure to comply with this section.
 We are working very hard to get them in place as soon as possible. If you would like to help, consider [applying to join our team!](https://forms.nhcarrigan.com/o/docs/forms/mCxDu3snk9TzFiDjrT4Vc8/4)
 :::
 ### 5.1. Crisis Resources Database
 We maintain an up-to-date database of:
@@ -618,7 +618,7 @@ Changes to this Policy will be communicated through:
 **(b)** Email notifications to registered users;
-**(c)** Community forum announcements and discussions;
+**(c)** Community announcements and discussions;
 **(d)** Documentation updates with clear change logs.
@@ -402,6 +402,12 @@ For cloud and remote service provision:
 ### 6.1. Automated Monitoring Systems
 :::tip[Heads Up!]{icon=pen}
 The policy or policies in this section are still a work in progress. We have not yet implemented the necessary infrastructure to comply with this section.
 We are working very hard to get them in place as soon as possible. If you would like to help, consider [applying to join our team!](https://forms.nhcarrigan.com/o/docs/forms/mCxDu3snk9TzFiDjrT4Vc8/4)
 :::
 We employ automated systems for compliance monitoring including:
 **(a)** **Real-Time Screening**: Real-time screening of all user registrations and transactions against sanctions lists;
@@ -290,6 +290,12 @@ This report is updated according to the following schedule:
 ### 7.4. Verification and Accuracy
 :::tip[Heads Up!]{icon=pen}
 The policy or policies in this section are still a work in progress. We have not yet implemented the necessary infrastructure to comply with this section.
 We are working very hard to get them in place as soon as possible. If you would like to help, consider [applying to join our team!](https://forms.nhcarrigan.com/o/docs/forms/mCxDu3snk9TzFiDjrT4Vc8/4)
 :::
 We ensure report accuracy through:
 **(a)** **Multi-Source Verification:** Cross-referencing multiple internal sources;
@@ -2047,7 +2047,7 @@ For questions, clarifications, or other matters related to this Licence, We may
 ### 17.1. Primary Communication Channels
-#### 17.1.1. Community Forum
+#### 17.1.1. Discord Community
 Our primary venue for Licence-related discussions and inquiries:
@@ -192,13 +192,15 @@ Regardless of your location, you have the following rights regarding your person
 To exercise any of these rights:
-**(a)** Submit requests to **privacy@nhcarrigan.com** from the email address associated with your account;
+**(a)** Submit requests through our **Privacy Request Form** (Preferred): https://forms.nhcarrigan.com/o/docs/forms/qEJgBWGDfyHv6x51VU9aVX/4
-**(b)** Provide sufficient information to verify your identity;
+**(b)** Alternatively, submit requests to **privacy@nhcarrigan.com** from the email address associated with your account;
-**(c)** Specify clearly which right you wish to exercise;
+**(c)** Provide sufficient information to verify your identity;
-**(d)** Include any relevant details or documentation to support your request.
+**(d)** Specify clearly which right you wish to exercise;
 **(e)** Include any relevant details or documentation to support your request.
 ### 5.3. Response Timeframes
@@ -242,6 +244,12 @@ General retention periods include:
 ### 6.3. Automated Deletion
 :::tip[Heads Up!]{icon=pen}
 The policy or policies in this section are still a work in progress. We have not yet implemented the necessary infrastructure to comply with this section.
 We are working very hard to get them in place as soon as possible. If you would like to help, consider [applying to join our team!](https://forms.nhcarrigan.com/o/docs/forms/mCxDu3snk9TzFiDjrT4Vc8/4)
 :::
 Where technically feasible, we implement automated systems to:
 **(a)** Delete information that has exceeded its retention period;
@@ -48,6 +48,8 @@ This Policy is designed to operate within the framework of applicable laws and r
 If you discover a security vulnerability within any of our systems or applications, please report it exclusively through our designated secure reporting channel:
 **Security Vulnerability Report Form** (Preferred): https://forms.nhcarrigan.com/o/docs/forms/wgdbBkS4tjCGoVZTqtmMNx/4
 **Primary Contact:** security@nhcarrigan.com
 **Subject Line Format:** [SECURITY] Brief description of vulnerability
@@ -172,7 +174,7 @@ Our standard coordinated disclosure timeline follows this process:
 **(c)** **Remediation Period:** Development and deployment of fixes (30-90 days depending on complexity);
-**(d)** **Public Disclosure:** Joint announcement of vulnerability and resolution (after fix deployment and reasonable notice period).
+**(d)** **Public Disclosure:** Joint announcement of vulnerability and resolution (after fix deployment and reasonable notice period). Aggregated and sanitized vulnerability reports are published at: https://security.nhcarrigan.com/report/
 ### 4.3. Public Acknowledgement
@@ -388,13 +390,15 @@ We utilise a comprehensive suite of security tools integrated into our developme
 We maintain transparency about our security posture through publicly accessible security reports and dashboards:
-**(a)** **Quality Dashboard:** Real-time security and quality metrics available at https://quality.NHCarrigan.link;
+**(a)** **Security Vulnerability Reports:** Aggregated and sanitized security vulnerability reports for all our products are published at: https://security.nhcarrigan.com/report/
-**(b)** **Security Reports:** Comprehensive security scan results published at https://security.nhcarrigan.com;
+**(b)** **Quality Dashboard:** Real-time security and quality metrics available;
-**(c)** **Regular Updates:** Weekly scanning cycles ensure up-to-date security information;
+**(c)** **Security Reports:** Comprehensive security scan results published;
-**(d)** **Trend Analysis:** Historical data tracking to identify and address security trends over time.
+**(d)** **Regular Updates:** Weekly scanning cycles ensure up-to-date security information;
 **(e)** **Trend Analysis:** Historical data tracking to identify and address security trends over time.
 ### 8.5. Security Development Lifecycle
@@ -464,6 +468,8 @@ If vulnerability research reveals potential regulatory compliance issues or lega
 For all security-related matters, including vulnerability reports, questions about this Policy, and general security inquiries:
 **Security Vulnerability Report Form** (Preferred for vulnerability reports): https://forms.nhcarrigan.com/o/docs/forms/wgdbBkS4tjCGoVZTqtmMNx/4
 **Email:** security@nhcarrigan.com
 **Response Time:** We aim to respond to all security inquiries within 7-10 business days
@@ -300,7 +300,7 @@ We maintain comprehensive service monitoring including:
 Service status information is communicated through:
-**(a)** **Status Page**: Real-time service status available at designated status page;
+**(a)** **Status Page**: Real-time service status available at designated status page at https://uptime.nhcarrigan.com;
 **(b)** **Incident Updates**: Regular updates during service disruptions or maintenance;
@@ -310,6 +310,12 @@ Service status information is communicated through:
 ### 8.3. Transparency Reports
 :::tip[Heads Up!]{icon=pen}
 The policy or policies in this section are still a work in progress. We have not yet implemented the necessary infrastructure to comply with this section.
 We are working very hard to get them in place as soon as possible. If you would like to help, consider [applying to join our team!](https://forms.nhcarrigan.com/o/docs/forms/mCxDu3snk9TzFiDjrT4Vc8/4)
 :::
 We publish regular transparency reports including:
 **(a)** **Monthly Availability Reports**: Summary of availability statistics for each service category;
@@ -352,7 +352,7 @@ Regarding data processed by subprocessors, users may:
 To exercise rights regarding subprocessor data processing:
-**(a)** **Primary Contact:** Contact us at privacy@nhcarrigan.com for coordination;
+**(a)** **Primary Contact:** Submit requests through our **Privacy Request Form** (Preferred): https://forms.nhcarrigan.com/o/docs/forms/qEJgBWGDfyHv6x51VU9aVX/4 or contact us at privacy@nhcarrigan.com for coordination;
 **(b)** **Direct Contact:** Contact subprocessors directly using their provided channels;
@@ -665,6 +665,35 @@ Hello~! I'm Naomi, a 34 year old transfem software engineer and community manage
 <insert bit about community here>
 ``` 
 #### 2.5.2. freeCodeCamp Contributor Sprint Template
 ```md
 ## This issue is part of Naomi's sprint initiatives.
 If you are interested in working on this issue, [join our Discord](https://chat.freecodecamp.org) and ping Naomi!
 ### Action Items
 - [ ] Prototype created and PRed to https://github.com/freeCodeCamp/curriculumexpansion
 - [ ] Prototype reviewed + approved + merged by staff
 - [ ] Break prototype down into steps (if workshop) or individual "step" (if lab) - write description, hint text **only** (no tests yet), and seed code. Refer to https://contribute.freecodecamp.org/how-to-work-on-coding-challenges
 - [ ] DRAFT PR opened on https://github.com/freeCodeCamp/freeCodeCamp
 - [ ] Team + Naomi review your steps, confirm the breakdown + user stories look good
 - [ ] Begin writing the actual test logic, refer to https://contribute.freecodecamp.org/curriculum-help/#basic-usage-pattern for how to write tests for Python challenges
 - [ ] Mark PR as not a draft, team reviews + approves + merges
 - [ ] YOU DID IT GO CELEBRATE!
 ### Other Details
 - Remember to keep an eye on your PRs and respond to review comments and suggestions
 - For workshops, refer to: https://contribute.freecodecamp.org/how-to-work-on-coding-challenges/
 - For labs, refer to: https://contribute.freecodecamp.org/how-to-work-on-labs/
 ### Questions
 Ping Naomi in the sprint channel on Discord
 ```
 ### 2.6. Gaming Templates
 #### 2.6.1. Guild Wars 2 Recruitment Advertisement Template
@@ -681,7 +681,7 @@ Technical Contributors provide development support, code contributions, and tech
 **Community Platform Expertise:**
 - Discord bot development and community tool creation
- Forum and community platform customisation and enhancement
+- Community platform customisation and enhancement
 - Documentation system development and maintenance
 - Accessibility implementation and testing
 - Security assessment and improvement recommendations
@@ -16,17 +16,15 @@ Our community operates across various platforms including:
 **(a)** **Discord Servers**: Real-time communication, voice chat, gaming coordination;
-**(b)** **Forum Systems**: Long-form discussions, documentation, support;
+**(b)** **Code Repositories**: Development collaboration, issue tracking, contributions;
-**(c)** **Code Repositories**: Development collaboration, issue tracking, contributions;
+**(c)** **Social Media**: Community outreach, updates, public engagement;
-**(d)** **Social Media**: Community outreach, updates, public engagement;
+**(d)** **Game Platforms**: MMOs, gaming communities, virtual events;
-**(e)** **Game Platforms**: MMOs, gaming communities, virtual events;
+**(e)** **Documentation Sites**: Knowledge bases, policies, guides;
-**(f)** **Documentation Sites**: Knowledge bases, policies, guides;
+**(f)** **Other Platforms**: Emerging technologies and specialised tools.
 **(g)** **Other Platforms**: Emerging technologies and specialised tools.
 ### 1.3. Integration with Existing Policies
@@ -60,7 +58,6 @@ This training operates within our policy framework:
 **Examples:**
 - **Discord**: Real-time moderation with immediate response capabilities
 - **Forums**: Considered, documented responses with longer discussion threads
 - **Code Repositories**: Technical focus with professional communication standards
 - **Social Media**: Public-facing brand representation with broader audience considerations
@@ -93,69 +90,46 @@ This training operates within our policy framework:
 - Meme and humour sharing common
 - Real-time community events and activities
-### 3.2. Forum Systems
+### 3.2. Code Repositories
 #### 3.2.1. Unique Characteristics
 - Asynchronous, threaded discussions
 - Long-form content and detailed explanations
 - Searchable, persistent content
 - Structured topic organisation
 - Advanced formatting and multimedia support
 #### 3.2.2. Moderation Considerations
 - **Thoughtful Responses**: Time for considered, well-researched replies
 - **Documentation Focus**: Posts serve as long-term resources
 - **Thread Management**: Keeping discussions on-topic and organised
 - **Archive Value**: Content remains accessible long-term
 - **SEO and Discoverability**: Public content may be indexed
 #### 3.2.3. Community Culture
 - Professional, informative tone expected
 - Detailed technical discussions
 - Educational resource creation
 - Mentorship and knowledge sharing
 - Formal support and troubleshooting
 ### 3.3. Code Repositories
 #### 3.3.1. Unique Characteristics
 - Technical development focus
 - Version control and collaboration workflows
 - Issue tracking and project management
 - Code review and quality assurance processes
 - Documentation and technical writing
-#### 3.3.2. Moderation Considerations
+#### 3.2.2. Moderation Considerations
 - **Technical Accuracy**: Focus on correctness and best practices
 - **Professional Standards**: High expectations for communication quality
 - **Intellectual Property**: Copyright and licensing considerations
 - **Contribution Guidelines**: Specific workflow and process requirements
 - **Code of Conduct**: Technical community behavioural standards
-#### 3.3.3. Community Culture
+#### 3.2.3. Community Culture
 - Professional, technical communication
 - Constructive feedback and collaboration
 - Learning and skill development focus
 - Open source values and practices
 - Quality and excellence standards
-### 3.4. Gaming Platforms
+### 3.3. Gaming Platforms
-#### 3.4.1. Unique Characteristics
+#### 3.3.1. Unique Characteristics
 - Game-specific contexts and terminology
 - Real-time coordination and strategy
 - Achievement and progression systems
 - Competitive and cooperative elements
 - Virtual world social dynamics
-#### 3.4.2. Moderation Considerations
+#### 3.3.2. Moderation Considerations
 - **Game-Specific Rules**: Understanding in-game behaviour standards
 - **Performance Pressure**: Dealing with competitive stress
 - **Time-Sensitive Coordination**: Event and activity scheduling
 - **Cross-Platform Gaming**: Integration with external gaming services
 - **Virtual Asset Management**: In-game resources and shared assets
-#### 3.4.3. Community Culture
+#### 3.3.3. Community Culture
 - Gaming-focused communication
 - Strategy and coordination discussions
 - Achievement celebration and recognition
@@ -286,7 +260,6 @@ This training operates within our policy framework:
 #### 5.3.1. Cross-Platform Integrations
 **Available Integrations:**
 - **Discord-Forum Bridges**: Share announcements across platforms
 - **Repository Notifications**: Development updates in community channels
 - **Social Media Coordination**: Consistent messaging across public channels
 - **Event Synchronization**: Calendar integration across platforms
@@ -321,43 +294,29 @@ This training operates within our policy framework:
 - **Channel Management**: Create, modify, and organise channels as needed
 - **Server Settings**: Understand security and moderation settings
-### 6.2. Forum-Specific Responsibilities
+### 6.2. Repository-Specific Responsibilities
-#### 6.2.1. Content Curation
+#### 6.2.1. Technical Moderation
 - Organise and categorise discussion topics
 - Create informative and educational content
 - Moderate long-form discussions and debates
 - Maintain knowledge base and FAQ resources
 #### 6.2.2. Forum Tools and Features
 - **Thread Management**: Move, merge, and organise discussion threads
 - **User Management**: Handle user accounts, permissions, and restrictions
 - **Content Tools**: Edit, format, and enhance community-generated content
 - **Search and Organisation**: Maintain findable, well-organised content
 ### 6.3. Repository-Specific Responsibilities
 #### 6.3.1. Technical Moderation
 - Review contributions for quality and standards
 - Moderate technical discussions and code reviews
 - Enforce coding standards and best practices
 - Support contributor onboarding and development
-#### 6.3.2. Development Tools
+#### 6.2.2. Development Tools
 - **Issue Management**: Track, prioritise, and organise development tasks
 - **Pull Request Review**: Evaluate and approve code contributions
 - **Documentation**: Maintain technical documentation and guides
 - **Community Building**: Foster inclusive development community
-### 6.4. Social Media Responsibilities
+### 6.3. Social Media Responsibilities
-#### 6.4.1. Public Representation
+#### 6.3.1. Public Representation
 - Maintain professional brand representation
 - Respond to public inquiries and comments
 - Share community updates and achievements
 - Monitor for brand mentions and community discussions
-#### 6.4.2. Community Outreach
+#### 6.3.2. Community Outreach
 - **Content Creation**: Develop engaging social media content
 - **Community Engagement**: Interact with broader tech and gaming communities
 - **Crisis Communication**: Handle public relations during difficult situations
@@ -443,12 +402,6 @@ This training operates within our policy framework:
 - Quick community communications and updates
 - Voice chat crisis intervention if needed
 **Forum Crisis Response:**
 - Detailed written responses and explanations
 - Long-form crisis resources and support
 - Archived information for future reference
 - Community discussion facilitation
 **Repository Crisis Response:**
 - Technical issue assessment and response
 - Code security and integrity protection
@@ -549,7 +502,7 @@ This training operates within our policy framework:
 ### 10.1. Scenario 1: Cross-Platform Crisis Coordination
-**Situation**: A crisis situation occurs that affects multiple platforms simultaneously. The crisis involves a safety threat that's being discussed across Discord, forums, and social media. Information is spreading rapidly and inconsistently across platforms.
+**Situation**: A crisis situation occurs that affects multiple platforms simultaneously. The crisis involves a safety threat that's being discussed across Discord and social media. Information is spreading rapidly and inconsistently across platforms.
 **Your Response:**
 1. How do you coordinate response across all platforms?
@@ -563,7 +516,7 @@ This training operates within our policy framework:
 ### 10.2. Scenario 2: Policy Inconsistency Report
-**Situation**: A community member reports that the same behaviour resulted in different moderation actions on different platforms. They received a warning on Discord but were banned on the forum for the same behaviour. They're confused and feel the moderation is inconsistent.
+**Situation**: A community member reports that the same behaviour resulted in different moderation actions on different platforms. They received a warning on Discord but were banned on another platform for the same behaviour. They're confused and feel the moderation is inconsistent.
 **Your Response:**
 1. How do you investigate this inconsistency?
@@ -577,7 +530,7 @@ This training operates within our policy framework:
 ### 10.3. Scenario 3: Cross-Platform Event Coordination
-**Situation**: The community is planning a major event that will happen across multiple platforms simultaneously. The event involves Discord voice channels, forum discussions, social media promotion, and GitHub collaboration. Coordination is complex and requires seamless experience.
+**Situation**: The community is planning a major event that will happen across multiple platforms simultaneously. The event involves Discord voice channels, social media promotion, and GitHub collaboration. Coordination is complex and requires seamless experience.
 **Your Response:**
 1. How do you coordinate event logistics across platforms?
@@ -614,4 +567,3 @@ This training document is part of the comprehensive mandatory training curriculu
 ---
 *This Cross-Platform Coordination Training document is part of our comprehensive staff development programme designed to create seamless community experiences across all platforms. For questions about cross-platform coordination techniques or to report training completion, please contact leadership through designated staff channels.*
@@ -287,6 +287,12 @@ This training provides comprehensive guidance for Team members serving as Data a
 ### 6.1. Data Analytics Infrastructure
 :::tip[Heads Up!]{icon=pen}
 The policy or policies in this section are still a work in progress. We have not yet implemented the necessary infrastructure to comply with this section.
 We are working very hard to get them in place as soon as possible. If you would like to help, consider [applying to join our team!](https://forms.nhcarrigan.com/o/docs/forms/mCxDu3snk9TzFiDjrT4Vc8/4)
 :::
 #### 6.1.1. Data Collection and Storage
 **Data Collection Systems:**
@@ -321,7 +327,6 @@ This training provides comprehensive guidance for Team members serving as Data a
 **Cross-Platform Analytics:**
 - **Discord Analytics**: Integration with Discord for community server analytics
 - **Forum Analytics**: Analysis of forum participation and engagement patterns
 - **Social Media Analytics**: Integration with social media platforms for broader community insights
 - **Event Analytics**: Integration of event participation and satisfaction data
@@ -177,7 +177,7 @@ This training operates within our comprehensive framework:
 ```
 **Incident Type**: [Policy violation category]
 **Date/Time**: [Exact timestamp]
-**Platform**: [Discord/Forum/Repository/etc.]
+**Platform**: [Discord/Repository/etc.]
 **User(s) Involved**: [Anonymized identifiers]
 **Team Member**: [Your name/identifier]
 **Policy Violated**: [Specific policy section]