Governance

[sebmck]

@wycats has some thoughts around this.

[wycats]

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]

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?

[wycats]

@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]

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 😸.

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]

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]

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

[saper]

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)?