Thursday Nov 13, 2008

Draft Constitution on Genunix Wiki

I put the draft Constitution on the Genunix wiki the other day, and I added a bunch of updates as well. After a few weeks of list conversations, we'll now move to working on the wiki. What becomes of this draft will be voted on in the March 2009 election. Much work still to do. Feedback welcome. Blogs tagged OGB here.

Tuesday Oct 07, 2008

OpenSolaris Constitution: Drafting v2

We are starting to rewrite the OpenSolaris Constitution, and we`re looking for community input. I posted a really rough initial draft today by combining some of the OGB reorganization documents with some of the bits from the current Constitution. It`s hard to blend these documents, so I found myself deleting entire sections of current Constitution. I doubt we`ll be able to edit these docs together, so I`m advocating a total rewrite in a new voice (and a single voice). A new version of the Constitution will be approved at the March 2009 election. I keep track of everything I do on the OGB here at this tag:

Friday Sep 19, 2008

Reminder: 3 Key Lists for Website Upgrade

It's important for all leaders of OpenSolaris communities and projects to be on the following lists:
In the coming months we'll be upgrading the infrastructure and content and also going through a governance-based community reorganization. So, the Constitution will be updated, the website platform will be updated, and the content and site navigation will continue to be updated. There will be many discussions and testing phases and migrations, and all of these issues will be implemented primarily on these three lists. So please sign up and start monitoring. As things come together, we'll also post schedules or timelines in the Website project with pointers and instructions.

Here are some updates as of now:
Many of these discussions have been taking place for some time now, and there is much more background information in the archives of the three lists above.

Tuesday Sep 16, 2008

OGB Meeting 091508

The OGB met this morning. We had a good discussion about how to start implementing the community reorganization proposals we've been talking about and voting on recently. There are a few directions we can take, but I think we settled on doing a couple of things simultaneously. There's a lot to do. Basically, we have to do a better job documenting what we've done, communicating that information to the community, asking for feedback (more than we already have), writing and synchronizing transition plans, and implementing where we can even if parts will still be manual initially. We need to get people used to the idea that the community structure will change, the Constitution will change, the webapp will change, and some of the processes will change. The hope is that it will all change for the better, of course. Anyway, this  strategy seems like the best solution because there will be multiple times over the coming months when the infrastructure (webapp, wiki, etc) will have to be upgraded and tested by the community, and there will be a great deal of migrations going on that involve user data (we'll do that automatically internally) and web page content (which may be partially automated and partially manual but the community will be directly involved in that part). So, the implementation of the community reorganization is directly tied to the implementation of the new website platform we are building.

I've been happy with our progress lately because, well, we've actually been making progress now. Previously, we were stalled a bit. I don't particularly care how slow we go (slow is better in this situation), but what is critical is that we have consistent movement each month toward a goal. Momentum is necessary for any project to succeed, and we have some good movement now. I'm not a supporter of the weekly OGB meetings, though. I don't think they are necessary each and every week since the board is distributed around the world. It would make more sense if we were all on the same hallway. But when you have a community -- which is exactly what the OGB is -- you need to do more work on list and then meet to resolve issues. Scheduling and attending weekly meetings is extremely difficult if you don't live on the West coast of the United States. There is only one solution to this: work on list as the core platform for getting stuff done. The OGB is currently not working on list very much these days. This is a problem because it forces live meetings to get anything done and breaks flow of potential work each day. That's a bug. This is odd because we actually started out on list very actively. I think we need to get back to working on list, and then we can meet live every two weeks or so. We'll see. Making some really good progress, though. 

OpenSolaris Community Meeting Booking

Book your time to talk at the OpenSolaris Town Hall Community Meeting. Everyone will gather on Tues Sept 16th at 3 pm Pacific. There will be community updates as well as an executive briefing from Tim Cramer and Dan Roberts. The OGB will also do an update about the community reorg. I worte a little summary here.

Thursday Sep 11, 2008

Reorg Votes Continue

The OGB earlier today voted to approve the next two parts of the community simplification process -- Group Creation Process | Membership Process. The Groups & Roles Proposal was approved a couple of weeks ago. Next up will be a discussion about how we implement these proposals and reconcile them with the Constitution. There's no rush, really. As long as we are making steady progress in stages, we're fine. 

Friday Aug 29, 2008

Keeping Up, Staying Involved

I've been trying to update the various parts of the community in which I participate about the OGB community reorganization. This is a big deal we are embarking on, and the OGB has to be out there in the community educating people about the changes we are implementing on the community's behalf. I've been sending notes to opensolaris-announce, ogb-discuss, advocacy-discuss, and i18n-discuss. Here is the latest I sent tonight. The entire process is open, and all the documentation is on the OGB's site. Sign up to ogb-discuss to participate.

Wednesday Aug 27, 2008

Reorg and Simplification Progressing

The OGB's community reorganization and simplification process is progressing. See the roles/groups proposal here (approved), and the group creation process here (draft), and membership process here (draft). We are just picking off pieces and flushing them out on list and in meetings. Eventually, we'll have to bring all these documents together into one document and update the Constitution. OGB reorg tag on this blog right here.

Wednesday Aug 06, 2008

A Vote of Approval

On Monday the OGB voted to approve the first two parts of the draft community simplification document. I've been talking about this for quite a while. Now that this decision is made, our webapp development team can move on to finishing the applications that will not only make up the core of the new but will also support the SCM migration. Working on that team and the restructuring project will now also take up the vast majority of my time over the next few months. I'm looking forward to it. It will involve some engineering management, some content management, and an enormous amount of communications with the community. Lots of learning, too. Cool.

Friday Aug 01, 2008

Simplification: Moving a Proposal Forward

I'm trying to move the OGB's community simplification process forward. There are important infrastructure engineering projects that depend on some very basic decisions from the OGB. So I've been advocating breaking this process into many small decisions, rather than one large and complex one. We need to vote on Monday. We are out of time. Make a decision. Move to the next one.

I've expressed my frustration about all this in a few forums, but that's mostly my desire to just move faster. It's my default position on everything, actually. But I think we may now be getting closer to agreeing on a draft from which we can start. Here is the latest draft of the community simplification proposal. I say start because there is absolutely no way to simplify and reorganize the OpenSolaris community before the main ON gate has been moved outside and before the webapp infrastructure has been implemented. First, the movement of the gate outside brings with it a significant amount of infrastructure and process we've never had outside, and long with that comes a whole boat load of people as well. And second, the current webapp is not flexible enough to enable any reorganization. Instead, all three things need to occur -- and are occurring -- at the same time. There are some clear dependencies that need considering. By necessity, the two infrastructure implementations are happening in a phased way, so any community governance reorganization needs to follow that same model.

Also, the work on the new webapp has been based on the existing Constitution, but it fixes many of the obvious and well-known issues that have been discussed for years in the OpenSolaris community. This is very cool. We will have a remarkable amount of flexibility with the new site that we've never had before, so it only makes sense simplify governance by actually simplifying governance, so we don't inadvertently add too much layers and process before we need it. That's why I'm pushing to keep things as flat as possible and as simple as possible. We can always get more complex over time if we need to. It was a mistake to create governance before we needed it, so we shouldn't make the same mistake now by recreating governance before we need it in a genuine attempt to simplify what we already have. We should cut first. Then build back up. If we need to. Regardless, I will always argue for a flat, simple, approach.

Although we still have some bits to figure out regarding all of this, at least there is clear consensus for making the OpenSolaris User Groups their own collective group on the site. This is very good news. This means that the OSUGs will have top level exposure right along side Projects and Communities and any other meta groups we specify under the reorganization. Many of us have been wanting this for a long time. The new infrastructure coming along will easily allow it, and now we hope to adjust the governance to enable it as well.

Friday Jul 18, 2008

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.

Friday Jul 11, 2008

Roles for the Reorg

Earlier this week the OGB voted to create a committee to specify the roles and overall community reorganization we may attempt when the new webapp is implemented. We need the new webapp in place to do the reorg, but work on the webapp is dependent on the OGB specifying up front any changes in the current roles or organization. We've been discussing this for a couple of months now, and we all agree that we want to start small and make incremental changes as needed. So, after the meeting on Monday, I posted to ogb-discuss some of my thoughts about specific roles and an overall organization, and I tried to focus on an extreme simplification of three roles and three collectives. I knew full well that that was too simple, but I wanted to start from there and work up as needed. There was some discussion during the week, and I just posted an update to the proposal with Alan's and John's comments. It's just a start to keep the process moving.

Some previous blog posts on this issue are here and here.

Friday Jun 20, 2008

From Reorg to Simplification

The OGB is continuing the discussion around how to simplify the structure and function of the OpenSolaris community. Simon Phipps posted an updated version of his initial draft that the OGB discussed a few weeks ago -- Simplifying OpenSolaris Governance. What I like about this is that it offers the ability for people to group themselves so that structure doesn't get in the way of function, and then over time we can see what actually works rather than attempting to specify all possibilities up front. Some of the discussion we've had on list is way too confusing for the issue of simplification.

We are fortunate that Alan Burlison has built enough flexibility into the authentication application for future evolution. So, the OGB should just concern itself with defining the collective groups (Projects, Communities, SIGs, UGs, etc) and also the main governance-oriented roles (Contributor, Core Contributor, Facilitator, Member, etc) and leave the rest to the new edge applications that will access the authentication application. The current webapp is monolithic in design, and we are replacing that with a distributed and modular design. The real intelligence and flexibility here is at the edge where apps will give people access to resources to get work done.

Just making these changes that Simon suggests (which we all discussed in two OGB meetings) is a big enough deal. We should start small and move and adjust in small and consistent steps along the way. The OGB has absolutely zero resources, so it really has no other choice. It has to carve out reasonable chunks of things to do and then engage other groups to do the actual work. As a result, big and comprehensive reorgs will get bogged down and ultimately fail.


« July 2016

No bookmarks in folder