| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This document is meant to be used by repos without too much traffic,
if they wish to migrate the default branch from master to main.
|
|
|
|
Since the kubernetes-incubator org has now been retired, this commit
removes references to the org from our docs.
Note that this commit does NOT remove references in the following docs:
* design proposals
* meeting notes
* docs/notes from old events
|
|
|
|
subproject-responsibilites.md -> subproject-responsibilities.md
|
|
|
|
Netlify has switched their hosted site domain from .com to .app.
Example:
kubernetes-foo.netlify.com -> kubernetes-foo.netlify.app
|
|
Add idealhack as New Membership Coordinator
|
|
|
|
|
|
|
|
Using the current instructions, we can only create repos using the
template repo if the template repo is in the same org as the new repo.
If template repo is _not_ in the same org, we can still use it by visiting
the template repo page and clicking on "Use this template".
|
|
|
|
calebamiles has graciously agreed to step down to make room
|
|
Update who must approve repo creation requests
|
|
Ref: https://github.blog/2019-06-06-generate-new-repositories-with-repository-templates/
|
|
The process is only meant for org admins so move to that doc and
decouple the process from the rules and guidelines for repos, which are
meant for everyone.
|
|
Current state of docs:
- https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md#subproject-creation
mentions that repos _may_ be created under k-sigs by a lazy consensus of subproject owners.
- Some charters like https://github.com/kubernetes/community/blob/master/sig-api-machinery/charter.md#deviations-from-sig-governance
have explicit processes setup for who can approve repo creation requests.
- https://github.com/kubernetes/community/blob/master/github-management/kubernetes-repositories.md#rules-for-new-repositories
says that repo creation requests must be approved by lazy consensus of SIG membership.
Current state of how we do things:
- We create repos if the SIG leads have approved the repo creation
request.
- We don't require a lazy consensus thread on the mailing list, just a
publicly linkable written decision.
This commit reconciles the docs with the current state of how we do this.
Note that the wording says "process spelled out in the SIG charter"
because SIG charters _may_ also define a complete process on how they'd
like to handle this, not just the list of people who can approve repo
creation requests.
|
|
- Moves adding a `netlify.toml` at the root of the repo to the beginning
of the process, so that the site can be viewed directly once Netlify is
configured.
- Add a note about "Basic Build Settings" getting autopopulated with values
in netlify.toml.
- Remove step about explicitly enabling HTTPS. Netlify enables HTTPS
automatically after DNS records are updated.
- Some markdown improvements.
|
|
|
|
Add subproject site request guidelines.
|
|
|
|
|
|
github-management: document team structure and process
|
|
github-management: add suggestions for creating new repos
|
|
|
|
Per comments in review, switching to use shortened URLs to
comply with style guidelines.
Signed-off-by: Steve Winslow <swinslow@gmail.com>
|
|
Signed-off-by: Steve Winslow <swinslow@gmail.com>
|
|
Ref: https://groups.google.com/d/topic/kubernetes-sig-architecture/TjHLgJcDF-I/discussion
|
|
|
|
|
|
|
|
|
|
|
|
An approver/reviewer in @kubernetes, may sponsor someone for the
kubernetes org or any of the related organizations
(kubernetes-sigs, kubernetes-csi etc); as long as it's a project
they're involved with.
However, this does not work the other way around.
A sponsor that is only an approver/reviewer in kubernetes-sigs cannot
sponsor someone for membership in the kubernetes org.
They are scoped just to the org they're associated with.
|
|
grodrigues3 has graciously agreed to step down for nikhita on the
team
I will step in as subproject owner
add the membership team as reviewers
|
|
|
|
FILE: ./sig-cloud-provider/CHARTER.md
[✖] https://github.com/kubernetes/community/blob/master/keps/0002-controller-manager.md
→ Status: 404
[✖] https://github.com/kubernetes/community/blob/master/keps/0002-controller-manager.md#repository-requirements
→ Status: 404
FILE: ./github-management/setting-up-cla-check.md
[✖] https://identity.linuxfoundation.org/lfcla/github/postreceive?group=284&comment=no&target=https://identity.linuxfoundation.org/projects/cncf
→ Status: 404
FILE: ./sig-scalability/blogs/k8s-services-scalability-issues.md
[✖] https://cilium.io/blog/2018/04/17/why-is-the-kernel-community-replacing-iptables)
→ Status: 404
FILE: ./sig-scalability/goals.md
[✖] provider-configs.md → Status: 400 Error: ENOENT: no such file or
directory, access
'/home/jorge/src/kubernetes/community/sig-scalability/provider-configs.md'
|
|
|
|
doing these changes in a separate PR before doing content changes
in followup PR's
|
|
|
|
|
|
|
|
Signed-off-by: Mike Brown <brownwm@us.ibm.com>
|
|
|
|
|
|
|
|
Added a new case I just ran into, and removed SIG Architecture
from having to be involved in the decision to archive (I view
consulting SIG Arch as part of the process for finding new
active maintainers of the project, we could bake this into the
language if it needs to be explicit)
Formatting changes:
- Trimmed whitespace in the FAQ
- Unindented headers
- FAQ questions are now bold rather than italic
- Repo removal is a checklist to follow
|
|
|
