Skip to content
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

The Road Forward #11

Open
junosuarez opened this issue Oct 21, 2014 · 4 comments
Open

The Road Forward #11

junosuarez opened this issue Oct 21, 2014 · 4 comments

Comments

@junosuarez
Copy link

Kudos to all involved for creating this repo in the open.

I know there has been (much) more discussion involved in this process which has not been made public. It's quite possible that there are good reasons for this, as has been hinted to me privately, but it's hard to tell. There has been no public recap or summary of the current position, and no clear announcement of the path forward. I think this could be a good place to clear up some essential issues related to the future of node instead of bikeshedding about microlevel policies like versioning schemes.

Now, I care a lot about the node community. It's currently the principle source of my livelihood and I count a good number of people that I've met from various conferences, meetups, and community events as close friends. I think it would be helpful to have more public insight on a path forward.

Technical Committee As I understand it, community-owned node (under whatever name) would be led by a Technical Committee to oversee development and day-to-day operations of the code base and architecture. Could someone articulate the makeup, decision making process, and governance of this body?

Scope Will the scope or spirit of the project change? Historically, node code has been a fairly small surface area, with most development pushed out into userland (npmland) modules. I have seen discussion here about bringing some popular modules into the node-forward namespace. Does this indicate an increased scope?

Community Contributions In addition to the core Technical Committee members, what other roles will exist? Specifically, how will the project do outreach to new users and new contributors, and to what extent? This is something that some other major open source projects do a good job of, and that node could improve on. Recognizing that everyone can contribute in some way and creating opportunities for more casual contribution -- including in non-code related ways, such as documentation -- shows that a project respects its community and aspires to be inclusive and accessible.

Timeline Finally, I think what's on everyone's minds is the question of when. For lack of other knowledge or communication, there is very little to go on but rumors and speculation. Joyent's node hasn't had a major release in a year and a half and has no definitive timeline (or realistic estimate) for node 0.12.

I'm assuming that everyone is operating with the best intentions and wants what is best for node and for the community of developers, contributors, and users. I want this too. A good start would be reducing uncertainty through frank, clear, public communication.

@mikeal
Copy link
Member

mikeal commented Oct 21, 2014

@jden

First off, apologies that some of this stuff isn't public and easily accessible. There are two major reasons for this. The first, and this is my fault as much as anyone's, is that we figured there would be a good deal of time to get some work done and iron out the messaging before anyone noticed. That was clearly a mistake. The second, which I unfortunately can't get in to the details of, is that a repository where we were doing a lot of this work and messaging was forced to go private. That is temporary, and should be resolved within the next three weeks.

Technical Committee / Governance / Contribution Policy

This is well documented in the other repo, which is unfortunately temporarily private. The TC and its rules were iterated on by a lot of people before being codified. The new contribution policy, which is far more liberal than prior policies and closer to @rvagg's "OPEN open source" I added in a PR which was discussed, iterated on, and eventually accepted. I've added the relevant sections of the CONTRIBUTING file from the other repo below. Keep in mind that this is a living document and we encourage iteration and participation.

Also, a quick note on "consensus seeking." Many changes have landed, some of them a little controversial, but we've actually never had to go to a vote. Either an easy consensus is reached with a few changes or the change is more or less abandoned. The voting is there as an "if all else fails" mechanism so the group can't ever be locked up by a single individual.

Here it all is:

Governance

This repository (node-forward/node) is jointly governed by a technical
committee, commonly referred to as the "TC."

Initial membership invitations to the TC were given to individuals who had
been active contributors to Node. Current membership is:

Fedor Indutny (@indutny)
Trevor Norris (@trevnorris)
Ben Noordhuis (@bnoordhuis)
Isaac Z. Schlueter (@isaacs)
Nathan Rajlich (@TooTallNate)
Bert Belder (@piscisaureus)

Invitations were also given to TJ Fontaine (@tjfontaine) and
Alexis Campailla (@orangemocha) who have not accepted but are
still invited to participate without accepting a role or
officially endorsing this effort.

Additionally the TC may invite persons or representatives from certain projects
to participate in a non-voting capacity. These invitees currently are:

  • A representative from build chosen
    by that project.

The TC has final authority over this project including:

  • Project governance and process
  • Contribution policy
  • GitHub repository hosting

The TC can change its governance model if they deem it necessary. The current
governance rules are:

  • Consensus Seeking
  • Motions with voting when consensus cannot be reached.
  • Quorum of 2/3 (66%), simple definite majority wins.
  • No more than 1/3 (34%) of the TC membership can be affiliated with the same
    employer.

TC Meetings

The TC meets weekly on a Google hangout. The meeting is run by a designated
moderator, currently Mikeal Rogers (@mikeal). Each meeting should be
published to Youtube.

Contributor Policy

Individuals making significant and valuable contributions are given
commit-access to the project. These individuals are identified by the TC and
discussed during the weekly TC meeting.

If you make a significant contribution and are not considered for commit-access
log an issue and it will be brought up in the next TC meeting.

Internal pull-requests to solicit feedback are required for any other
non-trivial contribution but left to the discretion of the contributor.

For significant changes wait a full 48 hours (72 hours if it spans a weekend)
before merging so that active contributors who are distributed throughout the
world have a chance to weigh in.

Controversial changes and very significant changes should not be merged
until they have been discussed by the TC which will make any final decisions.

TC members nominate contributors to be added to the TC which the TC will vote
on. They can nominate any individual during any meeting.

Code of Conduct

This Code of Conduct is adapted from Rust's wonderful CoC.

  • We are committed to providing a friendly, safe and welcoming environment for
    all, regardless of gender, sexual orientation, disability, ethnicity, religion,
    or similar personal characteristic.
  • Please avoid using overtly sexual nicknames or other nicknames that might
    detract from a friendly, safe and welcoming environment for all.
  • Please be kind and courteous. There's no need to be mean or rude.
  • Respect that people have differences of opinion and that every design or
    implementation choice carries a trade-off and numerous costs. There is seldom
    a right answer.
  • Please keep unstructured critique to a minimum. If you have solid ideas you
    want to experiment with, make a fork and see how it works.
  • We will exclude you from interaction if you insult, demean or harass anyone.
    That is not welcome behaviour. We interpret the term "harassment" as including
    the definition in the Citizen Code of Conduct;
    if you have any lack of clarity about what might be included in that concept,
    please read their definition. In particular, we don't tolerate behavior that
    excludes people in socially marginalized groups.
  • Private harassment is also unacceptable. No matter who you are, if you feel
    you have been or are being harassed or made uncomfortable by a community
    member, please contact one of the channel ops or any of the TC members
    immediately with a capture (log, photo, email) of the harassment if possible.
    Whether you're a regular contributor or a newcomer, we care about making this
    community a safe place for you and we've got your back.
  • Likewise any spamming, trolling, flaming, baiting or other attention-stealing
    behaviour is not welcome.
  • Avoid the use of personal pronouns in code comments or documentation. There
    is no need to address persons when explaining code (e.g. "When the developer")

Scope

If you look at the discussions happening in the roadmap you can already tell that tolerance for expanding the scope of core is incredibly low. The members of the TC along with, from what I can tell, the community that coalesces around core are far more comfortable breaking things out of core than adding them in.

Community Contributions

The technical view of scope I just explained goes past just the technical level and in to the rest of the community activities. What has been happening so far is that people passionate about any non-core-code activity are given a space to do that work and given ownership of it, completely separated from the TC. In the case of welcome it is entirely separated, in the case of build it's governance and contribution policies are owned by that group while certain affordances are given to participate in the TC because core will actually become dependent on that work.

I would describe the Node Forward philosophy as "distributed ownership and responsibility." People who are doing the work should own it and anyone looking to take on responsibility for something should be given ownership as soon as they show they are engaged. There isn't any one single rule for all of this, and I believe strongly that each project should own it's governance and contribution policy rather than having it dictated to it by the TC or anyone else, but you can already see the philosophy present in the work that is currently public.

One last note on "distributed ownership." By this I do not mean that projects should be broken in to parts and given a single "owner." That might be "distributed" but it isn't "shared" and what we want to encourage is a shared sense of responsibility. What I mean by "distributed ownership" is that everyone is a participant and should be given opportunity and respect for their work. People who share a sense of responsibility for something will work hard and love what they do, but when they grow a sense of responsibility without ownership the relationship between the participants and the "owners" will grow contentious and hostile. That is what we are seeking to avoid.

Timeline

As you may have seen Joyent is taking steps to work with the community on some of these issues. Everyone would prefer to move forward with Joyent as a participant, but that takes time. I won't speculate on when they will make any final decisions, nor can I speculate on when they will do a release of Node, all I can say is that Node Forward is a place where the community is taking responsibility for stuff like this and that once it stabilizes transparency around releases and timeline are a high priority, that's why we have the roadmap repo to gather feedback from the community at large and try to work it in to the future process.

@junosuarez
Copy link
Author

@mikeal thank you for the prompt reply. I'd love to hear from other stakeholders in this process as well, specifically from Joyent. Unfortunately, there's no such public forum where I could ask questions of Joyent that is likely to get such a reply. If there were, some of the things I would ask, in addition to the above:

  • Is Joyent cooperating with node's move into a foundation?
  • What concrete actions has Joyent taken to improve diversity in node's development?
  • How will Joyent demonstrate its support for node in the interest of the community over its own particular interests? Short of that, how does Joyent plan to show continued alignment between its own interests and those of the broader community?

@mikeal
Copy link
Member

mikeal commented Oct 21, 2014

@jden it was reported in the press, although Joyent hasn't officially announced yet, that they are creating an "Advisory Board" that will take up these topics. Have a little patience, Joyent will surely make this board public soon and others will share their thoughts on the board at that time. It won't help for people to share their opinions and speculations before Joyent has even had a chance to announce this themselves.

I will also say that your very directed questions at Joyent aren't really all that helpful. Even if Joyent had a sufficient answer for you that wouldn't solve the real problem, which is that in the current structure all of the responsibility for these problems rests on Joyent's shoulders rather than the community. Rather than take shots at Joyent or call them out on Node's issues we should take responsibility for these issues ourselves. That's what Node Forward is, a way to take responsibility for these problem rather than just yell at/about Joyent.

I'll answer your questions as if they were directed at the community rather than Joyent.

  • What concrete actions has the community taken to improve diversity in node's development?

As noted in my previous reply the project being run under the TC has adopted a Code of Conduct, which is a first step but certainly not a last one.

  • How will the community demonstrate its support for node in the interest of the community over its own particular interests? Short of that, how does the community plan to show continued alignment between its own interests and those of the broader community?

Two things are already happening. The first is that putting Node under the control of a broader spectrum of people, with open and inclusive governance, reduces the influence of any single actor.

But, this still leaves us with a disparity in the kind of skills related to working on core as opposed to using core. The background of core engineers is always going to differ from a typical user so it's important to find new and inventive ways that we can gather feedback and priorities from the community at large and work them in to the long term roadmap for Node. This is the motivation behind the roadmap repository and there are some good conversations happening there. Again, this is a first step, and certainly not the last, but it is a step in the right direction that should bring in wider participation.

@darrenderidder
Copy link

I'm really glad to see this initiative, especially @bnoordhuis back in the saddle and @isaacs and @mikeal getting on board, too. A guy from our local meetup mentioned he'd been working with Joyent on the advisory board representing [a major corporation], and although it's too early to judge, the way they went about it covertly didn't exactly inspire a great deal of confidence. Great to see a community led initiative. Kudos for the effort everyone!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants