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

io.js Working Groups #599

Closed
wants to merge 3 commits into from
Closed

io.js Working Groups #599

wants to merge 3 commits into from

Conversation

mikeal
Copy link
Contributor

@mikeal mikeal commented Jan 24, 2015

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.

* @calvinmetcalf
* @sonewman
* @domenic
* @timgestson
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a few duplicates in here

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


The list of responsibilities should be specific. Once established these
responsibilities are no longer governed by the TC and therefor should
not be broad or subjective.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

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
Copy link
Contributor Author

mikeal commented Jan 25, 2015

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

@@ -0,0 +1,296 @@
# io.js Working Groups

io.js Working Groups are autonomous projects created by the TC.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

rvagg commented Jan 25, 2015

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
Copy link
Contributor Author

mikeal commented Jan 26, 2015

@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
Copy link
Member

rvagg commented Jan 26, 2015

that sounds like a good compromise

@mikeal
Copy link
Contributor Author

mikeal commented Jan 30, 2015

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
Copy link
Contributor

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

@mikeal
Copy link
Contributor Author

mikeal commented Jan 30, 2015

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
Copy link
Contributor

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
Copy link
Contributor Author

mikeal commented Jan 30, 2015

@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
Copy link
Contributor

@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
Copy link
Contributor Author

mikeal commented Jan 31, 2015

@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
Copy link
Contributor

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
Copy link
Contributor Author

mikeal commented Feb 1, 2015

@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
Copy link
Member

rvagg commented Feb 3, 2015

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?

@rvagg rvagg removed the tc-agenda label Feb 3, 2015
@chrisdickinson
Copy link
Contributor

+1

@mikeal
Copy link
Contributor Author

mikeal commented Feb 3, 2015

@chrisdickinson can you merge it then :)

chrisdickinson added a commit that referenced this pull request Feb 4, 2015
PR-URL: #599
Reviewed-By: Chris Dickinson <christopher.s.dickinson@gmail.com>
@chrisdickinson
Copy link
Contributor

Merged in 0a54b6a.

@snostorm
Copy link

snostorm commented Feb 5, 2015

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
Copy link
Contributor Author

mikeal commented Feb 5, 2015

@snostorm yes, please send a PR :)

@rvagg rvagg deleted the working-groups branch October 28, 2015 03:50
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

Successfully merging this pull request may close these issues.

8 participants