search

silverstripe / .github

0 stars 2 forks source link

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

Open maxime-rainville opened 5 months ago

maxime-rainville commented 5 months ago

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

Related (possible duplicate)

Acceptance criteria

Notes

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.

maxime-rainville commented 5 months ago

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

maxime-rainville commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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

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?

GuySartorelli commented 4 months ago

We'll wait on this until we have a Product Owner again.