BlindAssist is a maintainer-led public project. The repository is currently maintained by @violetljj. Contributions in Chinese or English are welcome.
- Small, reversible fixes are decided through pull-request review and the applicable automated checks.
- Broad changes to architecture, permissions, packaged models, feedback behavior, evidence contracts, or licensing should start with a public issue.
- Decisions that change a stable interface or project-wide rule are recorded in the owning current document or an architecture decision record and linked from the pull request.
- Research results never receive default-App, deployment, or safety authority merely because their code is merged. Promotion uses the separate gates in docs/RESEARCH_GOVERNANCE.md.
The maintainer makes the final merge and release decision. Rejections should be explained in terms of scope, evidence, maintenance cost, privacy, licensing, or project safety boundaries rather than contributor identity.
Project work should normally happen in public issues and pull requests. Private channels are reserved for vulnerabilities, credentials, private data, and other sensitive reports covered by SECURITY.md.
Reviewers and maintainers should disclose a material conflict of interest. If the only maintainer is conflicted, the limitation and the available evidence should be recorded publicly without exposing sensitive information.
Roles recognize demonstrated work; they are not rewards for stars, affiliation, or private relationships. Time and pull-request counts are minimum signals, not automatic promotion.
| Role | Minimum evidence | Repository authority |
|---|---|---|
| Contributor | First qualifying pull request merged | No special access |
| Regular contributor | At least 3 merged pull requests across at least 4 weeks; responds to review and keeps scope verifiable | No special access; may be invited to own a follow-up issue |
| Triager / reviewer | Repeatedly reproduces issues, classifies scope, or reviews changes accurately while respecting privacy and evidence boundaries | Bounded issue-triage or review responsibility; no release control |
| Area maintainer | At least 2–3 months of sustained work, at least 5 high-quality merged pull requests, review of other contributors, and demonstrated understanding of the area's safety and evidence boundaries | Limited ownership through scoped CODEOWNERS or equivalent review responsibility |
| Core maintainer | Sustained cross-module decisions plus participation in releases and security-incident handling | Release, security, and cross-module authority granted explicitly |
The current maintainers evaluate quality, continuity, judgment, conflicts of interest, and the project's actual need before each invitation. A candidate may remain at a role without write access indefinitely; contribution quality is not measured only by code volume.
Access is expanded gradually, scoped to the smallest necessary area, reviewed periodically, and may be withdrawn if it is unused or puts users, contributors, or repository integrity at risk. Maintainers with repository access must use an individual account with two-factor authentication, never share credentials, and follow protected-branch, pull-request, required-check, and no-force-push rules. Until a second trusted maintainer exists, a pull-request requirement may use zero mandatory approvals to avoid deadlocking the sole maintainer; required CI and the public review record still apply. The approval count should become at least one when an independent trusted reviewer can reliably satisfy it.
After a contributor's first qualifying pull request merges, the maintainer should thank them in the relevant release notes and offer one bounded follow-up issue in the same area. This is an invitation to continue, not a promise of promotion.
If active maintenance pauses, the repository should say so explicitly. The latest release, open issues, known evidence gaps, and security contact state must not be presented as actively supported when they are not.