search

kubernetes / community

Kubernetes community content
Apache License 2.0
11.82k stars 5.14k forks source link

Project Governance Umbrella issue #402

Closed bgrant0607 closed 6 years ago

bgrant0607 commented 7 years ago

There have been a number of discussions about project governance.

Relevant issues:

One thing that is clear is that people are trying to solve different problems. The purpose of this issue is to surface those problems and (ideally) to come to agreement about which problems we're going to tackle first. Then we get move onto proposals for how we're going to solve them.

Some problems that have been mentioned, culled from the above, in no particular order:

What other problems do people think we need to solve? Let's brainstorm first, then prioritize and cull.

cc @sarahnovotny @brendandburns @countspongebob @sebgoa @pmorie @jbeda @smarterclayton @thockin @idvoretskyi @calebamiles @philips @shtatfeld @craigmcl

countspongebob commented 7 years ago

Brian, great list, thanks for pulling this together.

One of the key issues for our project is whether we are philosophically running more of a top-down, hierarchically oriented project, or more of a decentralized one. I think if we can get some consensus on that (or get the BDFLs to agree), the implementation strategies become more clear.

There are good arguments both ways for how to tilt our direction.

My specific proposal was an attempt to create something more decentralized yet with enough structure to not be chaotic. Kubernetes is today effectively a BDFL model. I was attempting (perhaps poorly) to advocate for a more decentralized model.

I heard through back channels that my proposal offended a few of the BDFLs. We have awesome BDFLs, so this is not intended as criticism of any of those individuals, all of whom I have a deep personal respect for.

I believe that a different structure will lead to long term better results, yet reasonable people can disagree on this point.

If we can resolve that one critical project strategic direction, much of the rest will follow.

-Bob

dankohn commented 7 years ago

It's an embarrassingly small part of your list, but CNCF staff is actively working on taking "...responsibility for legal issues, license validation, trademark enforcement, etc." In particular, we'll soon be presenting a program to the K8s project leaders and the TOC of monthly retroactive license scans of all code, especially vendored libraries and incubator projects.

CNCF staff stand ready to do more (e.g., we're having discussions about spending money to improve metrics, GitHub tooling and CI).

brendandburns commented 7 years ago

In addition to defining roles, I'd like to see us define the process for decision making.

One other thing that concerns me with our current (lack of) governance structure is that it kind of papers over the fact that SIGs sometimes make changes that have really broad impact (sig-api-machinery, I'm looking at you...).

Currently we've been allowing SIGs to make these decisions without much input from the rest of the community. I'd like to see some notion of what size of decision is ok for a SIG to make for themselves, and what kind of decision we need to escalate to a broader group of folks. (and what that process looks like)

bgrant0607 commented 7 years ago

One description of a few common governance structures: https://opensource.guide/leadership-and-governance/#what-are-some-of-the-common-governance-structures-for-open-source-projects

bgrant0607 commented 7 years ago

A TBD from the governance.md PR:

sebgoa commented 7 years ago

Incubator:

The current structure of the incubator is light weight by design but it lacks:

Suggestions:

bgrant0607 commented 7 years ago

From a comment by @jbeda on the architectural layers doc:

brendandburns commented 7 years ago

fwiw, there data + analysis tools for the community survey data is here:

https://github.com/brendandburns/k8s-community-survey

thockin commented 7 years ago

When the title is "governance", it brings to mind a particular class of concerns for me. This is not to diminish the importance of the many other issues we have as a codebase, project, and community, but I think GOVERNANCE is really the framework by which we decide who gets to decide.

1) There aren't official technical leads for subareas of the project.

2) There is no clear escalation path / procedure.

3) The org structure of the project is opaque to newcomers.

3) There is no official process for joining & progressing through org roles.

5) There is no official body to drive overall technical vision of the project.

I'm not arguing for a BDFL model, but I am wary of a fully democratic process, at least without some grounding in actual contribution/activity.

I'm not 100% sure what Bob means by "more decentralized". I'm sort of a concrete, literal person, so maybe you can get more specific with a straw man?

Rebuilding my own straw man from the other thread, from the bottom up:

Special Interest Groups (SIGs) are the lowest level of group ownership. The whole project is covered by SIGs. Any topic that does not naturally fall into a SIG must find a SIG willing to expand scope, or else petition for a new SIG (process TBD). Any topic which naturally falls into multiple SIGs must find a "home" SIG. SIGs can spawn limited-lifetime Working Groups (WGs) to drive particular goals (process TBD).

Each SIG has a SIG-Lead and a SIG-TL. SIG-Leads are volunteers (process TBD) nd need not be as deeply involved as the SIG-TL, but are responsible for running SIG meetings, etc. SIG-TLs are drawn from the OWNERs of the relevant area (process TBD). SIG-TLs are the deciders for technical matters within their domains, and are responsible for technical direction and "traffic control" of contributions. All SIG-TLs must come together on a regular basis to produce status and planning artifacts.

The Product Management Group (PMG) is drawn from major contributing parties (process TBD), and is responsible for driving non-technical topics, such as cross-SIG features, deadlines, releases, etc. SIG-TLs are beholden to the PMG, and are expected to implement the plans therefrom.

Issues that cannot be resolved satisfactorily by the SIG-TLs and PMG can be escalated to the Elders (better name, pleeeeease), who are the final arbiters (process TBD). The Elders are drawn from the project LEADS (process TBD), and must convene on a regular basis to consider issues such as project scope, architecture, overall roadmap, project health, etc.

There's a lot of room for refinement in there, but it gets to the heart of my main concern - a system of roles that are clearly defined, with fairly obvious scope, and fairly unambiguous authority. Most importantly - this is easily memorized and is distinct from (through in most cases drawing candidates from) the contributor ladder and org-wide roles, which deserve their own doc and process definition.

idvoretskyi commented 7 years ago

The Product Management Group (PMG) is drawn from major contributing parties (process TBD), and is responsible for driving non-technical topics, such as cross-SIG features, deadlines, releases, etc.

@thockin We already have the SIG-PM [1], and its responsibility is more or less equal to that what you've described. Does your concept of PMG fit the concept of SIG-PM or PMG is rather a separate sub-organization?

  1. https://github.com/kubernetes/community/tree/master/sig-pm
thockin commented 7 years ago

It was designed to formalize the role of SIG-PM with regards to the rest of my sketch.

On Thu, Mar 16, 2017 at 3:22 AM, Ihor Dvoretskyi notifications@github.com wrote:

The Product Management Group (PMG) is drawn from major contributing parties (process TBD), and is responsible for driving non-technical topics, such as cross-SIG features, deadlines, releases, etc.

We already have the SIG-PM [1], and its responsibility is more or less equal to that what you've described. Does your concept of PMG fit the concept of SIG-PM or PMG is rather a separate sub-organization?

  1. https://github.com/kubernetes/community/tree/master/sig-pm

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kubernetes/community/issues/402#issuecomment-287015145, or mute the thread https://github.com/notifications/unsubscribe-auth/AFVgVGwhnZW5jfykOjOlWH9tw6SdXZu8ks5rmQ1ugaJpZM4MLmBs .

jbeda commented 7 years ago

@thockin I like your sketch.

But I do worry about the phrasing: "SIG-TLs are beholden to the PMG, and are expected to implement the plans therefrom." This implies a level of command and control that may not be practical. In an OSS project we can't really tell anyone where to spend their time. We can withhold support, not merge, not review, etc. But we can't make stuff happen if folks aren't bought in.

Also, while we have a clear (ish) idea of what it means to be a technical contributor (PRs, reviews, etc). We don't have an idea for the product side. We can either require that folks that have deciding power in the PMG must also be contributors or we have to come up with some other way for folks in that group to prove themselves.

Concretely, I don't want a big company to one (or many) people who call themselves PMs and have them come in and try to direct the project without establishing themselves in the community. Part of the ethos of our community is that the project must come ahead of commercial concerns. That can only be shown through actions over time.

thockin commented 7 years ago

On Thu, Mar 16, 2017 at 9:59 AM, Joe Beda notifications@github.com wrote:

@thockin I like your sketch.

But I do worry about the phrasing: "SIG-TLs are beholden to the PMG, and are expected to implement the plans therefrom." This implies a level of command and control that may not be practical. In an OSS project we can't really tell anyone where to spend their time. We can withhold support, not merge, not review, etc. But we can't make stuff happen if folks aren't bought in.

Sure, I thought about that as I was writing, but I wasn't sure the right words. Like any constitution, we need to find the right balance of powers and the right checks on those powers.

Also, while we have a clear (ish) idea of what it means to be a technical contributor (PRs, reviews, etc). We don't have an idea for the product side. We can either require that folks that have deciding power in the PMG must also be contributors or we have to come up with some other way for folks in that group to prove themselves.

Agree. What if PMG is elected by the OWNERS or MAINTAINERS to represent the product interests. In a way, it's still an engineering driven project, but with a refinement from actual product people.

E.g. if there are enough MAINTAINERS from company X, they can get a PM on the PMG; but they could also just demonstrate enough PM-contribution to be elected naturally. There can be PM contributors that are not elected to PMG just as there are technical contributors who are not MAINTAINERs. I am sure there's some vote distribution technique that prevents non-obvious gaming...

Concretely, I don't want a big company to one (or many) people who call themselves PMs and have them come in and try to direct the project without establishing themselves in the community. Part of the ethos of our community is that the project must come ahead of commercial concerns. That can only be shown through actions over time.

100% agreed.

countspongebob commented 7 years ago

@thockin : Three branches proposal is my concrete proposal for distributing project control, and concretely, this proposal gives the PM SIG too much weight without a check.

Inherent in my proposals is an opinion that the the project is currently ad-hoc highly centralized, and should be formally more decentralized. This means more people from more companies granted a higher level of trust and empowerment. I grant that this will feels like a risk, but the reward will be a higher project velocity and more adaptability to future requirements.

This is the major lesson of micro-service architectures and high velocity organizations and we should move in this direction, not away from it.

Presently the PM group (as product management groups often are) is release-based and feature oriented. We must have a strong orientation to architectural improvement over the long haul. This group currently does not have the participation from the technical community. We have seen in recent years large open source projects go down the wrong path on this front.

This, as Joe points out, is the point where the project is the most susceptible to disruption from those without technical credentials and history on the project, and we need to protect the project from that with appropriate checks.

Project policy and process issues very much need to be separated from this group. Process efforts centered on product management teams generally err in one direction, process efforts run by developers alone generally err in the other. We need to find a place where some balance can be achieved.

If I were to extend the separation-of-powers concept to the SIGs, I would propose that every SIG have:

I believe conflating these roles will counter-productive.

A related lesson is that without debate is that the the high velocity organization MUST have great automated testing. Formalizing command-and-control organization is a very typical response to testing automation that has too many gaps.

Upon reflection of this point, this would indicate that the testing SIG should probably have some additional empowerment related to setting acceptable bars for releases.

In summary: We need to find the way towards more de-centralizations, transparency, and empowerment and away from centralized control hierarchies.

-Bob

thockin commented 7 years ago

On Fri, Mar 17, 2017 at 9:23 AM, Bob Wise notifications@github.com wrote:

@thockin : Three branches proposal is my concrete proposal for distributing project control, and concretely, this proposal gives the PM SIG too much weight without a check.

To be sure, my proposal here was somewhat off the cuff, especially with regards to PMG. I'm going to pause here and re-digest your proposal. OK, I am back.

Bob, I think we're about 84.7113% aligned. I de-emphasized what you call the Project Policy Board, probably because I am not sure I understand it, and I added the SIG-TLs. More on this below, after I talk to your whole message.

Inherent in my proposals is an opinion that the the project is currently ad-hoc highly centralized, and should be formally more decentralized. This means more people from more companies granted a higher level of trust and empowerment. I grant that this will feels like a risk, but the reward will be a higher project velocity and more adaptability to future requirements.

I'm not getting that from your proposal. You're endorsing "PMG" for for features / roadmap / product issues, as am I. You're endorsing "elders", as am I. You keep describing this as "more decentralized", but where is that effect in your proposal? Is the main thrust that you're divvying up what PMG currently does into 2 disjoint groups? I'm probably OK with that, but I do have a human concern - when you give a group of people an unbounded mandate and measure their "worth" by it, they are going to do things. Creating a group whose focus is "creating policies", we're going to get policies. How many policies do we want? We certainly need some, probably more than we have today, but does that warrant a full branch of governance?

This is the major lesson of micro-service architectures and high velocity organizations and we should move in this direction, not away from it.

The associated lesson is that microservice architectures encourage siloing, focusing on local optima, and general navel-gazing.

Presently the PM group (as product management groups often are) is release-based and feature oriented. We must have a strong orientation to architectural improvement over the long haul. This group currently does not have the participation from the technical community. We have seen in recent years large open source projects go down the wrong path on this front.

OK, ACK. We have been very product/feature focused as a project (rightly so, I think, but that eventually has to stabilize). What part of your proposal fixes this, though?

This, as Joe points out, is the point where the project is the most susceptible to disruption from those without technical credentials and history on the project, and we need to protect the project from that with appropriate checks.

Project policy and process issues very much need to be separated from this group. Process efforts centered on product management teams generally err in one direction, process efforts run by developers alone generally err in the other. We need to find a place where some balance can be achieved.

Doesn't this suggest that the process-related group is a "reconciliation group" between PMG and eng (what I called the SIG TLs), rather than a standing body?

If I were to extend the separation-of-powers concept to the SIGs, I would propose that every SIG have:

A rep from the PM group who attends all meetings and represents the conduit of feature-related information in both directions. Not control - communication and leadership. An organizer (the current model for the SIG lead) who ensures process items for the meetings are followed, especially the transparency of the proceedings, and represents process issues back to the policy board. Technical lead(s) who have the requisite project credentials and permissions and represent the council of elders.

Excellent, our alignment just went up. Can you clarify what "represent the council of elders" means in your mind? Is that a top-down model, where the N<=5 elders dictate where the project should go, and N<=20 SIG-TLs execute? Or is that a decentralized model where SIG-TLs decide where the project should go, and the elders adjudicate and approve?

I believe conflating these roles will counter-productive.

Sorry, I just want to clarify - conflating SIG-Lead, SIG-TL, and SIG-PM will be counter-productive? I agree.

A related lesson is that without debate is that the the high velocity organization MUST have great automated testing. Formalizing command-and-control organization is a very typical response to testing automation that has too many gaps.

Upon reflection of this point, this would indicate that the testing SIG should probably have some additional empowerment related to setting acceptable bars for releases.

I'm OK with that in broad strokes.

In summary: We need to find the way towards more de-centralizations, transparency, and empowerment and away from centralized control hierarchies.

PM group should be oriented towards roadmaps, communication, and leadership, not management and control. SIG testing needs greater empowerment to gate releases Architecture and technical standard setting need more formalization (council of elders). More engineers on the project need more empowerment.

So after reading this, I really do think we (you ad I, everyone else can catch up) are pretty close. I would describe it as:

Am I getting closer to what you're thinking about? If not, where am I missing?

jbeda commented 7 years ago

Some open questions that are unrelated to the main thread here as @bgrant0607 keeps telling me to put issues here:

smarterclayton commented 7 years ago

I'd appreciate if the specific criticism of API machinery was moved into its own discussion thread (probably on that sig's email group) and the folks who have concerns specifically describe them in detail and work with the SIG on those issues. I'm seeing references, but no attempt to resolve the concerns or be specific, which I don't think is in keeping with our community code of conduct.

EDIT: or for examples of project wide decisions - would be good to provide concrete examples and the specific concerns in an appropriate forum so we can reference them.

jbeda commented 7 years ago

I'm happy to move this stuff in to a SIG specific issue/document if we have one that I can put it in. Otherwise, Brian was asking me to pull everything in to this one issue as I was reviewing the governance.md PR that he has out.

As for issues -- don't want to get in to it here. But I find it encouraging that the discussions around external admission policy was submitted to the feature repo. These discussions have been going on for quite a while in the API machinery SIG even though it is a project wide impacting feature that deserves, IMO, wide attention.

smarterclayton commented 7 years ago

It was one of our committed 2017 features at the dev summit (along with TPR improvements, clients on the server): https://docs.google.com/presentation/d/1dFfN3_9VM4cRKknZB9_0wsM_1YLJToRTEx7dX6BoEhI/edit#slide=id.g18c1dcf7fb_3_431

I don't know how things can be more advertised than the Kubernetes community 2017 roadmap :)

jbeda commented 7 years ago

I'm not sure that it is worthwhile to go back and forth on a specific issue but, yes, it could have been better advertised. There was no feature issue for it until 2 days ago and there were no updates during the community meeting. As features like this hit major milestones (design proposed, design accepted, alpha) it would be helpful to checkpoint with the larger community.

sebgoa commented 7 years ago

We need to define the scope of this governance. Is this kubernetes/kubernetes? kubernetes/*? Some other subset? Any repo that goes in to the main release?

To me we should do it all in one go.

I understand there are established roles that have grown organically, but we can define a high level framework that covers the entire project. That's what I suggested in #351

Once you have a basic framework - as succint as possible- we can work on layering technical roles and decision making on top of that structure, using some/all existing roles.

bgrant0607 commented 7 years ago

Regarding membership lists: The governance.md draft does advocate checking in all membership lists, as suggested above: https://github.com/kubernetes/community/issues/402#issuecomment-287577041

bgrant0607 commented 7 years ago

Observation: If we cap the number of SIGs, we'll definitely need to formalize the notion of Working Groups, which are already sprouting up (e.g., the Resource Management Working Group). People want dedicated forums to work together on specific areas of interest. That's what spawned SIG Cluster Lifecycle initially, as well.

bgrant0607 commented 7 years ago

Buckets of areas:

bgrant0607 commented 7 years ago

Decision role identification framework aligned with existing project practices: https://stumblingabout.com/tag/oarp/

davidopp commented 7 years ago

I don't see a good reason to cap the number of SIGs, unless there are redundant discussions happening in different SIGs. But I haven't actually heard any complaints about that. I think the underlying complaint here is that SIGs are sometimes making cross-cutting decisions without getting broad participation from affected parties, many of whom may not be in the relevant SIG. We'd still need to address this even if we limited the number of SIGs (unless we reduced to one SIG). I think the solution there is better advertising when discussions about such topics are going to happen.

On a tangentially related note, I think there is a limit to how inclusive in-person meetings can be given the wide spread of timezones. On the one hand it is often much faster to make decisions in a meeting vs. using asynchronous comunication channels. On the other hand there will be some people left out no matter what time you hold the meeting. So if we set up a policy for how to handle cross-cutting decisions, I think it should have an asynchronous component not just meeting component.

bgrant0607 commented 7 years ago

Great example of a community-led initiative by @philips:

https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/kubernetes-dev/v_jgXtqMjeg/HsR0pbzKBwAJ https://github.com/kubernetes/community/pull/126

bgrant0607 commented 7 years ago

Whatever problems aren't solved by the initial draft should have assigned owners.

bgrant0607 commented 7 years ago

Proposal to allow ~anyone into the github org: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/kubernetes-wg-contribex/ia6tV0LNen8/IEakt5YYEwAJ

bgrant0607 commented 7 years ago

Followup from the first meeting (with links to notes and video): https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/kubernetes-dev/4e8WOnMvZC0/eZIvrFYlCAAJ

One of the first things that needs to be figured out is a decision categorization framework, so that the deciders for each category can be easily and unambiguously determined (to the extent that is possible). Examples of categories could be:

calebamiles commented 7 years ago

I thought that the Rust Language governance RFC was fairly interesting read. I also think that their general RFC framework is an interesting, if not slightly ambiguous, way to propose changes to Rust.

bgrant0607 commented 7 years ago

Thanks, @calebamiles. I'll take a look. I also thought the NodeJS governance was interesting, since they were also striving for a lightweight model:

https://github.com/nodejs/node/blob/master/GOVERNANCE.md

bgrant0607 commented 7 years ago

One issue that has come up in multiple threads that governance will need to address:

We have a number of horizontal SIGs/teams that span the entire project, such as:

Clearly these SIGs need to be able to make forward progress in these areas, but there has been discussion about how changes with project-wide impact should be vetted, communicated, and rolled out.

bgrant0607 commented 7 years ago

Many other SIGs work on areas that affect other SIGs, as well, such as scalability, scheduling, node, ...

I also want to reinforce a point by @spiffxp in another proposal: https://github.com/kubernetes/community/pull/422#issuecomment-284919213

Where there are SIGs covering an area, we need to work with those SIGs to improve. Where there isn't an appropriate SIG, we either need to create one or designate an existing one as the owner. We can't have parts of the project falling between the cracks and we can't undermine what structure we do have.

bgrant0607 commented 7 years ago

Another example: https://www.debian.org/devel/constitution

bgrant0607 commented 7 years ago

Interesting cautionary tale: http://asterisk.dynevor.org/xfree-forked.html

bgrant0607 commented 7 years ago

The Rust governance RFC that @calebamiles pointed out also has interesting parallels to the K8s SIG model (~ Rust subteam) as well as to the proposal process (~ Rust RFC).

calebamiles commented 7 years ago

I also really liked the Debian constitution, @bgrant0607. Specifically I like that all power flows from individual developers to roles of official leadership and that it is possible to recall members from official leadership roles although I would hope that the process for doing so would be exercised infrequently

countspongebob commented 7 years ago

Per discussion at the SIG PM meeting today, I'm proposing we consider changes rather than features, @jbeda has proposed calling these "efforts". Change control policy is a key governance issue, SIG PM requested I post the issue here.

https://github.com/kubernetes/features/issues/247

calebamiles commented 7 years ago

I've taken some notes on the aspects of some other governance models for OSS communities. I've also taken some notes on my thoughts on the taxonomy of problems presented by @bgrant0607 although no promises of of consistency of proposed solutions is guarenteed especialy with regard on preventing project capture by one or more corporate organizations.

cc: @philips, @thockin

bgrant0607 commented 7 years ago

Very constructive and helpful, @calebamiles. Thanks.

Know anyone at Debian who could answer questions, such as how they incentivize volunteers to work on the Front Desk?

bgrant0607 commented 7 years ago

More examples: http://gem5.org/Governance https://www.xenproject.org/governance.html

bgrant0607 commented 7 years ago

On lazy consensus:

Lazy consensus is very pragmatic, and we'll likely need to use that approach for some decision-making on the project in order to make forward progress. However, I am concerned about using the approach broadly, because it requires constant vigilance from the stakeholders. And, because voting/veto rights are not transferrable today, those stakeholders can never take vacation or at least never go offline.

Mitigations might include some combination of:

From @philips: I agree this is a problem along with the inverse issue of achieving the right to vote but never ceding or always relying on an alternate. Many foundation based projects have gone into deadlock in the long run this way. Tricky balance.

Other decision-making approaches we may take inspiration from and/or use in conjunction or in other contexts:

In context of meritocratic model: http://oss-watch.ac.uk/resources/meritocraticgovernancemodel

Some variant strategies:

Other decision-making advice: http://ctb.ku.edu/en/table-of-contents/leadership/leadership-functions/make-decisions/main

More thought/investigation needed.

idvoretskyi commented 7 years ago

Lazy consensus is a valuable form of voting; I would avoid skipping it completely, but we need to define types of questions that might be solved with the lazy consensus.

"Simple" questions may be solved with the lazy consensus; "complex" questions - should use more enhanced for of voting.

bgrant0607 commented 7 years ago

PMC reports could serve as inspiration for repo and/or SIG reports: http://www.apache.org/foundation/board/reporting

Even if we split the project into more repos, we couldn't entirely unify SIGs and repos due to the number of horizontal efforts.

bgrant0607 commented 7 years ago

More on nodejs:

https://nodejs.org/en/foundation/ https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951

13 working groups plus the core technical committee: https://github.com/nodejs/TSC/blob/master/WORKING_GROUPS.md https://github.com/nodejs/CTC/blob/master/WORKING_GROUPS.md

Almost 300 github org members and 100 repos: https://github.com/nodejs

"The Node.js project is organized into over a hundred repositories and a few dozen Working Groups. There are large variations in contribution policy between many of these components because each one has different constraints. "

"...in Node.js we’ve had to continually break off work into other, more specific, repositories just to keep the volume on a single repo manageable."

Project descriptions, categorized as core, dependent, adjacent: https://github.com/nodejs/TSC#tsc-scope

Project lifecycle: https://github.com/nodejs/TSC/blob/master/Project-Lifecycle.md

Interestingly, the CTC (https://github.com/nodejs/CTC) characterizes the TSC (https://github.com/nodejs/TSC) as non-technical.

Example meeting notes: https://github.com/nodejs/CTC/blob/master/meetings/2017-04-05.md

Proposal repo: https://github.com/nodejs/node-eps

Repo for support issues: https://github.com/nodejs/help/issues

TSC composition: https://github.com/nodejs/TSC/blob/master/TSC-Charter.md#section-4-establishment-of-the-tsc

Decision making is through a combination of Condorcet voting (elections) and lazy consensus seeking. LCS voting is triggered by call for vote + second, and requires a simple majority or super-majority to pass.

People making valuable contributions are called "collaborators", and commit access is as needed. A "maintainer" is a collaborator on the core project elected to represent it on the TSC.

WG governance: https://github.com/nodejs/TSC/blob/master/BasePolicies/Governance.md https://github.com/nodejs/TSC/blob/master/BasePolicies/Charter.md

Articles about creating the governance advisory board: https://www.ibm.com/blogs/cloud-computing/2014/10/node-js-takes-positive-step-towards-open-governance/ https://www.joyent.com/blog/node-js-advisory-board

bgrant0607 commented 7 years ago

Possible modified Lazy Consensus Seeking approach:

I don't see a need for the more complex voting scheme (+2, -0, -2, etc.).

I think allowing earlier calls for votes seems abuse-prone. Choosing a short period in order to accelerate a vote could, as well, but I think always using a long period would slow down decisions, and developing hard rules governing the period duration would be difficult, so encouraging the proposer to choose a reasonable period but allowing others to request extensions could provide some balance.

Allowing votes to be transferred addresses the "can't go anywhere" problem without delaying all progress when any voter is unavailable. We've seen this spring that assuring mutual availability of even a group as small as 5 people can be difficult.

Requiring a super-majority can encourage obstructionism, according to a number of sources.

mikeal commented 7 years ago

@bgrant0607 last week @dankohn invited me to speak to ContribX about how Node.js has managed all of this by, just trying to figure out the scheduling because I had a conflict during their meeting this week.

bgrant0607 commented 7 years ago

LLVM: http://llvm.org/foundation/documents/other/LLVMF%20Bylaws.pdf

bgrant0607 commented 7 years ago

@mikeal Would definitely appreciate it! I had a useful chat with Myles Borins at the OSLS a couple months ago. Nodejs looks to be of similar scale, encountered some of the same challenges, and shares similar goals (e.g., scaling the contributor base).