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
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
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
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.
Social groups gathered around issues or technologies. All
roles except Participant have edit rights to web pages in
- Participant: Someone who participates in the activities of the
- 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
Development groups gathered around code repositories and
integration tools. All roles except Participant have edit rights
to web pages in
- Participant: Someone who participates in the activities of a
- 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.
Groups of users gathered around issues or technologies in
specific geography. All roles except Participant have edit rights
to web pages in
their User Group.
Group Creation Process
- Participant: Someone who participates in the activities of a User
- Coordinator: A participant who leads and coordinates the
activities of a User Group.
- 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.
- 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
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
, and Simon