doc: rewrite GOVERNANCE.md #39

ghost · 2017-09-01T18:16:52Z

this is an Extremely Early write-up for what our future governance structure could look like. there's currently multiple things missing, and it's probably full of inconsistencies and missing links, but it's a start.

TODO:

write how teams are elected
probably write more about efa's
write about github rights management

ghost · 2017-09-01T18:41:13Z

this would close #2

addaleax · 2017-09-01T18:51:17Z

GOVERNANCE.md


-The meeting chair is responsible for ensuring that minutes are taken and that a
-pull request with the minutes is submitted after the meeting.
+There should always be multiple EFAs, a recommended number is 4.


How about 3 or 5 to always have an odd number?

This raises interesting issue - in case of different opinions of EFA there is a vote? If not, how EFA for specific issue is choosen?

Qard · 2017-09-01T19:02:35Z

The term "member" feels a little more exclusionary than collaborator to me, but that could just be my own perspective. Can't really think of a better word than collaborator. 🤔

Some statement on what "consensus" is would be helpful here. ie: 50%? 70%? 100%? When would EFA step in?

ghost · 2017-09-01T19:03:25Z

@Qard idk in my view collaborator was always too connected to actual technical stuff, but i'm open to terminology changes

Qard · 2017-09-01T19:04:14Z

That's fair. Not sure what would be a better word.

Qard · 2017-09-01T19:05:32Z

Maybe just defining the openness of the definition of "members" would work?

ghost · 2017-09-01T19:06:28Z

sure, i could add a Why not collaborator? segment and explain that there

ghost · 2017-09-01T19:10:33Z

regarding the definition of consensus, i believe the TSC has always required a simply majority vote?

lekoder · 2017-09-01T19:27:14Z

GOVERNANCE.md


 * Technical direction
-* Project governance and process (including this policy)
+* Project governance


This words "project governance" as part of "technical issues" - intentional?

lekoder · 2017-09-01T19:27:51Z

GOVERNANCE.md

-the TSC by assigning the `tsc-review` label to a pull request or issue. The
-TSC should serve as the final arbiter where required.
+the TC by assigning the `tc-review` label to a pull request or issue. The
+TC should serve as the final arbiter where required.

 * [Current list of Collaborators](./README.md#current-project-team-members)


I think you are using "Member" now, link still has "Collaborators"

shadowcodex · 2017-09-01T19:29:00Z

I think we should point out that changes and issues submitted by sponsors will not have increased priority over that of members and the community as a whole.

This should be part of the consensus seeking process?

lekoder · 2017-09-01T19:29:11Z

GOVERNANCE.md

-  there is an extended impasse, a motion for a vote may be made.
+There should always be multiple EFAs, a recommended number is 3-5.
+
+EFAs have the intellectual authority to overrule the TC and the CC on issues


As per discord discussion, I think "decisive vote" is a better term here; It implies authority only in case of lack of consensus, which seems to be a core of EFA.

shadowcodex · 2017-09-01T19:40:16Z

GOVERNANCE.md


-The meeting chair is responsible for ensuring that minutes are taken and that a
-pull request with the minutes is submitted after the meeting.
+## Elected Final Arbiters


I know part of this document is to figure out how members get onto each commit so I wanted to start a review thread within this pull to talk about that.

My thoughts (opinions)(perception):

Members elect EFA's

Possibly EFA's elect TC and CC members Alternatively TC & CC are elected by community members.

Upon term expiring for an EFA then a review should kick off to remove or add members to the TC or CC (Similar to a president coming in and out and re-evaluating the cabinet staff?)

TC and CC should have terms as well, but may be re-elected. This will force a periodic review of the member if we aren't reviewing them via the EFA elections.

Other thoughts? These are just ideas and should be taken as that at face value.

scotttrinh · 2017-09-02T13:25:59Z

Spit-balling: If the only duty of the EFA is to break a deadlock, what if EFA's were elected ad hoc, as needed? Mutually agreed upon third-parties?

TimothyGu

I like the simple terminology of TC and CC, though I have to mull on the properties and responsibilities of EFAs a bit...

TimothyGu · 2017-09-02T13:34:46Z

GOVERNANCE.md


 * helping users and novice contributors
 * contributing code and documentation changes that improve the project
 * reviewing and commenting on issues and pull requests
-* participation in working groups
+* participation in adjacent projects


Can I get a clarification on what "adjacent projects" may be? Projects under the ayojs GitHub org? Projects used in Ayo.js? Node.js?

TimothyGu · 2017-09-02T13:41:06Z

GOVERNANCE.md

-The TSC periodically reviews the Collaborator list to identify inactive
-Collaborators. Past Collaborators are typically given _Emeritus_ status. Emeriti
-may request that the TSC restore them to active status.
+The TC periodically reviews the Member list to identify inactive


I don't remember this rule actually being invoked in Node.js. If this is the case, we should reconsider continuing to have it.

I'm not with Node.js project long enough though, so if this is not the case please correct me.

makes sense, i don't remember anything related to that rule being enforced either

TimothyGu · 2017-09-02T13:43:24Z

GOVERNANCE.md


-## Technical Steering Committee
+## Technical Committee


Is how TC members are added documented anywhere (or will they be)? Will the TC have its own repo like Node.js TSC/CTC does?

it will be, yeah!

TimothyGu · 2017-09-02T13:45:31Z

GOVERNANCE.md

+Elected Final Arbiters (EFA) are Members of the Ayo.js projects that serve to
+resolve issues where there is no consensus. They are elected on a 1-year term,
+during which they can choose to resign at any time. In the event that this
+happens, reelections immediately taken into consideration.


Couldn't parse the last sentence, missing a verb in the main clause it seems.

TimothyGu · 2017-09-02T13:47:40Z

GOVERNANCE.md


 ## Consensus Seeking Process

-The TSC follows a [Consensus Seeking][] decision making model as described by
-the [TSC Charter][].
+The TC and the CC follow a [Consensus Seeking][] decision making model.


ghost · 2017-09-02T14:08:32Z

GOVERNANCE.md

-The Technical Steering Committee (TSC) has final authority over this project
-including:
+The Ayo.js project has multiple top-level committees that are responsible for
+managing a part of the project. These committees and their responsibilities are:


i'm not at all satisfied with the phrase managing a part of the project, but i can't think of anything else. thoughts?

s/a part/particular facets/?

What about "directing", "leading", or "stewarding" different parts (or facets, like @TimothyGu suggests) of the project? Directing and leading might be too top-down, and stewarding might go too far in the other direction, so maybe "managing" is best...

ShaneCurcuru · 2017-09-02T14:17:46Z

...point out that changes and issues submitted by sponsors will not have increased priority over that of members and the community as a whole

That's a key differentiator between where it seems Ayo is going versus the Node Foundation's governance. Possibly the biggest difference, at least from the outside perspective.

... EFA's were elected ad hoc, as needed? Mutually agreed upon third-parties?

That's a great idea for an outside perspective, as long as the bulk of your TC/CC members 1) are confident you can find third parties who can show up and understand the issues to make decisions, and 2) are confident the decisions will be in the spirit of the project. It's hard for an outside party to really understand the hard issues when there are disagreements - not impossible, but difficult. Super interesting idea though.

scotttrinh · 2017-09-02T14:46:20Z

@ShaneCurcuru

I imagine the "third parties" would still be parties involved in the project, and are from, perhaps, different committees/boards/areas of influence within the community. They would be the same pool of people that would be elected by the other means currently being suggested. Maybe even community members, library authors, contributors, etc. For particularly hairy situations, this could go to multiple levels: elect people who elect the EFA's. But, I suppose the thrust of my suggestion is that there is no need for a standing set of EFA's, and they have the potential to have outsized influences if EFA is a position someone might serve on across multiple, consecutive issues.

Certainly is worth looking at the history of mutual, non-state arbitration to find prior art on this to inform our decision. Think juries, non-state courts, courts of cultural diasporic peoples, etc.

scotttrinh · 2017-09-02T14:49:55Z

Trying to avoid a classic case of "who watches the watchers?" and keep from saddling the same group of people with the burden of arbitrating for a whole term.

abritinthebay · 2017-09-05T20:20:11Z

Would this document also cover the concept that was discussed of separate WG's for each major feature? I guess that might come under Committees but I'm not sure if consensus was reached around that idea in the first place.

ghost · 2017-09-07T19:04:13Z

@abritinthebay i was gonna add that but i'm not sure if we've reached consensus on what form we want working groups to exist (if at all) yet?

abritinthebay · 2017-09-07T21:07:20Z

@pup makes sense! Was mostly curious 😄. It's one of the things I'm most excited about for Ayo tbh.

Sounds like it would belong here but in a future iteration.

varjmes · 2017-09-11T14:56:21Z

GOVERNANCE.md

+* The moderation team, which enforces the Code of Conduct
+* Multiple sub-teams, which handle more specific matters like maintaining Ayo.js
+  itself or maintaining Ayo.js documentation
+* occasionally, EFA's (Elected Final Arbiters), which serve to break stalemates


can we capitalise the "o" here in "occasionally"

varjmes · 2017-09-11T14:58:01Z

GOVERNANCE.md

+Each team decides who gets permissions for their respective
+repository/repositories.
+
+More information about these teams can be found on the [website]().


I'd just take this out for now.

varjmes · 2017-09-11T14:58:32Z

GOVERNANCE.md

+
+EFAs have the authority to establish a decisive vote on issues where no
+consensus can be reached by the team(s). They do not place
+above the teams in the hierarchy, for they are Members. A EFA should not be


Also I'm interested how an EFA cannot be a member of the Core team. With our current size, this seems hard to do.

Yeah, I agree with @varjmes here, I'd say the only restriction for the EFA(s) is that they haven't already been apart of the issue in question, which will be hard enough to find early on without imposing any further restriction.

ghost · 2017-09-12T14:21:20Z

i'm giving this PR 2 more hours (roughly 6pm CEST) until i land it! cc @ayojs/core

PR-URL: #39 Reviewed-By: James <hello@jmes.tech> Reviewed-By: James Butler <james.butler@sandfox.co.uk>

ghost · 2017-09-12T15:53:01Z

landed in ebca59b!!!! 🎉

ghost added discuss help wanted process meta and removed process labels Sep 1, 2017

addaleax reviewed Sep 1, 2017

View reviewed changes

ghost changed the title ~~doc: rewrite GOVERNANCE.md~~ [WIP] doc: rewrite GOVERNANCE.md Sep 1, 2017

lekoder reviewed Sep 1, 2017

View reviewed changes

shadowcodex reviewed Sep 1, 2017

View reviewed changes

TimothyGu reviewed Sep 2, 2017

View reviewed changes

ghost commented Sep 2, 2017

View reviewed changes

varjmes suggested changes Sep 11, 2017

View reviewed changes

varjmes approved these changes Sep 12, 2017

View reviewed changes

sandfox approved these changes Sep 12, 2017

View reviewed changes

ghost changed the title ~~[WIP] doc: rewrite GOVERNANCE.md~~ doc: rewrite GOVERNANCE.md Sep 12, 2017

ghost force-pushed the pup/governance branch from 7cb2c7b to ff7c5e1 Compare September 12, 2017 15:48

ghost pushed a commit that referenced this pull request Sep 12, 2017

doc: rewrite GOVERNANCE.md

ebca59b

PR-URL: #39 Reviewed-By: James <hello@jmes.tech> Reviewed-By: James Butler <james.butler@sandfox.co.uk>

ghost closed this Sep 12, 2017

ghost force-pushed the pup/governance branch from ff7c5e1 to ebca59b Compare September 12, 2017 15:51

zkat deleted the pup/governance branch September 15, 2017 18:35

zkat mentioned this pull request Sep 27, 2017

potential governance models #2

Closed

This pull request was closed.

doc: rewrite GOVERNANCE.md #39

doc: rewrite GOVERNANCE.md #39

Conversation

ghost commented Sep 1, 2017 • edited by ghost Loading

ghost commented Sep 1, 2017

Choose a reason for hiding this comment

lekoder Sep 1, 2017 • edited Loading

Choose a reason for hiding this comment

Qard commented Sep 1, 2017 • edited Loading

ghost commented Sep 1, 2017

Qard commented Sep 1, 2017

Qard commented Sep 1, 2017

ghost commented Sep 1, 2017

ghost commented Sep 1, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

shadowcodex commented Sep 1, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

scotttrinh commented Sep 2, 2017

TimothyGu left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ShaneCurcuru commented Sep 2, 2017

scotttrinh commented Sep 2, 2017 • edited Loading

scotttrinh commented Sep 2, 2017

abritinthebay commented Sep 5, 2017

ghost commented Sep 7, 2017

abritinthebay commented Sep 7, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ghost commented Sep 12, 2017

ghost commented Sep 12, 2017

ghost commented Sep 1, 2017 •

edited by ghost

Loading

lekoder Sep 1, 2017 •

edited

Loading

Qard commented Sep 1, 2017 •

edited

Loading

scotttrinh commented Sep 2, 2017 •

edited

Loading