This document briefly describes "how we make decisions" in the CII Best Practices Badge Project.
This project is a Linux Foundation (LF) Core Infrastructure Initiative (CII) project. The CII is led by a steering committee who represent a variety of organizations; see the CII FAQ for more information.
In terms of "Governance models" (Gardler and Hanganu) the badging project is a bazaar - contributions are gladly welcomed from anyone. The project is led by a single technical lead designated by the CII. The technical lead has final say on decisions (and thus is something of a "benevolent dictator"), but the technical lead is subject to being overruled or replaced by the CII. Also, since the project is FLOSS, the project can be forked; this ability to fork also provides a check against despotism. The technical lead's job is focus on doing what's best for this project, and the project's goal is to help the FLOSS community overall.
The technical lead has commit rights on the software, and administrative rights to the production site, and can add or remove those rights to others. Those with commit rights can make changes (subject to caveats described below) and accept changes (typically pull requests) submitted by others. These changes include changes to the process and contribution requirements.
We generally use the GitHub issue tracker and pull requests for managing changes. For details, including contribution requirements, see CONTRIBUTING.md. Note that we emphasize two-person review for anything other than low-risk contributions.
CII requires two-factor authentication (2FA) for all projects, including this one. In addition, this project does not accept SMS as the second factor.
Issues that we have determined are especially important, particularly if they will take a while, are added to the "next" milestone (which identifies "what should be prioritized next").
We expect people to focus on improving the project, not attacking other people. Please strive to "Be excellent to each other." For more information, see our Code of Conduct.
Changing criteria can have a much larger impact on participating projects than simply changing the supporting software, so we have special rules about them. Fundamentally, any project that has honestly achieved a badge has a right to not have it revoked without notice.
Criteria may be immediately changed if the change will not change the meaning of the criteria, e.g., spelling corrections, grammar corrections, trivial reorderings, and trivial clarifications.
Criteria may have clarifications and minor exceptions added, but there must be an opportunity for discussion. Our usual approach is to create an issue and mark it with "criteria-clarification".
We expect that the criteria will need to be changed in more significant ways over time, but these more significant changes MUST happen much less often and projects MUST be given much more time to either (1) object or (2) modify their project to comply and record that in the BadgeApp (so that they retain their badges). We currently expect that badge criteria will change at most 1/year, and that projects will have at least 2 months' warning before the change. In that 2-month time, the BadgeApp must provide the necessary mechanisms (e.g., using "future" criteria) so that projects can record their new answers and thus have ample time to prevent losing the badge.
The current Badge Project technical lead is David A. Wheeler. Others with commit rights include Dan Kohn and Jason Dossett.
Project participation and interface:
- CONTRIBUTING.md - How to contribute to this project
- INSTALL.md - How to install/quick start
- governance.md - How the project is governed
- roadmap.md - Overall direction of the project
- background.md - Background research
- api - Application Programming Interface (API), inc. data downloads
Criteria:
- criteria.md - Criteria for "passing" badge
- other.md - Criteria for other badges (silver and gold)
Development processes and security:
- requirements.md - Requirements (what's it supposed to do?)
- design.md - Architectural design information
- implementation.md - Implementation notes
- testing.md - Information on testing
- security.md - Why it's adequately secure (assurance case)