Project Lead

[tjfontaine]

Below is from an internal thread from the advisory board, included here to start the discussion.

Project Lead

@shammond2000

• like all organizations, there should be a leader. In this case, the leader is not a BD, but instead has the role of driving consensus.

@isaacs

I disagree about the need for a single "leader". In a complex technical project like Node, there will naturally be leaders in different areas, and these people will change over time.

The role of any "leader" then is really just to keep everyone moving forward. What's needed is a PM/facilitator person, who can also help coordinate everyone, including work being done on the build system, release engineering, documentation, and so on. (We discussed this a bit at the last JNAB meeting.) So far, Mikeal has been doing this job for Node Forward. He's very good at it, but he's also very busy, and I think we ultimately need a full-time person in this role.

It is important, I think, for the TC facilitator to not get a vote or be part of consensus. Otherwise, it's too tempting to (unwittingly) abuse their influence.

@Danese

I've discussed above how "tie-breaking" is handled at Apache (one reason it seems necessary to have a "leader" is to resolve disputes, but single leads at Apache are rare).

I think I disagree about the Coordinator function being necessarily non-voting, although perhaps I could be persuaded.

[mikeal]

A few things I should mention:

• Having a non-voting participant moderate has, in my opinion, been key to the success of the process thus far.
• TC meetings have other non-voting participants. See https://github.com/joyent/nodejs-advisory-board/pull/11/files#diff-898e7f1ceacb493c024554f5a7c87bdfR20
• I'm not the only person who has moderated the calls. @rvagg ran one meeting and another meeting that was all about build was basically run by him since he led that Agenda item which accounted for almost the entire agenda.
• In the discussions we've had so far about "releases" (I put this in quotes because we're basically just talking about tagging at a certain point so that we can chop up the work in the buckets and goals) the current thought is that the role of "release wrangler" should fall to different people on something of a rotation rather than always being the same person. This isn't just to avoid some kind of "new dictator" problem, it's also a good way for everyone to empathize with the person who has to ask everyone "are you done yet" and crack the whip from time to time.

The role of moderator has some implicit power in it. You set the Agenda, you follow up, you write the notes which become the result of any discussion or meeting. If people think that you have a particular agenda that conflicts with theirs it's easy to become hostile towards the moderator because you feel as though they have some power over you. A great way to difuse that is to pick a moderator who doesn't get a vote and, in effect, has less power than the participants in real terms.

[piscisaureus]

I would like the node project to have more direction. Right now it's just a giant free-for-all where everybody either takes random minor issues from an ever-growing issue list, or works on their own pet project. I expect a leader for node.js to:

• Make sure everyone is working toward the same goal
• Facilitate planning (release timelines) and decision making (roadmap)
• Stay in close contact with their team
• Monitor progress, identify roadblocks
• Communicate with the outside world about roadmap and planning

The leader/facilitator probably shouldn't be doing any of the following:

• Maintain CI / build automation
• Make releases
• Go heads down coding
• Act as a gatekeeper for feature requests
• Be unreachable for weeks
• Invent cool new roadmap items

[mikeal]

It might be a good idea to put a term limit on the moderator. It's the kind of job that can easily burn someone out without really noticing. I can think of a dozen great people in the community that could take on the role, we should use them.

[ijroth]

• Make sure everyone is working toward the same goal

A published roadmap would accomplish this. You don't need (nor I think want) a moderator to set the goal. If there is a moderator they would perhaps facilitate the consensus building, or ask people to step up to do so.

• Facilitate planning (release timelines) and decision making (roadmap)
• Monitor progress, identify roadblocks
• Communicate with the outside world about roadmap and planning

I don't see why these tasks have to be relegated to a moderator. Any community member should be able to do these and different people could take on different ones.

[piscisaureus]

• Make sure everyone is working toward the same goal

A published roadmap would accomplish this. You don't need (nor I think want) a moderator to set the goal. If there is a moderator they would perhaps facilitate the consensus building, or ask people to step up to do so.

The leader/facilitator should not set the goal, but should facilitate goal-setting and bring it up when needed.

• Facilitate planning (release timelines) and decision making (roadmap)
• Monitor progress, identify roadblocks
• Communicate with the outside world about roadmap and planning

I don't see why these tasks have to be relegated to a moderator. Any community member should be able to do these and different people could take on different ones.

I agree with that, it's not so much that I need to facilitator to do all this by her/himself, but it has to be done nonetheless. There's probably a larger discussion to be had about what roles we can identify in the TC; I believe that as much as we need programmers to look at pull requests and take them to the TC, we also need someone that puts "make a release plan" on the agenda and come up with strawman that's concrete enough so that the other TC members can have an opinion about it.

[k1tm]

I believe there is a PM role that needs to be filled, I believe there is a "Leader Role" to get the release organized and to work with the TC members to herd the cats, and I believe that the TC needs a process for appointing and replacing people as they come and go over time. So, here is why and maybe a little of how this works for others I work with….

Like all projects of a certain scope it is necessary to plan the work, monitor progress and get around roadblocks. Some of the keys to trust, consensus and a sense of community are to do it in the open, share the planning information before the decisions are made, consistently exercise the consensus process to set the scope for the release and then execute manageable chunks that get delivered (unless somebody just fails to hold up their end). This takes both a pm role and leadership to execute.

If the release cycles are short and reliable, then you take a few weeks to plan openly and then execute and repeat. This would greatly relieve the stress and allow others to share in the responsibility for execution. The TC could have a PM attached to it that handled the planning and execution tasks. The "leader" works the consensus model. He works to keep the less than useful feature or changes requests out of the hair of his team.

Things like maintaining the CI/Build infrastructure should be community tasks. Documentation, internationalization, etc.. should be community tasks. The leader should come to the supporters with needs and we should work to find solutions as a team. The TC has to surface those needs.

Most groups that start down this path have the first leader appointed by the host company, and then over time as the trust and execution flow happens, this role can transfer to others. This is not uncommon. The angst in the system currently is greatly reduced once execution happens to a plan. Most organizations create a process that allows for replacements of TC members. Some vote them in periodically, some appoint them until they wish to move on and then call for a vote. If the community is not getting what they need from their leaders they like to see a clean process and timing for change.

Net: Have a pm, have a leader, execute to an open plan in short dependable cycles, have a process for managing change of membership to the TC and Leader.

[totherik]

Net: Have a pm, have a leader, execute to an open plan in short dependable cycles, have a process for managing change of membership to the TC and Leader.

Totally agree. This is the major pain point Bert has raised already and the current TC proposal does not yet address it. In fact, I think the current proposal is less "governance" and more "personnel structure and process" (which is also just as necessary, as @k1tm mentioned). The overall framework needs to expand upon the TC proposal, identifying any additional roles (PM, leader) and clearly define the responsibilities of each role.

[shammond2000]

Agreed. The organizational structure was part of the original discussion
on governance on the AB but it got lost. Let's pull it back in.

On Thu, Nov 20, 2014 at 8:25 AM, Erik Toth notifications@github.com wrote:

Net: Have a pm, have a leader, execute to an open plan in short dependable
cycles, have a process for managing change of membership to the TC and
Leader.

Totally agree. This is the major pain point Bert has raised already and
the current TC proposal does not yet address it. In fact, I think the
current proposal is less "governance" and more "personnel structure and
process" (which is also just as necessary, as @k1tm
https://github.com/k1tm mentioned). The overall framework needs to
expand upon the TC proposal, identifying any additional roles (PM, leader)
and clearly defining the responsibilities of each role.

—
Reply to this email directly or view it on GitHub
#9 (comment)
.

Scott R. Hammond
President and CEO
Joyent, Inc.
(o)415-800-0872
(c)650-906-0740

[mikeal]

The leader/facilitator should not set the goal, but should facilitate goal-setting and bring it up when needed.

That's a great description, maybe that should make it in to the document.

[blakmatrix]

The leader/facilitator should not set the goal, but should facilitate goal-setting and bring it up when needed.

100% agree.