search

joyent / nodejs-advisory-board

Meeting Minutes and Working Group Discussions
http://nodeadvisoryboard.com
MIT License
158 stars 22 forks source link

Project Lead #9

Open tjfontaine opened 9 years ago

tjfontaine commented 9 years ago

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 commented 9 years ago

A few things I should mention:

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 commented 9 years ago

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:

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

mikeal commented 9 years ago

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 commented 9 years ago
  • 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 commented 9 years ago
  • 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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 https://github.com/joyent/nodejs-advisory-board/issues/9#issuecomment-63835121 .

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

mikeal commented 9 years ago

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 commented 9 years ago

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

100% agree.