From 87a171b45f270e749f79385f44bd7fc035cd86ae Mon Sep 17 00:00:00 2001 From: Yang Li Date: Thu, 11 Oct 2018 18:36:40 +0800 Subject: [PATCH] Use better reference links for lazy consensus MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit As it’s been used elsewhere in this repo already --- committee-steering/governance/sig-governance-requirements.md | 2 +- committee-steering/governance/sig-governance.md | 2 +- sig-azure/charter.md | 2 +- sig-cloud-provider/CHARTER.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/committee-steering/governance/sig-governance-requirements.md b/committee-steering/governance/sig-governance-requirements.md index e5e621c0f..5c220591c 100644 --- a/committee-steering/governance/sig-governance-requirements.md +++ b/committee-steering/governance/sig-governance-requirements.md @@ -72,7 +72,7 @@ All technical assets *MUST* be owned by exactly 1 SIG subproject. The following - *SHOULD* define target metrics for health signal (e.g. broken tests fixed within N days) - *SHOULD* define process for meeting target metrics (e.g. all tests run as presubmit, build cop, etc) -[lazy-consensus]: http://communitymgt.wikia.com/wiki/Lazy_consensus +[lazy-consensus]: http://en.osswiki.info/concepts/lazy_consensus [super-majority]: https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote [warnocks-dilemma]: http://communitymgt.wikia.com/wiki/Warnock%27s_Dilemma [slo]: https://en.wikipedia.org/wiki/Service_level_objective diff --git a/committee-steering/governance/sig-governance.md b/committee-steering/governance/sig-governance.md index 7edc28565..8a45d7211 100644 --- a/committee-steering/governance/sig-governance.md +++ b/committee-steering/governance/sig-governance.md @@ -155,7 +155,7 @@ Issues impacting multiple subprojects in the SIG should be resolved by either: - after 3 or more months it *SHOULD* be retired - after 6 or more months it *MUST* be retired -[lazy-consensus]: http://communitymgt.wikia.com/wiki/Lazy_consensus +[lazy-consensus]: http://en.osswiki.info/concepts/lazy_consensus [super-majority]: https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote [KEP]: https://github.com/kubernetes/community/blob/master/keps/0000-kep-template.md [sigs.yaml]: https://github.com/kubernetes/community/blob/master/sigs.yaml#L1454 diff --git a/sig-azure/charter.md b/sig-azure/charter.md index c31a2bad5..bf282276f 100644 --- a/sig-azure/charter.md +++ b/sig-azure/charter.md @@ -93,7 +93,7 @@ Subprojects of the SIG MUST use the following processes unless explicitly follow Issues impacting multiple subprojects in the SIG should be resolved by SIG Technical Leads, with fallback to consensus of subproject owners. -[lazy-consensus]: http://communitymgt.wikia.com/wiki/Lazy_consensus +[lazy-consensus]: http://en.osswiki.info/concepts/lazy_consensus [super-majority]: https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote [KEP]: https://github.com/kubernetes/community/blob/master/keps/0000-kep-template.md [sigs.yaml]: https://github.com/kubernetes/community/blob/master/sigs.yaml#L1454 diff --git a/sig-cloud-provider/CHARTER.md b/sig-cloud-provider/CHARTER.md index 1e5d60164..abe12c4bd 100644 --- a/sig-cloud-provider/CHARTER.md +++ b/sig-cloud-provider/CHARTER.md @@ -39,7 +39,7 @@ Subprojects that fall under SIG Cloud Provider may also be features in Kubernete ## Subproject Retirement -Subprojects representing Kubernetes providers may be retired given they do not satisfy requirements for more than 6 months. Final decisions for retirement should be supported by a majority of SIG members using [lazy consensus](http://communitymgt.wikia.com/wiki/Lazy_consensus). Once retired any code related to that provider will be archived into the kubernetes-retired organization. +Subprojects representing Kubernetes providers may be retired given they do not satisfy requirements for more than 6 months. Final decisions for retirement should be supported by a majority of SIG members using [lazy consensus](http://en.osswiki.info/concepts/lazy_consensus). Once retired any code related to that provider will be archived into the kubernetes-retired organization. Subprojects representing Kubernetes features may be retired at any point given a lack of development or a lack of demand. Final decisions for retirement should be supported by a majority of SIG members, ideally from every provider. Once retired, any code related to that subproject will be archived into the kubernetes-retired organization.