New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Governance #274

Open
kittens opened this Issue Sep 5, 2016 · 10 comments

Comments

Projects
None yet
9 participants
@kittens
Member

kittens commented Sep 5, 2016

@wycats has some thoughts around this.

@kittens kittens added this to the 1.0.0 - Open source milestone Sep 5, 2016

@wycats

This comment has been minimized.

Show comment
Hide comment
@wycats

wycats Sep 5, 2016

Member

I'd like to go with an RFC-based governance model (similar to Rust, Ember or Swift) that looks something like this:

  • new features go through a public RFC that describes the motivation for the change, a detailed implementation description, a description on how to document or teach the change (for kpm, that would roughly be focused around how it affected the usual workflows), any drawbacks or alternatives, and any open questions that should be addressed before merging.
  • the change is discussed until all of the relevant arguments have been debated and the arguments are starting to become repetitive (they "reach a steady state")
  • the RFC goes into "final comment period", allowing people who weren't paying close attention to every proposal to have a chance to weigh in with new arguments.
  • assuming no new arguments are presented, the RFC is merged by consensus of the core team and the feature is implemented.

All changes, regardless of their source, go through this process, giving active community members who aren't on the core team an opportunity to participate directly in the future direction of the project. (both because of proposals they submit and ones from the core team that they contribute to)

In Rust, we use the "No New Rationale" rule, which says that the decision to merge (or not merge) an RFC is based only on rationale that was presented and debated in public. This avoids accidents where the community feels blindsided by a decision.

Member

wycats commented Sep 5, 2016

I'd like to go with an RFC-based governance model (similar to Rust, Ember or Swift) that looks something like this:

  • new features go through a public RFC that describes the motivation for the change, a detailed implementation description, a description on how to document or teach the change (for kpm, that would roughly be focused around how it affected the usual workflows), any drawbacks or alternatives, and any open questions that should be addressed before merging.
  • the change is discussed until all of the relevant arguments have been debated and the arguments are starting to become repetitive (they "reach a steady state")
  • the RFC goes into "final comment period", allowing people who weren't paying close attention to every proposal to have a chance to weigh in with new arguments.
  • assuming no new arguments are presented, the RFC is merged by consensus of the core team and the feature is implemented.

All changes, regardless of their source, go through this process, giving active community members who aren't on the core team an opportunity to participate directly in the future direction of the project. (both because of proposals they submit and ones from the core team that they contribute to)

In Rust, we use the "No New Rationale" rule, which says that the decision to merge (or not merge) an RFC is based only on rationale that was presented and debated in public. This avoids accidents where the community feels blindsided by a decision.

@cpojer

This comment has been minimized.

Show comment
Hide comment
@cpojer

cpojer Sep 12, 2016

Member

I think it is indeed important that we get this right but I'd prefer to hold off on implementing such a system until we have grown contributors and until the project is successful. I expect that after the initial open source release and before the end of the year we'll want to move pretty quickly on this project and I recommend revisiting the RFC based model early next year. Does that sound like a good plan?

Member

cpojer commented Sep 12, 2016

I think it is indeed important that we get this right but I'd prefer to hold off on implementing such a system until we have grown contributors and until the project is successful. I expect that after the initial open source release and before the end of the year we'll want to move pretty quickly on this project and I recommend revisiting the RFC based model early next year. Does that sound like a good plan?

@cpojer cpojer removed this from the 1.0.0 - Open source milestone Sep 20, 2016

@kittens kittens self-assigned this Sep 20, 2016

@kittens kittens added the discussion label Sep 20, 2016

@wycats

This comment has been minimized.

Show comment
Hide comment
@wycats

wycats Sep 21, 2016

Member

@cpojer I think we can do a lightweight version of an RFC process when we open source.

The nice thing about leading with an RFC process is that it shows potential contributors, from the get-go, that they have a path to contributing even big ideas.

I don't want to do anything to compromise our ability to move quickly in the early days, and don't recommend that we start assuming that every change will go through the whole RFC process. That said, having a process in place lets us use it to model the kind of proposals we want to see, which should increase the quality of proposals from early users, and also give us the moral authority to ask early contributors to flesh out proposals more completely in order for us to take them seriously.

So I propose having the repo in place, and using it for targeted proposals where we really want feedback from early users, and hold off formalising anything more until early next year, as you said.

Member

wycats commented Sep 21, 2016

@cpojer I think we can do a lightweight version of an RFC process when we open source.

The nice thing about leading with an RFC process is that it shows potential contributors, from the get-go, that they have a path to contributing even big ideas.

I don't want to do anything to compromise our ability to move quickly in the early days, and don't recommend that we start assuming that every change will go through the whole RFC process. That said, having a process in place lets us use it to model the kind of proposals we want to see, which should increase the quality of proposals from early users, and also give us the moral authority to ask early contributors to flesh out proposals more completely in order for us to take them seriously.

So I propose having the repo in place, and using it for targeted proposals where we really want feedback from early users, and hold off formalising anything more until early next year, as you said.

@doug-wade

This comment has been minimized.

Show comment
Hide comment
@doug-wade

doug-wade Feb 1, 2017

I am curious to know where this stands in light of yarnpkg/rfcs#1 (comment). It sounds like the situation as it currently stands is "let's hold off on new major features while we figure out a sustainable governance model and stabilize the fb use case" which make a lot of sense to me, and I wholeheartedly support; however, as someone who would like to use yarn more extensively, I'd be curious to know how the roadmap will be handled, how rfcs make it through to features, and the like. Please don't feel harried or anything, just a gentle ping 😸.

doug-wade commented Feb 1, 2017

I am curious to know where this stands in light of yarnpkg/rfcs#1 (comment). It sounds like the situation as it currently stands is "let's hold off on new major features while we figure out a sustainable governance model and stabilize the fb use case" which make a lot of sense to me, and I wholeheartedly support; however, as someone who would like to use yarn more extensively, I'd be curious to know how the roadmap will be handled, how rfcs make it through to features, and the like. Please don't feel harried or anything, just a gentle ping 😸.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 6, 2017

In yarnpkg/rfcs#1, @cpojer mentioned the desire of the current yarn core team at Facebook to build a solid community driven core team. As a community member interested in the shared ownership of yarn, and involvement of the wider JavaScript community in its development and support, does Yarn publish a core team page similar to Ember - http://emberjs.com/team/

ghost commented Feb 6, 2017

In yarnpkg/rfcs#1, @cpojer mentioned the desire of the current yarn core team at Facebook to build a solid community driven core team. As a community member interested in the shared ownership of yarn, and involvement of the wider JavaScript community in its development and support, does Yarn publish a core team page similar to Ember - http://emberjs.com/team/

@Daniel15

This comment has been minimized.

Show comment
Hide comment
@Daniel15

Daniel15 Mar 8, 2017

Member

does Yarn publish a core team page

There's the core team page on GitHub (https://github.com/orgs/yarnpkg/teams/core), looks like the team is marked as private for some reason though. @cpojer @kittens is there a reason the yarnpkg/core team is private?

Of course, there's also the contributors page which shows people's contributions in terms of Git commits: https://github.com/yarnpkg/yarn/graphs/contributors

Member

Daniel15 commented Mar 8, 2017

does Yarn publish a core team page

There's the core team page on GitHub (https://github.com/orgs/yarnpkg/teams/core), looks like the team is marked as private for some reason though. @cpojer @kittens is there a reason the yarnpkg/core team is private?

Of course, there's also the contributors page which shows people's contributions in terms of Git commits: https://github.com/yarnpkg/yarn/graphs/contributors

@cpojer

This comment has been minimized.

Show comment
Hide comment
@cpojer

cpojer Mar 8, 2017

Member

I made some adjustments to the teams to reflect the current state and turned the core group visible.

Member

cpojer commented Mar 8, 2017

I made some adjustments to the teams to reflect the current state and turned the core group visible.

@saper

This comment has been minimized.

Show comment
Hide comment
@saper

saper Apr 12, 2017

I am not sure it works very well for https://github.com/libuv/leps

it kind of may discourage from hacking and exploring risky opportunities

also, should RFCs include working code (basics for the IETF work)?

saper commented Apr 12, 2017

I am not sure it works very well for https://github.com/libuv/leps

it kind of may discourage from hacking and exploring risky opportunities

also, should RFCs include working code (basics for the IETF work)?

@bestander bestander added the triaged label Apr 28, 2017

@BYK BYK added needs-discussion and removed cat-discussion labels Oct 27, 2017

@KidkArolis

This comment has been minimized.

Show comment
Hide comment
@KidkArolis

KidkArolis Jan 7, 2018

Contributor

Given there have been a bunch of RFCs implemented and accepted - should this issue be closed now?

Contributor

KidkArolis commented Jan 7, 2018

Given there have been a bunch of RFCs implemented and accepted - should this issue be closed now?

@wycats

This comment has been minimized.

Show comment
Hide comment
@wycats

wycats Jan 8, 2018

Member

@KidkArolis indeed! I'm psyched that this ended up being the Yarn governance ❤️

Member

wycats commented Jan 8, 2018

@KidkArolis indeed! I'm psyched that this ended up being the Yarn governance ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment