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

[ghost]

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

[KidkArolis]

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

[wycats]

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

[olingern]

Not to dig an old issue up, but ...

I asked over in the v2 release who the governing body may or may not be ( it's currently unclear, to me at least ), and seeing as how yarn v2 is going to potentially replace yarn v1, I'm interested in how the governance works here?

[wwahammy]

Hey all, I don't know if this is addressed but it looks like PR's for known issues aren't being addressed on Yarn v1. Without knowing the governance model and who is in charge of what, it kind of looks like no one.

Is there an individual or group in charge of handling issues and PRs on Yarn?

[olingern]

@wwahammy I volunteered my time on a different issue, but it was kind of unclear what that looked like in practice. There was a bit of a rift between yarn 1 and yarn 2's release, so I thought it was best to let that settle.

In general, I think Yarn v1 should be maintenance only and no new features added. That's what Yarn v2 is for. So, I've pushed back pretty hard on PR's, like this one where a number of Microsoft employees wanted something that was easily accomplished outside of Yarn.

The number of duplicates, low quality issues, and un-mergable PR's is unmanageable for one, probably even two people. No idea on how to deal with that, other than to auto-close everything new.

Anyway, I'd be curious to see if @cpojer or @arcanis had any thoughts here. Governance / managing the project.