mirror of
https://github.com/falcosecurity/falco.git
synced 2025-09-16 23:08:16 +00:00
docs: move governance to falcosecurity/.github
See https://github.com/falcosecurity/.github/pull/25 Signed-off-by: Leonardo Grasso <me@leonardograsso.com>
This commit is contained in:
@@ -1,55 +0,0 @@
|
|||||||
# Process for becoming a maintainer
|
|
||||||
|
|
||||||
* Express interest to the existing maintainers that you or your organization is interested in becoming a
|
|
||||||
maintainer. Becoming a maintainer generally means that you are going to be spending substantial
|
|
||||||
time (>25%) on Falco for the foreseeable future. You should have domain expertise and be extremely
|
|
||||||
proficient in C++. Ultimately your goal is to become a maintainer that will represent your
|
|
||||||
organization.
|
|
||||||
* We will expect you to start contributing increasingly complicated PRs, under the guidance
|
|
||||||
of the existing maintainers.
|
|
||||||
* We may ask you to do some PRs from our backlog.
|
|
||||||
* As you gain experience with the code base and our standards, we will ask you to do code reviews
|
|
||||||
for incoming PRs (i.e., all maintainers are expected to shoulder a proportional share of
|
|
||||||
community reviews).
|
|
||||||
* After a period of approximately 2-3 months of working together and making sure we see eye to eye,
|
|
||||||
the existing maintainers will confer and decide whether to grant maintainer status or not.
|
|
||||||
We make no guarantees on the length of time this will take, but 2-3 months is the approximate
|
|
||||||
goal.
|
|
||||||
|
|
||||||
## Maintainer responsibilities
|
|
||||||
|
|
||||||
* Monitor Slack (delayed response is perfectly acceptable).
|
|
||||||
* Triage GitHub issues and perform pull request reviews for other maintainers and the community.
|
|
||||||
* During GitHub issue triage, apply all applicable [labels](https://github.com/falcosecurity/falco/labels)
|
|
||||||
to each new issue. Labels are extremely useful for future issue follow up. Which labels to apply
|
|
||||||
is somewhat subjective so just use your best judgment.
|
|
||||||
* Make sure that ongoing PRs are moving forward at the right pace or closing them.
|
|
||||||
* Participate when called upon in the security releases. Note that although this should be a rare
|
|
||||||
occurrence, if a serious vulnerability is found, the process may take up to several full days of
|
|
||||||
work to implement. This reality should be taken into account when discussing time commitment
|
|
||||||
obligations with employers.
|
|
||||||
* In general continue to be willing to spend at least 25% of ones time working on Falco (~1.25
|
|
||||||
business days per week).
|
|
||||||
|
|
||||||
## When does a maintainer lose maintainer status
|
|
||||||
|
|
||||||
If a maintainer is no longer interested or cannot perform the maintainer duties listed above, they
|
|
||||||
should volunteer to be moved to emeritus status. In extreme cases this can also occur by a vote of
|
|
||||||
the maintainers per the voting process below.
|
|
||||||
|
|
||||||
# Conflict resolution and voting
|
|
||||||
|
|
||||||
In general, we prefer that technical issues and maintainer membership are amicably worked out
|
|
||||||
between the persons involved. If a dispute cannot be decided independently, the maintainers can be
|
|
||||||
called in to decide an issue. If the maintainers themselves cannot decide an issue, the issue will
|
|
||||||
be resolved by voting. The voting process is a simple majority in which each senior maintainer
|
|
||||||
receives two votes and each normal maintainer receives one vote.
|
|
||||||
|
|
||||||
# Adding new projects to the falcosecurity GitHub organization
|
|
||||||
|
|
||||||
New projects will be added to the falcosecurity organization via GitHub issue discussion in one of the
|
|
||||||
existing projects in the organization. Once sufficient discussion has taken place (~3-5 business
|
|
||||||
days but depending on the volume of conversation), the maintainers of *the project where the issue
|
|
||||||
was opened* (since different projects in the organization may have different maintainers) will
|
|
||||||
decide whether the new project should be added. See the section above on voting if the maintainers
|
|
||||||
cannot easily decide.
|
|
Reference in New Issue
Block a user