Cut the Bureaucracy, Cut the Hierarchy

I'd like for the OGB's community simplification effort to be successful. We all want that. But I'm not sure why we are finding this so difficult to move faster. We talk about it intensely in conference calls, and then we drop it for weeks at a time. We chat on lists, and then the lists go quiet. I'm getting frustrated. We are not working together. We are talking at each other, not with each other. Consistent movement in small steps is critical for building momentum on any project. Without that movement, agreement is difficult and that undermines implemention. Also, to simplify anything you have let go. You have to trust that the bureaucratic structures you have in place may not actually be holding things together at all. It's ok to cut. It's ok to cut to the absolute minimum and build structure only if it's needed and only when it's needed.

On ogb-discuss I have offered a simple operational structure based on three categories: Communities, Projects, User Groups. Within each of those three categories there can be many instances of those groups. They can create themselves easily, they can organize and run themselves any way they want, and they can associate with whoever they want. Operations are their business, so they ought to know that better than any centralized authority. They'll have only a few operational roles to contend with, and if people in those groups want to apply for Membership status (voting rights), they can go to the OGB Membership Committee when it's formed (the Membership interaction between groups and the OGB needs to be specified). Or they can ignore Membership entirely if they are not interested in community-wide voting issues.

This is very simple plan. It pushes governance to the back, it pulls development to the front, it decouples governance from operations, and it cuts the bureaucracy and hierarchy. Here's an outline:

Constitutional Term Changes and Deletions
  • Group replaces Community Group to describe all collectives.
  • Groups are Communities, Projects, and User Groups.
  • Core Contributor is removed.
  • Facilitator is removed.
  • Emeritus Contributor is removed.
Communities: Social groups gathered around issues or technologies. All roles except Participant have edit rights to web pages in their Community.
  • Participant: Someone who participates in the activities of the Community.
  • Contributor: A Participant who has been acknowledged by the Community as having substantively contributed towards accomplishing the goals of that Community.
  • Leader: A Contributor elected by a Community to lead the Community.
Projects: Development groups gathered around code repositories and integration tools. All roles except Participant have edit rights to web pages in their Project.
  • Participant: Someone who participates in the activities of a Project.
  • Committer: A Participant who has been acknowledged by the Project as having substantively contributed towards accomplishing the goals of that Project and who has commit rights to any code repositories owned by the Project.
  • Leader: A Committer elected by a Project to lead a Project.
User Groups: Groups of users gathered around issues or technologies in a specific geography. All roles except Participant have edit rights to web pages in their User Group.
  • Participant: Someone who participates in the activities of a User Group.
  • Coordinator: A participant who leads and coordinates the activities of a User Group.
Group Creation Process
  • Groups can associate with each other for purposes of collaboration, but development Projects are no longer sponsored by Community Groups. As a result, the new Group creation process can be simplified because governance is decoupled from operations and there is no need for CC voting for Projects. If people want infrastructure so they can do some work, they can send mail to a Group creation alias with a request and if it's not rejected in a week it's automatically created.
Membership Process
  • If Groups want their participants to be involved in community-wide voting then each Group will have to follow the OGB Membership Committee's specification (which is yet to be defined).
Earlier drafts here and here.

Please note: This is not meant to be the reorg. It's meant to be the start of a reorg that will emerge over time as the new infrastructure is implemented, as we move to open development, and as we experiment with simple operational and Membership structures. All we have to do right now is specify three things from an operational perspective: (1) group categories, (2) roles within each group, (3) and relationships (if any) between the groups. That's it. From that point, the infrastructure engineering team can finish implementing the new webapp, and the OGB can then move on to communicating with the community about these issues as well as specifying the Membership process.

Simon summarized some of our early conversations beautifully. But I think a few of us are interpreting those initial conversations differently. I'm clearly at the extreme edge of simplicity, and I'm there quite intentionally. I just don't see the need for much process here at all. We already have enough. It's time to cut. I also think I'm pretty consistent with the original intent of the simplification process. We'll see. There are many proposals now, and they live on lists, in bug databases, in blogs, and on wikis. Here are the basic proposals from Jim, John, Glynn, and Simon.
Comments:

Excellent! So when can we have this!

Posted by Ghee on July 18, 2008 at 11:20 AM JST #

hey ... well, we'll have to see if I can get some consensus for it. :) So far, no specific plan is being favored.

Posted by Jim Grisanzio on July 18, 2008 at 05:21 PM JST #

I'd simplify this further. I'd merge Participant with Contributor/Committer and merge Co-ordinator with Leader.

The very fact that Participants are around, means that they are contributing (somewhat different to those that use the technology, but we never hear from them). I'd suggest that we have Leader and Contributor roles only.

Leader has the ability to make decisions about the direction of a given project and has the respect of their peers to be in that position of responsibility and authority. Only Leaders can elevate Contributors to that level, to share the responsibilities.

Contributor can have a number of 'attributes' - commit status, web editing power, ... as their contributions are recognized.

In many ways, this now starts to look like what I wrote in my blog. You've kept the idea of Communities, and I've suggested calling them SIGs. I'm fine with either.

Posted by Glynn Foster on July 18, 2008 at 06:57 PM JST #

How does Linus do this kind of thing? His systems seem to work pretty well.

Posted by Kevin Hutchinson on July 19, 2008 at 11:21 PM JST #

hey, Glynn. I'm glad I'm close to yours. :) I wanted fewer roles initially in earlier drafts, but Alan convinced me I was too simple. I do think we need a Participant as an entry level, but I agree we can easily merge Coordinator and Leader. Not sure about Contributor and Committer. And I can go either way on SIGs/Communities, too. We'll have to talk about it. I'm less concerned about the specifics of a few roles as I am about keeping things simple and flat. I really don't want a hierarchical community system for OpenSolaris.

Posted by Jim Grisanzio on July 21, 2008 at 02:16 PM JST #

Kevin ... I'm not sure about the details of what Linus does. However, there are some big differences here. Linus is dealing primarily with kernel development, and we are trying to map out a meta-community governance system that involves much more than the kernel but doesn't really specify the details of kernel development. In other words, I really want to lay out a general structure into which the OpenSolaris engineers can build out there own development methodologies. I honestly don't think development is an OGB matter -- as long as our development methodologies are consistent with our overall governance model.

Posted by Jim Grisanzio on July 21, 2008 at 02:23 PM JST #

Post a Comment:
Comments are closed for this entry.
About


Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Bookmarks

No bookmarks in folder