Maintainers had no written guidance for a first-time contributor. Add a
short section: reply within two working days, help with the DCO, read
the diff before approving any CI run for an external contributor, review
to the same standard as any other change, and say early when a change
will not be accepted.
Sanctions questions are left to the Linux Foundation guidance, which the
maintainer expectations now link instead of restating it.
Assisted-by: LLM
Signed-off-by: tym83 <6355522@gmail.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
The unversioned /docs/operations/configuration/telemetry/ path is an alias owned by the v0 docs, so GOVERNANCE.md sent readers to the v0 Telemetry page. It now names the v1.6 page, like the Licenses link a few lines below.
Assisted-by: LLM
Signed-off-by: Marian Koreniuk <moriarti@cp.if.ua>
Every apps kind is registered on the one Application Go type, and the
stock Scheme.ConvertToVersion picks the first kind registered for a
type, so without help a Redis comes back from the API as whichever app
kind was registered first. So far the fix lived in a fork of
k8s.io/apimachinery that patches ConvertToVersion. Upstream has not
taken the change, and the fork has to be rebased onto every Kubernetes
minor before the libraries can move.
The apps group now encodes through a serializer that picks the kind the
object carries, along the lines upstream suggested instead of changing
Scheme. The replace directive goes, and with it the Renovate rule that
kept the fork's stale release tags from being proposed as updates. The
serializer relies on the storage stamping the kind on every object it
returns, which it does. A test drives create, get, list, update, watch,
apply and table through the real handler chain for two kinds and fails
without the serializer on upstream apimachinery.
One path converts through the Scheme rather than the serializer and
goes back to the first registered kind: the row objects of a Table
requested with includeObject=Object, which kubectl asks for only with
--sort-by. Admission webhooks and ValidatingAdmissionPolicy get the
request kind set explicitly.
Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <f@lex.la>
GOVERNANCE.md defined a Directors role (non-technical leaders, elected by the maintainers, one vote in decisions), but no Directors were ever identified or elected. The role was intended for non-technical leadership, but those people ended up maintaining parts of the project directly, so it stayed unused. Remove it so the documented decision-making body matches actual leadership (maintainers, by consensus with a simple-majority fallback); it can be reintroduced if a real need arises. Addresses cozystack/community#79.
Signed-off-by: Timur Tukaev <6355522@gmail.com>
The Code Repositories list named seven repositories and was wrong in both
directions: five of the six sub-projects whose code ships in the
distribution were missing from it, while talos-bootstrap and talos-meta-tool
were listed although an adopter installs neither. Nothing said what being on
the list meant, which is why it drifted.
It is replaced by a section organised around the distinction that actually
matters — whether a repository's output reaches the artifact an adopter
installs. Packaged sub-projects get a table naming what each contributes,
its stability and its owners; independent tooling, project infrastructure
and upstream forks are described in a line each as out of that scope.
Three things an evaluator will find anyway are stated rather than left to be
discovered: that one fork (apimachinery) is compiled into the product and
why, that four repositories are private and none of them ships, and that
telemetry is received by a component adopters do not install.
Assisted-By: Claude
Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
The second paragraph argued that an upstream maintained by an individual is
still an upstream. Nobody had disputed it, and a governance document that
defends an unraised objection invites the question instead of settling it.
What remains is the arrangement itself and where the components are listed.
Assisted-By: Claude
Signed-off-by: Andrei Kvapil <andrei.kvapil@aenix.io>
The section named two of the upstreams it describes, which put a list here and
another on the Licenses page, with nothing keeping the two in step — the drift
the link was meant to avoid.
States the rule and the test for applying it; the components it covers stay
enumerated where they already are.
Assisted-By: Claude
Signed-off-by: Andrei Kvapil <andrei.kvapil@aenix.io>
The section states the rule; the licenses page is where the components it
covers are actually enumerated, so point at it rather than restating a list
that would drift.
Assisted-By: Claude
Signed-off-by: Andrei Kvapil <andrei.kvapil@aenix.io>
Cozystack vendors software it does not own, which is ordinary, but the boundary
was nowhere written down. Two of those components are maintained by someone who
is also a Cozystack maintainer — from outside, that is indistinguishable from
project code parked in a personal account, and a reader has to guess.
Records the rule and names those two cases, with what makes them upstreams
rather than components: their own identity and licence, a problem that exists
outside this project, and absence from a default installation.
Assisted-By: Claude
Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
This is a first draft of Cozystack project governance
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Documentation**
- Introduced a new governance document outlining the project's community
roles and responsibilities.
- Clarified roles for various community members including users,
contributors, and leadership.
- Detailed the decision-making process and guidelines to promote
transparent engagement and active participation.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Signed-off-by: Nick Volynkin <nick.volynkin@gmail.com>
Co-authored-by: Nick Volynkin <nick.volynkin@gmail.com>
tym83