summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorYang Li <idealhack@gmail.com>2018-10-11 18:36:40 +0800
committerYang Li <idealhack@gmail.com>2018-10-11 18:36:40 +0800
commit87a171b45f270e749f79385f44bd7fc035cd86ae (patch)
tree6f28be3d47e6395e09fbaee01043bb653bdb5daa
parentdc829aac369ce8967bf7be06b5a0124777c15030 (diff)
Use better reference links for lazy consensus
As it’s been used elsewhere in this repo already
-rw-r--r--committee-steering/governance/sig-governance-requirements.md2
-rw-r--r--committee-steering/governance/sig-governance.md2
-rw-r--r--sig-azure/charter.md2
-rw-r--r--sig-cloud-provider/CHARTER.md2
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 e5e621c0..5c220591 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 7edc2856..8a45d721 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 c31a2bad..bf282276 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 1e5d6016..abe12c4b 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.