docs(governance): welcome new contributors and link LF sanctions guidance

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>
This commit is contained in:
tym83 authored and Aleksei Sviridkin committed 2026-10-12 16:08:37 +03:00
1 parent 33ca8b67bb
commit b524a42ae7
1 file changed
+11
+11
View File
@@ -84,11 +84,22 @@ Cozystack maintainers are expected to:
and CNCF Slack workspaces, Telegram groups, and help out when possible.
* Rapidly respond to any time-sensitive security release processes.
* Attend Cozystack community meetings.
* Be familiar with the Linux Foundation guidance on [OFAC sanctions and open source](https://bestpractices.linuxfoundation.org/regulatory/ofac/) and raise any related questions privately with the other maintainers.
If a maintainer is no longer interested in or cannot perform the duties
listed above, they should move themselves to emeritus status.
If necessary, this can also occur through the decision-making process outlined below.
### Welcoming new contributors
A first contribution is often the moment someone decides whether to stay. When a new contributor opens an issue or a pull request:
* Aim to respond within two working days, even if only to say who will review it and when.
* Point to the contributing guide and help with the mechanics. If the DCO check fails, explain how to fix it: `git commit --amend --signoff` for the last commit, or `git rebase --signoff main` for several.
* Before approving a CI run for an external contributor, read the diff and make sure it does not touch workflows, secrets or release tooling in a way that could run untrusted code with project credentials. This applies to every approval, not only the first one.
* Review against the same standards as any other change, and explain the reason behind each requested change. If the change is not going to be accepted, say so early and say why, rather than leaving it open.
* Suggest a good next step: a `good first issue`, a related bug, or a documentation gap.
### Becoming a Maintainer
Anyone can become a Cozystack maintainer. Maintainers should be extremely