Add GOVERNANCE.md document #140
Conversation
|
I appreciate you getting to this one! Overall, this is a super well written document, and very clearly defines what little governance policies we have and need. I love the care taken on writing the new section of policies, but totally agree that we need to put a numeric value there to define inactivity. And whatever timeframe chosen I feel like has to be measured in months. Such as maybe 6 months? Or 3? It is really hard to say, but I'd be leaning towards the three personally. But curious to hear if you have any thoughts? |
|
Thanks for the kind words, had a moment of rare inspiration in the early hours of the morning. |
|
I can add the 3 months onto this branch if that suits? e.g. - If a member of a team or role becomes inactive for an extended period of time without a
+ If a member of a team or role becomes inactive for over three months without a |
Yeah that could be could, maybe just add an |
My only issue with |
Ahh I see, this looks fine then to me |
Co-authored-by: Maurício Szabo <[email protected]>
| ## Other roles and responsibilities | ||
|
|
||
| Not every single role or responsibility has been detailed in this document. Some responsibilities are handled as and when required and to the person or people most suited for it. | ||
| Such areas include access details and administration of various tools and services used by the organization, social media account access, fund/donation access and expenses approval and organization secrets access. | ||
| The above policies regarding adding or removing people to these specific privileges still apply. |
There was a problem hiding this comment.
In all honesty, I think we don't in practice have policies we go by on this stuff. We have not been voting, for instance, on who has access to the non-GitHub services we use. Cirrus is implicit via GitHub perms. etc.
This section feels "docs before the policy", "cart before horse", and I don't like being critical, but it doesn't sit right telling people one thing when I full well expect us to do another. (EDIT: Perhaps it would be sufficient for me to say "I dunno if this part is accurate".)
There was a problem hiding this comment.
We have not been voting, for instance, on who has access to the non-GitHub services we use.
No but I think in my opinion it should be done - at the very least these should be (where possible) via the admin email account. For those that are scoped around "teams" type accounts then we should probably start to be more granular with those permissions.
It might seem overkill to vote on all of them in which case I'm all ears for alternative wording here.
| ## Team member & role additions/removals | ||
|
|
||
| Team/role administration and membership decision making is mostly covered by our [Policies](https://github.com/pulsar-edit/.github/blob/main/POLICY.md) but this section details the criteria and justifications for adding or removing team members and/or roles. | ||
|
|
||
| ### Adding members/roles | ||
|
|
||
| Adding team members is performed in much the same way as any other decision (see [Policies](https://github.com/pulsar-edit/.github/blob/main/POLICY.md)) by proposals being made to add somebody to a team or role and a vote then taking place on that proposal. | ||
| If the vote passes without any significant disagreements then the member can be added to the relevant team or role. | ||
| There is no strict set of criteria for addition but generally people who are active in the community and project for an extended period of time, have contributed and added value, and share in the organization's goals & vision can be considered. |
There was a problem hiding this comment.
I'm not sure we had formalized that adding members goes to a vote, though now that I think about it, it has been done most of the times.
Exceptions were the somewhat haphazard early days when it wasn't clear when/if we were going to branch off from atom-community, and we needed some people with permissions just to have people with permissions and to get the ball rolling on Pulsar (not just PRs and discussions at atom-community org).
But this does feel like putting it in writing, which it is. Just noting it. Mixed feelings, since feels mildly "documentation before policy" "cart before horse", but I'm leaning toward this does feel like it is de-facto policy and I seem to recall informal agreement on this one. Just this makes it somewhat formal.
There was a problem hiding this comment.
Sorry it took so long to come back to this, not sure what happened.
So yeah, this one I think has indeed been de-facto policy, the intial grouping was one thing but this has been the process since I joined (02/08) at the very least, including raising access levels.
|
|
||
| Members may belong to more than one team or role and some come hand-in-hand with each other. | ||
|
|
||
| We do not work on a strict set of responsibilities with a strict governance model, we mostly resemble the [Do-ocracy](https://communitywiki.org/wiki/DoOcracy) approach to governance without too much in the way of formal or elaborate governance and policies but we do of course have to have some guidelines and agreed conventions to have a working organization. |
There was a problem hiding this comment.
👍 Do-ocracy sounds about right, that is indeed how we've been doing it at least.
|
I finally put together a proper marked up draft 2 of this for discussion purposes, after all this time, sorry for the delay. My draft/marked up version of the document here, with notes inline:
Hope this can help move things forward, and these are just suggestions as I was reading over it and marking it up with changes I thought to make. Best, |
The idea of this document is to somewhat clarify the organizational structure behind the org and have some place to reference in case it is needed or asked. For such a new project we have a lot of active contributors and by virtue of the project itself we inherited a bunch of stuff to deal with right off the bat rather than being able to grow it organically which does make keeping on top of things a little more difficult.
My main goal with this is not to add anything we aren't already doing (with one exception) nor is it to try to take the fun out of the project with strict rules and bureaucracy. It is designed so that we can have somewhere to actually come up with plans for when we have to deal with difficult situations that nobody otherwise wants to bring up.
For example the one section I added which we don't have precedence for is "removal of roles/members" which is something that has come up in discussion before for those who are still part of the GitHub org but aren't currently participating in the project.
I think this section needs more fleshing out with something we would have to decide on - for example what duration of inactivity or low contribution before we consider somebody "inactive"?
The idea here isn't to punish, it is to make administration easier and grant privileges and access only as required to prevent any damage (malicious or unintentional) to the org and team.
Much of this was based on the questions and guidance in https://opensource.com/article/20/5/open-source-governance.
Very happy to take comments on this as I understand it could well be controversial and may need rewording in more than a few places or we may decide to forgo it entirely and place an abridged version in POLICY.md (or nothing at all).