Draft Exception Processes for Repository Standards

🧑‍💼 User Need

As a GitHub organisation administrator
I want to define and prepare a draft exception process for repositories that require justified deviations from baseline standards
so that teams have a clear, consistent, and governed path for requesting exceptions, even before the process is formally published or integrated into the developer portal.

💡 Value / Purpose

• Establishes a controlled and auditable mechanism for handling deviations
• Ensures governance remains flexible while maintaining accountability
• Provides clarity for teams needing non‑standard configurations
• Creates documentation that can later be published or integrated into the developer portal when ready
• Supports future automation (e.g., linking exceptions to validation workflows)

🛠️ Description / Context

Some repositories will legitimately require deviations from baseline standards (e.g., alternative licensing, missing CODEOWNERS, non‑standard workflows, special branch protections). Before enforcing standards or automating validation, we must:

• Define what constitutes a valid exception
• Define the approval workflow, including:
  • required justification
  • who reviews
  • who approves
  • how long exceptions remain valid
• Draft the exception process documentation, including:
  • request format
  • review criteria
  • approval steps
  • renewal/expiry rules
• Prepare the documentation for future publication, but without requiring immediate integration into the developer portal
• Ensure the draft aligns with the planned repository‑creation validation workflow

This ticket focuses on drafting and preparing the process, not publishing it.

🧪 Testing steps

• Draft the exception process documentation.
• Review the draft with governance, security, and engineering stakeholders.
• (If possible) - Validate the process using real‑world scenarios (e.g., repos needing alternative workflows).
• Refine the draft based on feedback.
• Store the draft in a suitable location (e.g., DevX Sharepoint) for later publication.

✅ Definition of Done

• Document work completed in Developer Experience Team SharePoint
• Exception criteria defined
• Approval workflow drafted
• Request/justification format documented
• Integration points with validation workflow identified
• Draft reviewed with stakeholders
• Finalised draft stored and ready for future publication

❓ Additional Information

• Be sure to review MoJ Confluence (LAA) and HMPPS documentation to see if anything pre-existing is available for consolidation.

Start by reviewing existing MoJ Confluence (LAA) and HMPPS documentation for material to consolidate. Draft the exception criteria, request format, approval workflow, renewal rules, and validation-workflow integration points in Developer Experience Team SharePoint, then seek governance, security, and engineering review. Done means the reviewed draft is finalised and stored for future publication.