├── cli (example CLI)
│ └── cmd (the actual CLI [sub]commands)
├── helpers (mostly untested code intented for project maintainers)
│ ├── convert (convert an KEP in the current format to the new format)
│ │ └── internal
│ │ ├── convert
│ │ ├── extract
I hereby claim:
- I am calebamiles on github.
- I am calebamiles (https://keybase.io/calebamiles) on keybase.
- I have a public key ASCA-W8cq_-rA_HU69MaCHNBcnl6HOSa9ROnGxzfEtnmAgo
To claim this, I am signing this object:
- CRI Validation Suite
- alpha release finished, no more work scheduled until 1.8
- action: move feature issue to next-milestone and update stability to target beta
- Enhance the Container Runtime Interface
- stats endpoint added, but implementation incomplete
- action: move feature issue to next-milestone
- Containerd CRI Integration
- basic support completed, tagged release created
- rework required to consume new containerd client and binary
- total issues: 4550
- issues without SIG: 1639
- issues marked for new contributors: 19
- issues labeled with help wanted: 56
- sig/api-machinery: 568
- priority/backlog: 157
Introduces a modification to Softgoal Interdependency Graph (SIG) models to study software ecosystem (SECO) health. Other than the introduction of terms and a list of the practicies from KDE.
Principled Evaluation of Strengths and Weaknesses in FLOSS Communities: A Systematic Mixed Methods Maturity Model Approach
Proposes a maturity model for FLOSS communities. The paper suggests that more "traditional" metrics based approaches to studying FLOSS communities do not by themselves provide guidance regarding opportunities for improvement which is of use to FLOSS community managers. TODO: pick up reading from page 40
- Production of high quality Kubernetes releases on a reliable schedule
- Ensure there is a consistent group of community members in place to support the release process [1]
- Driving project wide changes necessary to both release bits continuously
- Ensuring high quality Kubernetes releases by:
- defining and staffing release roles to manage resolving and communicating the status of release blocking criteria
- project structure added to governance repository under
Kubernetes
GitHub organization - create "Front Desk" inspired by Debian Project to welcome new contributors
- create mentorship requirement in contributor ladder
- adopt RFC process inspired by Rust langage governance
- create technical steering committee bootstrapped from "top level OWNERS" as penultimate arbiters with power vested in Kubernetes community to make all final decisions
- affirm decision by technical steering committee in case inability of community to make decision
- devolve primary decision making and consensus building authority to SIGs
- Healthy Open Source
- explicit goal to be a lightweight process
- concrete ability to scale to hundreds of contributors
- good fundamental goals
- transparency
- participation
- efficacy
- ecosystem projects encouraged but not required to adopt foundation governance templates
- creation of projects under TSC explicity delegates authority from TSC to project TC
NewerOlder