Draft formal policy on what Core Committers are allowed to do and not do

[maxime-rainville]

CISO has asked us to nail down this part of the process a bit.

Related (possible duplicate)

• Review Core Committer policy #166

Acceptance criteria

• A formal core committer policy is drafted and covers what action core committer are allowed to perform. use existing documentation per discussion in comments below
• Core committers are required to attest that they have read the policy and agreed to it.
• Core committers are required to re-read the policy on a regular basis.
• The access to the security repo process is folded back into this policy.
• Policy is short enough not to dissuade core committers from reading.
• CISO is satisfied that the policy meet our ISO27K obligations.
• Silverstripe has a defined process for recording and storing proof that core committers have read the policy.

Notes

• We'll have a chat with the core committers about having a formal policy for removing people off if they haven't done something in a while.

Draft policy

This is no longer in consideration.

https://docs.google.com/document/d/1aywYhAxj6k6X3G3xuMf7wFWYq6jSftgsjDGEmWOmvTo/edit

This is a draft policy for Core Committers - that word "draft" is important, it's by no means official at this stage.

Please read through it and suggest any changes you think are appropriate (more detail, additional sections, ask for clarification, etc).

My primary concern while writing this has been the principle of least privilege - not giving admin access to everyone when nobody is really using it, but still keeping access to the wealth of knowledge of the core committers and doing what we can to ensure the community at large has some amount of say in the future of Silverstripe CMS

PRs

The current thinking is that once a year, Core Committers should submit a PR updating the below and update the date by their name, indicating that they have read the linked pages.
The product owner will be responsible for sending an annual reminder.

• DOC Add file for core committers to indicate they read policies #282

[maxime-rainville]

Copied from https://github.com/silverstripeltd/product-issues/issues/842

[maxime-rainville]

Had a look. From an ISO perspective the main concern should be that core committers be reviewed on a regular basis and that they re-read some key policies every once in a while. Combined with not having all core committers owners of the org, that should be enough to please auditors.

I don't necessarily think redefining what expectations of the core committers are part of the ACs as I envisioned them. I would be more inclined to documenting the status quo. It could be useful to rethink what's our expectation for the core committers are, but that should happen in a follow up card.

[GuySartorelli]

I'm no longer sure what you actually want as a deliverable from this issue.

If you just want to document the status quo, that's in https://docs.silverstripe.org/en/5/project_governance/maintainer_guidelines/ and https://docs.silverstripe.org/en/5/project_governance/core_committers/

If you want something for core committers to "sign" (or update on GitHub as you mentioned on slack), that's not what most of this issue says it's for - most of this issue is talking about drafting policy.

The the wording of this issue heavily implies that the intention is to define explicitly what core committers can and cannot do. But the status quo is that they can basically whatever they want and as mentioned above is already documented.

I'm not able to continue working on this without a much clearer set of expectations.

[maxime-rainville]

I think requiring the Core Committers to re-read these two pages once a year is resonnable:

• Secure Coding
• Maintainer Guidlines

Do we have any bits anywhere that says that Core Committers have access to undisclosed security issues and should respect the confidentiality of those discussion? If not, we should probably include this on the Core Committer page.

Could we add a bit that explicitly disallows (or at the very least strongly discourage) self-merges/direct-pushes for people who have that level of access?

Beyond those two points, we probably just need an extra bit to document the process for recording that the policy has been read and periodically reviewing it.

Is that enough for you to go on?