Decision making process aligned with guiding principles#39
Decision making process aligned with guiding principles#39KirstieJane wants to merge 8 commits intothe-turing-way:mainfrom
Conversation
…way/governance into kw-decision-making
…tw-governance into kw-decision-making
BatoolMM
left a comment
BatoolMM
left a comment
There was a problem hiding this comment.
Thank you, Kirstie! I’ve left a quick note. I went through the text, and I think it captures our discussions and changes — unless I’ve missed something.
|
|
||
| #### Timeframe | ||
|
|
||
| _Kirstie needs to get clarity from the SC about this - are we asking for a VOTE or just an informal recommendation to bump to a WG / DG?_ |
There was a problem hiding this comment.
My understanding (and I can be wrong), it is an informal recommendation.
There was a problem hiding this comment.
I'm still on the fence for this one:
On the one hand, we have a 'reassign' voting option (below - line 110) which fits this purpose if we need to redirect to the appropriate level by voting.
On the other, a comment on the discussion explaining why the decision is delegated, may be just enough, and it could cut down the waiting time of the vote.
There was a problem hiding this comment.
Yes I don't think we need to vote unless we have a significant difference of opinion on what should be a decision at a different level
There was a problem hiding this comment.
Otherwise we're voting on voting and that seems a little circular
|
|
||
| #### Implementation | ||
|
|
||
| Before any decision is made by the Steering Committee, a dedicated GitHub discussion post at the [GitHub organisation level](https://github.com/orgs/the-turing-way/discussions) is created. |
There was a problem hiding this comment.
I can't remember whether we settled on this or issues in the governance repo.
There was a problem hiding this comment.
I had written up a template issue in the governance repo, with the idea that it would be closed by a PR of the record of the decision.
I do think that a lot of decisions are generated by discussions however, so I wouldn't be hugely in favour of opening up a new discussion just to vote - that feels too separate. So we may need to figure out how to take different sources of decisions into account if we don't want to use the issue approach.
| Anyone can open a discussion asking for a decision or advice from the Steering Committee. | ||
| They can draw the Steering Committee's attention to the request by adding the [`gov-sc-dec-req`](https://github.com/orgs/the-turing-way/discussions?discussions_q=label%3Agov-sc-dec-req) (decision requested) or [`gov-sc-advice-req`]((https://github.com/orgs/the-turing-way/discussions?discussions_q=label%3Agov-sc-advice-req)) (advice requested) labels. |
There was a problem hiding this comment.
I think you need triage (or above) role to manage labels. So, I don't think anyone can create a discussion then label it.
There was a problem hiding this comment.
Alternative, we could create discussion categories to cover these. You can filter discussion based on category (like you can with labels).
It might also be possible to create an action to automate things when a discussion is created. I think that might require using the GraphQL API though.
There was a problem hiding this comment.
+1 to discussion categories. Maybe name it "Request Steering Committee Input"? So members know exactly what the discussion is for, and it tags the SC when opened.
There was a problem hiding this comment.
Only problem with this is what I described above - we've had a couple of cases where it's become clear over the course of a discussion that an SC decision is needed, and at that point I'm not sure you can change the category of discussion?
Given we have a team on GitHub, perhaps people could just @ that instead to draw attention to the discussion if they feel it requires it?
| Rather a decision will be considered passed with a simple majority vote, which at the time of writing would be 5 of the 8 Steering Committee members. | ||
|
|
||
| In the case of a tie (4/8 vote), the decision will pass if the Chair of the Steering Committee approves of the proposal. |
There was a problem hiding this comment.
Maybe we should make this independent of the exact number of SC members? Like, "50% + 1". The exact number will change as working groups are established or wrap up.
| > * 👀 (eyes) or "abstain" - I'm not voting on this for a specific reason (e.g. conflict of interest) | ||
| > * 🚀 (rocket) or "reassign" - this decision should be made at a different level | ||
| > | ||
| > Quorum for this vote is 5/8 Steering Committee members, or 4/8 if the Chair votes for the proposal. |
There was a problem hiding this comment.
Same comment about the numbers here
| Anyone can open a discussion asking for a decision or advice from the Steering Committee. | ||
| They can draw the Steering Committee's attention to the request by adding the [`gov-sc-dec-req`](https://github.com/orgs/the-turing-way/discussions?discussions_q=label%3Agov-sc-dec-req) (decision requested) or [`gov-sc-advice-req`]((https://github.com/orgs/the-turing-way/discussions?discussions_q=label%3Agov-sc-advice-req)) (advice requested) labels. | ||
|
|
||
| If a decision is requested then a vote comment (see [template below](#public-voting)) will be opened within the discussion, including an explicit timeline. |
There was a problem hiding this comment.
My understanding from our chat was that if the discussion needed a vote, an issue will be opened to request it
There was a problem hiding this comment.
that was my understanding too
fixing typos
| #### Timeline | ||
|
|
||
| Verbal (in the Community Forum) and written (in the GitHub repository) reports will be made every three months. | ||
|
|
There was a problem hiding this comment.
We should have a written record of who exactly is responsible for producing written reports - to be frank as Secretary I would this to be a rotating responsibility among the Steering Committee members rather than defaulting to the Secretary or Chair.
Co-authored-by: Jim Madge <jim+github@jmadge.com> Co-authored-by: Precious Onyewuchi <42142405+Preshh0@users.noreply.github.com>
Arielle-Bennett
left a comment
Arielle-Bennett
left a comment
There was a problem hiding this comment.
Reviewed - my main comment is that as an operational document this may be better re-organised since parts of related processes are spread out through it
My suggestion would be that we document operationally the processes for public voting and how things are bought to the steering committee, then have a short discussion on how these processes operationalise our values at the end.
|
|
||
| At the end of the page we include a template [vote comment](#vote-comment-for-steering-committee-members) that can be used to document decision making requests in GitHub discussion posts. | ||
|
|
||
| ## Guiding principle: Inclusion |
There was a problem hiding this comment.
I think we should link back to the guiding principles in the main document if we're referencing them here 😄
|
|
||
| #### Implementation | ||
|
|
||
| Before any decision is made by the Steering Committee, a dedicated GitHub discussion post at the [GitHub organisation level](https://github.com/orgs/the-turing-way/discussions) is created. |
There was a problem hiding this comment.
I had written up a template issue in the governance repo, with the idea that it would be closed by a PR of the record of the decision.
I do think that a lot of decisions are generated by discussions however, so I wouldn't be hugely in favour of opening up a new discussion just to vote - that feels too separate. So we may need to figure out how to take different sources of decisions into account if we don't want to use the issue approach.
| Anyone can open a discussion asking for a decision or advice from the Steering Committee. | ||
| They can draw the Steering Committee's attention to the request by adding the [`gov-sc-dec-req`](https://github.com/orgs/the-turing-way/discussions?discussions_q=label%3Agov-sc-dec-req) (decision requested) or [`gov-sc-advice-req`]((https://github.com/orgs/the-turing-way/discussions?discussions_q=label%3Agov-sc-advice-req)) (advice requested) labels. |
There was a problem hiding this comment.
Only problem with this is what I described above - we've had a couple of cases where it's become clear over the course of a discussion that an SC decision is needed, and at that point I'm not sure you can change the category of discussion?
Given we have a team on GitHub, perhaps people could just @ that instead to draw attention to the discussion if they feel it requires it?
|
|
||
| #### Timeframe | ||
|
|
||
| For each request requiring community voting or recommendations, a timeframe of at least 5 days and at most 8 weeks will be provided after the Steering Committee approves the community engagement plan for that decision. |
There was a problem hiding this comment.
I think we need to make it clear what the flow is:
- Community input phase from 5 days to 8 weeks
- THEN Steering Committee vote of 7 days
So the minimum timeframe for a decision is 2 weeks?
|
|
||
| This timeframe can be extended or shortened by the Steering Committee Chair with publicly documented justification for the change to the recommended length of time. | ||
|
|
||
| ### Regular process review |
There was a problem hiding this comment.
I think this section actually needs to be up the top - otherwise it feels like it's under the inclusion principle and I think it sits across multiple principles
| #### Implementation | ||
|
|
||
| The only pathway for decision making by the Steering Committee is through asynchonous and public (see [below](#public-voting)) voting on a GitHub discussion post. | ||
|
|
There was a problem hiding this comment.
We should add in a bit here about the different emojis being defined in the voting issue template (it doesn't have to live there but it should live somewhere)
|
|
||
| ## Guiding principle: Transparency | ||
|
|
||
| ### Public voting |
There was a problem hiding this comment.
I'm not sure I agree with the structure of having this information separate from other information on the voting process. I understand why this has been organised this way, but you'll see from review comments that I find it confusing not to have all the information about one process in one place. Perhaps there is a better way to show which parts of the process support our guiding values without separating up operational information?
|
|
||
| ### Publicly archiving meeting agendas and notes | ||
|
|
||
| Discussions held during Steering Committee meetings are transparently documented. |
There was a problem hiding this comment.
| Discussions held during Steering Committee meetings are transparently documented. | |
| Discussions held and decisions made during Steering Committee meetings are transparently documented. |
|
|
||
| At each Steering Committee meeting the members will discuss open requests for a decision or advice from the Steering Committee. | ||
|
|
||
| These requests can be found as discussion posts labelled [`gov-sc-dec-req`](https://github.com/orgs/the-turing-way/discussions?discussions_q=label%3Agov-sc-dec-req) (decision requested) or [`gov-sc-advice-req`]((https://github.com/orgs/the-turing-way/discussions?discussions_q=label%3Agov-sc-advice-req)) (advice requested). |
There was a problem hiding this comment.
See comments above about labels and who can use them - we may need to expand this section
| #### Timeline | ||
|
|
||
| Verbal (in the Community Forum) and written (in the GitHub repository) reports will be made every three months. | ||
|
|
There was a problem hiding this comment.
We should have a written record of who exactly is responsible for producing written reports - to be frank as Secretary I would this to be a rotating responsibility among the Steering Committee members rather than defaulting to the Secretary or Chair.
7 participants
I started editing @malvikasharan's first version of our decision making documentation - see #28 - and made so many surface level changes that I ended up making a new branch!
I can open this PR against her branch, but I suspect that won't really help anyone in reviewing because although the content is very similar the structure is very different and won't make much sense in a git history.
I've copied and pasted here from the "table of contents" at the top of the file:
Ask for the steering committee - have I captured all of our decisions from across the summer in this document? Are they clear? Which parts of the process still needs input?
One thing I've taken out is the "red flag" policy. I haven't heard us require this and given that all our decision making is asynchronous, public and does not require consensus.... I don't really know when we'd use it?
I've left in a question about whether we can reassign a request to another level (maintenance most likely) without needing a vote. It feels heavy for us all to vote every time we want to say "you don't need our decision on this".... but I wasn't sure how to operationalise "we chatted and we're not going to accept this request for a decision!"