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.
Thursday Nov 13, 2008
Tuesday Oct 07, 2008
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: http://blogs.sun.com/jimgris/tags/ogb.
Friday Sep 19, 2008
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 opensolairs.org 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.
In the coming months we'll be upgrading the opensolairs.org 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
The OGB met this morning. Here are my notes.
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.
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.
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
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
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
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
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 opensolaris.org 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
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 opensolaris.org 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 opensolaris.org infrastructure coming along will easily allow it,
and now we hope to adjust the governance to enable it as well.
Friday Jul 18, 2008
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
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, Michelle, Glynn, and Simon.
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.
- 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.
- 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.
- Participant: Someone who participates in the activities of a User Group.
- 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).
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, Michelle, Glynn, and Simon.
Friday Jul 11, 2008
Earlier this week the OGB voted to create a committee to specify the
roles and overall community reorganization we may attempt when the new
opensolaris.org 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.
Some previous blog posts on this issue are here and here.
Friday Jun 20, 2008
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 opensolaris.org 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.
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 opensolaris.org 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.
This blog copyright 2009 by jimgris
