|
| 1 | +# Open Cluster Management Repositories Guidelines |
| 2 | + |
| 3 | +This document attempts to outline a structure for creating GitHub repositories |
| 4 | +with the Open-Cluster-Management project. It also describes how and when repositories |
| 5 | +are removed. It is in the best interests of everyone involved in the |
| 6 | +Open-Cluster-Management community that our various projects and repositories are active |
| 7 | +and healthy. This ensures a clear clarification of goal/non-goal of the repositories, |
| 8 | +ensures the maintainers working with stable commitment, ensures a rapid response |
| 9 | +to potential required fixes (e.g. critical security problems) and (most importantly) |
| 10 | +it ensures that contributors and users receive quick feedback on their issues and contributions. |
| 11 | + |
| 12 | +## Rules for New Repositories |
| 13 | + |
| 14 | +* All repos will live in github.com/open-cluster-management-io/\<project-name\>. |
| 15 | +* Have a mission of Kubernetes cluster and multicluster management; |
| 16 | +* Must contain the topic for the sponsoring subprojects - e.g. application. (Added through the Manage topics link on the repo page.) |
| 17 | +* Must adopt the Open-Cluster-Management Code of Conduct. |
| 18 | +* All code projects use the Apache License version 2.0. |
| 19 | +* All OWNERS of the project must also be active Open-Cluster-Management members. |
| 20 | +* Must be approved by the following process. |
| 21 | + 1. It has been discussed and recognized in the community meeting with a |
| 22 | + publicly linkable written decision. |
| 23 | + 2. It must have two sponsors, each of whom must be the maintainer of a sub project. |
| 24 | + 3. A repository onboarding issue is created under this repo. |
| 25 | + |
| 26 | +## Review process |
| 27 | + |
| 28 | +The Steering Committee together with project sponsors will then review the |
| 29 | +application, and decide whether or not to accept it. If it is accepted, the Committee |
| 30 | +will assign one person to assist the Subproject in their integration. |
| 31 | + |
| 32 | +In some cases, promising but incomplete projects may be accepted as Experimental |
| 33 | +Subprojects. Such Experimental Subprojects will be considered part of |
| 34 | +Open Cluster Management, but will be marked as Experimental on the website and in code |
| 35 | +repositories, in order to inform users. Experimental Subproject Members are considered |
| 36 | +Members of Open Cluster Management, but the Subproject is not entitled to a representative on the |
| 37 | +Steering Committee. Steering will review Experimental Subprojects at least twice |
| 38 | +per year to determine if they have matured to full Subproject status. |
| 39 | + |
| 40 | +## Removing Repositories |
| 41 | + |
| 42 | +As important as it is to add new repositories, it is equally important to prune |
| 43 | +old repositories that are no longer relevant or useful. |
| 44 | + |
| 45 | +### Grounds for removal |
| 46 | + |
| 47 | +Repositories may be removed from the project if they |
| 48 | +are deemed _inactive_. Inactive repositories are those that meet any of the |
| 49 | +following criteria: |
| 50 | + |
| 51 | + * There are no longer any active maintainers for the project and no |
| 52 | + replacements can be found. |
| 53 | + * All PRs or Issues have gone un-addressed for longer than six months. |
| 54 | + * There have been no new commits or other changes in more than a year. |
| 55 | + * The contents have been folded into another actively maintained project. |
| 56 | + |
| 57 | +Any Steering Committee member may propose removal of a project on |
| 58 | +these grounds, and Steering can confirm this with a majority vote. |
| 59 | + |
| 60 | +Projects which still have contributors will then be moved to a repository in their |
| 61 | +own namespace. Projects which have ceased all activity are moved to an archive namespace. |
0 commit comments