hackforla / hackforla/lucky-parking
Define repository merge-governance ruleset and rollout plan
- Dominant language
- Jupyter Notebook
- Stars
- 37
- Forks
- 60
- Avg merge
- 13h 32m
- Merged PRs (30d)
- 5
Description
### Description
Conduct a timeboxed spike to define an evidence-based, contributor-friendly merge-governance model for the repository. The outcome is an approved ruleset design and implementation backlog; do not change GitHub repository settings as part of this task.
### Action Items
- [ ] Audit current repository branch protections, rulesets, organization policies, bypass actors, and existing merge practices.
- [ ] Define the purpose and protection level of `main` and `stable`, including whether each should use the same policy.
- [ ] Propose pull-request, approval, stale-approval, self-approval, and conversation-resolution requirements.
- [ ] Inventory the exact check names produced by compliance, Integration, CodeQL, and any quality tools; identify which are safe to make required and when.
- [ ] Define direct-push, force-push, branch-deletion, and narrowly scoped emergency-bypass policies, including how exceptions are recorded.
- [ ] Evaluate merge-queue suitability, capacity/merge-volume threshold, and required `merge_group` workflow changes.
- [ ] Evaluate a CODEOWNERS/review-ownership model, including contributor and maintainer coverage.
- [ ] Evaluate the readiness criteria for requiring CodeQL and external quality/security checks.
- [ ] Identify policy conflicts, dependencies, and prerequisites with organization-level GitHub settings.
- [ ] Produce a written recommendation with proposed ruleset settings, staged rollout, validation cases, rollback plan, and explicitly scoped follow-up implementation tickets.
### Additional Information
Related work: #739 (PR compliance), #740 (Integration hardening), #741 (CodeQL), #742 (CodeRabbit OSS/SonarQube Cloud), and #744 (GitHub Actions validation).
This is a discovery and design task. Do not enable merge queue, CODEOWNERS enforcement, CodeQL/quality gates, or branch rules until the recommendation is reviewed and approved.
The resulting policy should protect protected branches without creating missing-check deadlocks or an unclear reviewer path for contributors.
Contributor guide
Research direction
Start with the repository's current GitHub branch protections, rulesets, organization policies, bypass actors, merge practices, and workflow check names; review related issues #739–#744 for dependencies. The finished work is an approved written recommendation covering ruleset settings, staged rollout, validation cases, rollback, and scoped implementation tickets, without changing settings.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github, github-actions
- Domain
- ci-cd, devops
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 35/100