governance: Create teams / working groups

[rvagg]

We currently have a build team that I expect to grow further as we get more momentum.

We're also in the process of building a streams team: nodejs/readable-stream#97

I've also proposed a more formal website team be formed: nodejs/readable-stream#97

We now have a shared iojs calendar (see #230) and it would be great if we could fill that up with Hangouts On Air happening for each of these teams. Additionally, the governance structure allows for TC meetings to invite additional collaborators in and we have that happening for the build team so it would be great to have a non-TC representative from streams and ditto for the website; perhaps not every meeting but regularly.

Each of these teams needs a good facilitator to make it happen. Currently I think the website could do with someone who is both interested in the area and has good skills in facilitation--not being the boss or even leader, just making stuff happen and greasing the wheels.

[mikeal]

So far we've had the one group, build, and it seems to be going quite well. It sounds like you think one of the keys is having a good facilitator and being tapped in to the TC meetings have been key to its success. I'd also say that being autonomous, having its own repo and making decisions daily without bringing everything to the TC, has also been key.

IMO, we should add up all these things that we think have been working and turn that in to the policy for teams/working groups. I've done a bunch of research on how other foundations and projects structure this but I think it's going to be a lot better if we just learn what works for our community and iterate.

Do we have any suggestions for facilitators in streams or the website?

[mikeal]

Also, I think a designer should be the facilitator on the website. That would help to keep things moving and it's possible that the decision making structures we have for code don't work for design driven work and I'd like the facilitator to be able to challenge that.

[thefoxis]

Hey ho, chiming in with my two cents :)

So historically what I've noticed on the front-end/design side in open source projects (not everywhere but seen it enough times) might get quite derailed, mostly to lack of consensus of collaborators and lack of designated owner. I think that with the right structure (== decision maker(s)) projects are growing steadily because along with ownership people take responsibility.

With regards to design/front-end teams I'd suggest designating an owner and another one or two designers helping out, depending on the amount of help that will be needed. One person is totally fine but then it's a single point of failure if you need quick changes (people don't have to necessarily be very responsive as you might need them to be) and work always can get delegated. Also when you empower less open source savvy designers/front-end devs they will be happy to help, learn from more seasoned contributors and get guideance. Which is again why there's a need for a "leader".

I hope I'm making sense, it's late here :)

The website is built from content and then adds visuals on top so that means wrangling copy or at least overseeing it delivery as well. I'm also game for helping to some extent.

[rvagg]

I'm using the term Facilitator intentionally to push it away from a strong-leader model and more towards collaboration. We don't really need the natural, charismatic, self-confident leader-types who easily demand a following simply by their presence. We need people who want to lead by empowering others and handing off responsibility—doing themselves out of the "leadership" job.

During spin-up phase for greenfield sub-projects we're probably going to need someone to put in the work to create an initial implementation, or a mock, or straw man, or whatever you want to call it. I'm doing this now with the build efforts. But the more I can publish code, scripts and documentation about how everything works the faster I can get it to a place where others can step in and begin taking responsibility and ownership of the project.

With the streams project we have something a little different because we have existing code so we don't need an initial spin-up. What we need to do is:

1. find a group of people who can logically be initial team members (I've started off using a list of people who have contributed to readable-stream as a way to do that); and
2. figure out how we can work together and who fits into what slot.

For now I'm happy simply saying that @chrisdickinson and myself are "facilitators" of that project as we nurture it into something more self-sustaining, run by a group that feels they have enough authority to make decisions for their project as long as it fits within the broader io.js effort. I'm assuming that Chris and myself will be involved in that project for more than the short-term but let's not make too many assumptions about the long-term structure of the project and its leadership.

I was hoping that we'd have an obvious candidate put their hand up to begin corralling a team to start make some decisions and drop some code but so far that hasn't happened, despite initial interest when this was node-forward (there is an existing "Website" team in the GitHub org that's dormant).

My initial suggestions for how we should encourage these sub-projects be conducted are:

• Regular, public meetings, advertised, calendared, broadcast and recorded (once a week is probably a bit too much for sub-projects)
• Connection to the TC, either by a TC member being directly involved and being able to represent that group or by having a group facilitator attend TC meetings and be able to participate in everything but voting
• Aim for:
  • Broad transparency and accountability
  • Ownership and decision making power for the group taking responsibility and doing the work
  • Autonomy, to reinforce the decision making powers of the group while being ultimately accountable to the TC

I think the governance docs in #233 would probably fit just as comfortably within a sub-project as they do here.

[snostorm]

@rvagg (for the sake of others finding this thread) I think for the website discussion you intended to link to nodejs/iojs.org#19

[mikeal]

First website working group meeting is scheduled https://doodle.com/nzkegz5mk3k5ucpd#admin

[tylergaw]

I just started poking around the project and am interested in contributing in the design department. @thefoxis's comment is right on. I was just asking questions about a design owner in IRC. Is there room for that on this project? (not sure if this is the correct issue for this question)

[snostorm]

@tylergaw I'd say any general design/website discussions are best moved over to https://github.com/iojs/website at this point. (Even the topic of an IRC channel for just the team has already been an opened Issue there -- nodejs/iojs.org#61.)

We're planning the first website team meeting for Monday -- nodejs/iojs.org#59 -- if you're able to join us. The topics of ownership, general realms of responsibilities, etc. do need to be discussed while we also utilize that face-to-face to discuss our strengths and interests a little more.

The website "team" (as an official concept) came together fairly late compared to the general io.js efforts. Technically no more than 13 days ago, when this ticket was opened :)

For example, my brief time on the repo has mostly been focussed on helping to get the site "good enough" in the days preceding v1.0.0 and helping to merge/implement some tweaks which came in with the influx of new users.

[tylergaw]

Thanks @snostorm. I'll put further questions there.

[mikeal]

We've just formalized the governance on the website team and are will eventually need to spin out an evangelism team. I'd like to get some input on how the streams group is going and merge some of what we've learned in website, streams and build in to a generally agreed upon "way to do working groups." /cc @chrisdickinson @rvagg

[Fishrock123]

#599

[chrisdickinson]

Closing this – seems to be resolved since #599 was merged.