In order for the project to be scalable wrt the increase in scope,
number of contributors and associated organizations, we feel the need to
at least establish some rules that will make things easier. There are
two targets:
1. Decrease maintenance costs by paying attention to the contribution
quality, and
2. Enable the community to self-organize and get PRs merged at a faster
pace without increasing associated risks.
And there are two PRs where each addresses one of those points:
1. https://github.com/ComplianceAsCode/content/pull/8314 introduces new
code-related and review-related guidelines, and
2. https://github.com/ComplianceAsCode/content/pull/8359 introduces new
project-level "rules".
It reflects discussions among Red Hat developers, but as this is a
community project, please check it out and provide feedback:
* on Gitter if you feel that you need to ask a short question to
clarify something,
* directly in PRs as a comment or suggestion, or
* here if you don't have a GH account or if you want to approach the
topic on a higher level than PRs do.
In any case, please tell us something, so those guidelines don't come
into effect by being merged simply because they have been laying around
for a couple of weeks._______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
