<commit_before># Kubernetes Repository Guidelines

This document attempts to outline a structure for creating and associating
GitHub repositories with the Kubernetes project. It also describes how and when
repositories are removed.

The document presents a tiered system of repositories with increasingly strict
requirements in an attempt to provide the right level of oversight and
flexibility for a variety of different projects.

Requests for creating, transferring, modifying, or archiving repositories can be
made by [opening a request](https://github.com/kubernetes/org/issues/new/choose)
against the kubernetes/org repo.

- [Associated Repositories](#associated-repositories)
  * [Goals](#goals)
  * [Rules](#rules)
- [SIG repositories](#sig-repositories)
  * [Goals](#goals-1)
  * [Rules for new repositories](#rules-for-new-repositories)
  * [Rules for donated repositories](#rules-for-donated-repositories)
- [Core Repositories](#core-repositories)
  * [Goals](#goals-2)
  * [Rules](#rules-1)
- [Removing Repositories](#removing-repositories)
  * [Grounds for removal](#grounds-for-removal)
  * [Procedure for removal](#procedure-for-removal)
- [FAQ](#faq)

## Associated Repositories

Associated repositories conform to the Kubernetes community standards for a
repository, but otherwise have no restrictions. Associated repositories exist
solely for the purpose of making it easier for the Kubernetes community to work
together. There is no implication of support or endorsement of any kind by the
Kubernetes project, the goals are purely logistical.

### Goals

To facilitate contributions and collaboration from the broader Kubernetes
community.  Contributions to random projects with random CLAs (or DCOs) can be
logistically difficult, so associated repositories should be easier.


### Rules

   * Must adopt the Kubernetes Code of Conduct statement in their repo.
   * All code projects use the Apache License version 2.0. Documentation
     repositories must use the Creative Commons License version 4.0.
   * Must adopt the CNCF CLA bot automation for pull requests.


## SIG repositories

SIG repositories serve as temporary homes for SIG-sponsored experimental
projects or prototypes of new core functionality, or as permanent homes for
SIG-specific projects and tools.

### Goals

To provide a place for SIGs to collaborate on projects endorsed by and actively
worked on by members of the SIG. SIGs should be able to approve and create new
repositories for SIG-sponsored projects without requiring higher level approval
from a central body (e.g. steering committee or sig-architecture)

### Rules for new repositories

   * For now all repos will live in `github.com/kubernetes-sigs/\<project-name\>`.
   * Must contain the topic for the sponsoring SIG - e.g.
     `k8s-sig-api-machinery`.  (Added through the *Manage topics* link on the
repo page.)
   * Must adopt the Kubernetes Code of Conduct
   * All code projects use the Apache License version 2.0. Documentation
     repositories must use the Creative Commons License version 4.0.
   * Must adopt the CNCF CLA bot, merge bot and Kubernetes PR commands/bots.
   * All OWNERS of the project must also be active SIG members.
   * SIG membership must vote using lazy consensus to create a new repository
   * SIG must already have identified all of their existing subprojects and
     code, with valid OWNERS files, in
[`sigs.yaml`](https://github.com/kubernetes/community/blob/master/sigs.yaml)

### Rules for donated repositories

The `kubernetes-sigs` organization is primarily intended to house net-new
projects originally created in that organization. However, projects that a SIG
adopts may also be donated.

In addition to the requirements for new repositories, donated repositories must
demonstrate that:

   * All contributors must have signed the [CNCF Individual
     CLA](https://github.com/cncf/cla/blob/master/individual-cla.pdf) or [CNCF
Corporate CLA](https://github.com/cncf/cla/blob/master/corporate-cla.pdf)
   * If (a) contributor(s) have not signed the CLA and could not be reached, a
     NOTICE file should be added referencing section 7 of the CLA with a list of
the developers who could not be reached
   * Licenses of dependencies are acceptable; project owners can ping
     [@caniszczyk](https://github.com/caniszczyk) for review of third party deps
   * Boilerplate text across all files should attribute copyright as follows:
     `"Copyright <Project Authors>"` if no CLA was in place prior to donation

## Core Repositories

Core repositories are considered core components of Kubernetes. They are
utilities, tools, applications, or libraries that are expected to be present in
every or nearly every Kubernetes cluster, such as components and tools included
in official Kubernetes releases. Additionally, the kubernetes.io website, k8s.io
machinery, and other project-wide infrastructure will remain in the kubernetes
github organization.

### Goals

Create a broader base of repositories than the existing
gh/kubernetes/kubernetes so that the project can scale. Present expectations
about the centrality and importance of the repository in the Kubernetes
ecosystem. Carries the endorsement of the Kubernetes community.

### Rules

   * Must live under `github.com/kubernetes/<project-name>`
   * Must adopt the Kubernetes Code of Conduct
   * All code projects use the Apache Licence version 2.0. Documentation
     repositories must use the Creative Commons License version 4.0.<commit_msg>Add note about updating copyright for donated repos<commit_after># Kubernetes Repository Guidelines

This document attempts to outline a structure for creating and associating
GitHub repositories with the Kubernetes project. It also describes how and when
repositories are removed.

The document presents a tiered system of repositories with increasingly strict
requirements in an attempt to provide the right level of oversight and
flexibility for a variety of different projects.

Requests for creating, transferring, modifying, or archiving repositories can be
made by [opening a request](https://github.com/kubernetes/org/issues/new/choose)
against the kubernetes/org repo.

- [Associated Repositories](#associated-repositories)
  * [Goals](#goals)
  * [Rules](#rules)
- [SIG repositories](#sig-repositories)
  * [Goals](#goals-1)
  * [Rules for new repositories](#rules-for-new-repositories)
  * [Rules for donated repositories](#rules-for-donated-repositories)
- [Core Repositories](#core-repositories)
  * [Goals](#goals-2)
  * [Rules](#rules-1)
- [Removing Repositories](#removing-repositories)
  * [Grounds for removal](#grounds-for-removal)
  * [Procedure for removal](#procedure-for-removal)
- [FAQ](#faq)

## Associated Repositories

Associated repositories conform to the Kubernetes community standards for a
repository, but otherwise have no restrictions. Associated repositories exist
solely for the purpose of making it easier for the Kubernetes community to work
together. There is no implication of support or endorsement of any kind by the
Kubernetes project, the goals are purely logistical.

### Goals

To facilitate contributions and collaboration from the broader Kubernetes
community.  Contributions to random projects with random CLAs (or DCOs) can be
logistically difficult, so associated repositories should be easier.


### Rules

   * Must adopt the Kubernetes Code of Conduct statement in their repo.
   * All code projects use the Apache License version 2.0. Documentation
     repositories must use the Creative Commons License version 4.0.
   * Must adopt the CNCF CLA bot automation for pull requests.


## SIG repositories

SIG repositories serve as temporary homes for SIG-sponsored experimental
projects or prototypes of new core functionality, or as permanent homes for
SIG-specific projects and tools.

### Goals

To provide a place for SIGs to collaborate on projects endorsed by and actively
worked on by members of the SIG. SIGs should be able to approve and create new
repositories for SIG-sponsored projects without requiring higher level approval
from a central body (e.g. steering committee or sig-architecture)

### Rules for new repositories

   * For now all repos will live in `github.com/kubernetes-sigs/\<project-name\>`.
   * Must contain the topic for the sponsoring SIG - e.g.
     `k8s-sig-api-machinery`.  (Added through the *Manage topics* link on the
repo page.)
   * Must adopt the Kubernetes Code of Conduct
   * All code projects use the Apache License version 2.0. Documentation
     repositories must use the Creative Commons License version 4.0.
   * Must adopt the CNCF CLA bot, merge bot and Kubernetes PR commands/bots.
   * All OWNERS of the project must also be active SIG members.
   * SIG membership must vote using lazy consensus to create a new repository
   * SIG must already have identified all of their existing subprojects and
     code, with valid OWNERS files, in
[`sigs.yaml`](https://github.com/kubernetes/community/blob/master/sigs.yaml)

### Rules for donated repositories

The `kubernetes-sigs` organization is primarily intended to house net-new
projects originally created in that organization. However, projects that a SIG
adopts may also be donated.

In addition to the requirements for new repositories, donated repositories must
demonstrate that:

   * All contributors must have signed the [CNCF Individual
     CLA](https://github.com/cncf/cla/blob/master/individual-cla.pdf) or [CNCF
Corporate CLA](https://github.com/cncf/cla/blob/master/corporate-cla.pdf)
   * If (a) contributor(s) have not signed the CLA and could not be reached, a
     NOTICE file should be added referencing section 7 of the CLA with a list of
the developers who could not be reached
   * Licenses of dependencies are acceptable; project owners can ping
     [@caniszczyk](https://github.com/caniszczyk) for review of third party deps
   * Boilerplate text across all files should attribute copyright as follows:
     `"Copyright <Project Authors>"` if no CLA was in place prior to donation
     * If there was a CLA prior to donation, the copyright can be updated post-transfer.
     The copyright _must_ be updated by someone from the donating organization.

## Core Repositories

Core repositories are considered core components of Kubernetes. They are
utilities, tools, applications, or libraries that are expected to be present in
every or nearly every Kubernetes cluster, such as components and tools included
in official Kubernetes releases. Additionally, the kubernetes.io website, k8s.io
machinery, and other project-wide infrastructure will remain in the kubernetes
github organization.

### Goals

Create a broader base of repositories than the existing
gh/kubernetes/kubernetes so that the project can scale. Present expectations
about the centrality and importance of the repository in the Kubernetes
ecosystem. Carries the endorsement of the Kubernetes community.

### Rules

   * Must live under `github.com/kubernetes/<project-name>`
   * Must adopt the Kubernetes Code of Conduct
   * All code projects use the Apache Licence version 2.0. Documentation
     repositories must use the Creative Commons License version 4.0.
{'fraction_non_alphanumeric': 0.061657892388685645, 'fraction_numerical': 0.0032122780405103952, 'mean_word_length': 4.480684596577017, 'pattern_counts': {'":': 0, '<': 9, '<?xml version=': 0, '>': 9, 'https://': 10, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7649683', 'n_tokens_mistral': 3027, 'n_tokens_neox': 2714, 'n_words': 1383}