io.js Working Groups

[mikeal]

Based on the informal process we've already undertaken I've written up a more formal documentation and process around the idea of "working groups" and attempted to charter the ones that are already up and running.

The high level goals are to ensure that we don't prematurely break work off in to subgroups and also to ensure that the projects have real autonomy.

Need feedback, especially from @chrisdickinson and @rvagg to make sure this accurately describes Streams and Build.

[goto-bus-stop]

There's a few duplicates in here

[chrisdickinson]

And a few folks that aren't members.

I'm not sure if we need to list members here, we should probably instead link to the appropriate repository and make maintaining a public membership list of some sort a responsibility of the WGs.

[mikeal]

Ya, the only reason this list is here is because the readable-stream README doesn't have one :) I pulled this from a GH issue.

[rvagg]

ya, remove the list, let @chrisdickinson manage the list on the README there

[chrisdickinson]

Hm, my feeling is that the TC should have final ruling on WG activities, but that in practice that prerogative won't be exercised often/at all.

[chrisdickinson]

I'll think on this more, but my initial reaction is: this looks good. I'd expect the TC to have final say over a WG's charter (including expanding, shrinking, or revoking it), but the WG itself is able to devolve its current responsibilities to subordinate WGs without TC approval. I am not sure if I like the minimum member count, or if that filter is best served by requiring that the formation of a WG has to get a member of the TC to "champion" it for an amount of time. My only other nit is that I'd like to start putting these files into doc/project or doc/meta folder and linking to them via a single top-level CONTRIBUTING.md or GOVERNANCE.md file.

[mikeal]

TC having final ruling.

IMO the WG should be truly autonomous. Granted, I'm thinking a little far ahead here, but the most successful approaches I've found elsewhere create assurances of autonomy and a formal relationship with the "parent" org. A good example is the jQuery Foundation's "right to leave" which ensures a project can exit without recourse if for any reason it disagrees with the foundation.

I don't think that the people taking on this kind of work should be beholden to the TC, or to any other group. If the TC recognizes that the work is important but that they don't want to take it on as part of the main project/repo then they should also trust them to function without interference. Developers have opinions, there's no way around it, and if you watch long enough you'll see developers at foundations and other orgs sticking their thumb in other people's projects for which they contribute little but dictation. This entire fork is the result of the people actually doing the work not having control over the project they're building, it seems hypocritical not to offer that same to projects under our umbrella :)

That said, the charter which outlines exactly what the TC is trusting the WG with needs to be approved by the TC. If that WG wants to change their charter and extend it to other responsibilities it would have to run it by the TC.

Here's a good example of the right balance: the streams WG has full control over readable-stream, they can take it any direction they see fit. They also recommend versions for inclusion in io.js but you'll notice that the final decision about which version to take in a release is not being moved from the TC to the WG.

I am not sure if I like the minimum member count, or if that filter is best served by requiring that the formation of a WG has to get a member of the TC to "champion" it for an amount of time.

I don't see a strong argument for segmenting governance in to a group without at least a few members. We can create repos at will, have hangout discussions, and take on any work in the io.js org without forming a WG. It's only when a sufficient number of people are clearly responsible for that work that we need a WG. For instance, I'm doing a bunch of evangelism work that is basically organized in a single Issue in the website until there are a sufficient number of people for a WG. I'm also doing a bunch of work in the roadmap repo and seeing what shape it takes before forming a formal WG around it.

I don't think it sends a good message to require a TC member to be involved, the hardest part of getting some of these spun up is making the contributors feel enabled to merge and move things forward without getting permission. Also, both build and website were created without a TC member (remember that Rod and myself aren't actually voting members).

[kesla]

Perhaps it would be good to newcomers (or people who just easily forget, like me) to make it a habit of writing out something like Technical Committee (TC) the first time we mention TC in docs?

[rvagg]

My initial reactions include:

This may be too prescriptive, we're not building a foundation here (yet) and io.js is all about just getting stuff done so I'd err on the side of more freedom with a back-stop (next point)

The lack of answerability to the TC concerns me here because we're talking about projects that are all about io.js. Some WGs will spin off on to separate concerns and may be best not to have oversight from the TC but so far they all need to be part of a combined effort. For example, maybe the website group start coming up with some whacky ideas for promoting io.js and messaging that diverges too far from what the contributors to iojs/io.js believe appropriate. It would be good to have some recourse for the WG to be corrected and brought back in line with the effort. Even more so with the build WG, it needs to be 100% in alignment with the main project for testing and releases.

I can imagine situations where more autonomy is appropriate however. readable-stream will need to have some coordination with core but that WG will end up having significantly greater expertise in this field than general iojs/io.js contributors and even the TC so they should be able to make autonomous(ish) decisions and then negotiate with core about how the code gets upstreamed. But again, there is a commitment to "Node.js compatibility" and streams is an obvious area for that to quickly diverge, what if the streams group decides to ditch the current API and go fully WHATWG streams?

I've been considering moving NAN to the iojs org and it would be a good candidate for a WG but so far it's had zero oversight outside its own team of collaborators and I don't think it'd be appropriate to bring in TC oversight there because it works well enough as is.

[mikeal]

@rvagg

RE: autonomy

I hear you, and maybe we do need some kind of recourse the TC can have over a WG, but whatever that is needs to be really clearly defined. If not then random TC members could jump in to WGs they have nothing to do with and start barking orders (this isn't something I'm making up, this happens at some foundations where board members will jump in and tell projects what to do). Sure, right now we're all in a very easy alignment, we've been doing this a few months, I'd be concerned if we weren't mostly on the same page :) But I'd like this stuff to have longevity.

Proposal: perhaps the only "recourse" available to the TC is to revoke the entire charter. If the TC feels they know better than the WG then they can take back responsibility for the work as well. This would encourage a better model of participation, the WG won't intentionally piss off the TC or go in crazy and unacceptable directions but the TC won't be barking orders unless they are prepared to take over all the work that the WG was doing.

[rvagg]

that sounds like a good compromise

[mikeal]

Ok, I've updated with everyones feedback. @chrisdickinson do you want to adjust the streams WG definition to fit the one you ratified today and then squash the branch down?

[chrisdickinson]

@mikeal I might ask @iojs/tc to quickly take a look at the proposed charter before squashing and merging.

[mikeal]

Ya, I think that we covered most of the WG concept but the TC should look through the existing WG charters and make sure they aren't over-reaching.

[piscisaureus]

I looked at it (as painful as reading markdown diffs is). LGTM.

On a tangential note:

• I always thought that the streams WG scope was limited to "userland" streams like steams1/2/3. For the more low-level details coordination with libuv is needed.
• From the CoC: "There is no need to address persons when explaining code (e.g. "When the developer". It's a nit, and not new, but I still don't really understand what the point of this rule is. And I violate the rule all the time (although I try to avoid making implications on the gender of "the developer").

[mikeal]

@piscisaureus the CoC is just copied directly from our current CoC. If we want to alter it we should log a different PR against the main CoC and if accepted we can copy it to here.

[piscisaureus]

@piscisaureus the CoC is just copied directly from our current CoC. If we want to alter it we should log a different PR against the main CoC and if accepted we can copy it to here.

It's a nit, and I don't really want to open the floodgates again...

[mikeal]

@piscisaureus I don't think it's meant to be something where when it happens there is some kind of disciplinary action against the offender, it's just there to mean "please try to avoid this and if it does happen and someone sends a patch we will accept it."

I routinely use the colloquial "you guys" when speaking to large crowds. Something I'm trying to do less of and can already avoid entirely in written form. I don't expect to be kicked out of any conferences for it but I am making an effort to remove it from my spoken vocabulary.

[piscisaureus]

I routinely use the colloquial "you guys" when speaking to large crowds. Something I'm trying to do less of and can already avoid entirely in written form. I don't expect to be kicked out of any conferences for it but I am making an effort to remove it from my spoken vocabulary.

Well, I can understand that, but what's wrong with this (from the libuv docs):

The user should therefore always be prepared to handle EAGAIN or equivalent when it attempts to read from or write to the fd.

What the CoC has to say about that:

There is no need to address persons when explaining code (e.g. "When the developer").

[mikeal]

@piscisaureus good point, maybe we can ask the people who wrote the original text for Rust what the thoughts there were. But we should do it in another thread :)

[rvagg]

removing tc-agenda label from this, minutes say that the agreement was to just fix up the outstanding items and merge, if this needs to be revisited could you please put the label back on @mikeal?

[chrisdickinson]

+1

[mikeal]

@chrisdickinson can you merge it then :)

[chrisdickinson]

Merged in 0a54b6a.

[snostorm]

Perhaps I'll migrate this to a new issue (as this is now merged) but in reviewing the charter it is possible more recent scope additions are missing for the website group:

• managing the io.js documentation build tools (docs themselves stay in core)
• social media / marketing
• general io.js evangelism efforts (empowering speakers, maintaining a list of interested speakers, PR)

In general the website WG has already agreed to take these on until a time when/if they can be broken up in to new WGs or sub-WGs. Regardless, we should formalize whether or not those responsibilities fall under the website WG or general TC for now.

[mikeal]

@snostorm yes, please send a PR :)