Thursday Nov 13, 2008
Tuesday Oct 07, 2008
By jimgris-Oracle on 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
By jimgris-Oracle on Sep 19, 2008
Here are some updates as of now:
Tuesday Sep 16, 2008
By jimgris-Oracle on Sep 16, 2008
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.
By jimgris-Oracle on Sep 16, 2008
Thursday Sep 11, 2008
By jimgris-Oracle on Sep 11, 2008
Friday Aug 29, 2008
By jimgris-Oracle on Aug 29, 2008
Wednesday Aug 27, 2008
By jimgris-Oracle on Aug 27, 2008
Wednesday Aug 06, 2008
By jimgris-Oracle on Aug 06, 2008
Friday Aug 01, 2008
By jimgris-Oracle on 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
By jimgris-Oracle on Jul 18, 2008
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, Glynn, and Simon.
Friday Jul 11, 2008
By jimgris-Oracle on Jul 11, 2008
Some previous blog posts on this issue are here and here.
Friday Jun 20, 2008
By jimgris-Oracle on Jun 20, 2008
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.
- Tokyo BarCamp 2010: Photos
- BarCamp Tokyo 2010: 4 Days Away
- Photos: Tokyo Make Meeting 05 2010
- Tokyo OpenSolaris Study Group: May 2010
- Tokyo OpenSolaris Study Group 2010.04
- OpenSolaris Night Seminar 041610
- Tokyo Linux User Group 041610
- Sun Japan
- Tokyo Linux User Group 041010
- OpenSolaris DTrace @ Yokohama Linux UG
No bookmarks in folder
- /Open Source
- /Project Management