Posts:
3,835
From:
JP
Registered:
4/6/05
|
|
|
|
[ogb-discuss] Simplification/Reorganization Issues
Posted:
Sep 30, 2008 2:42 AM
|
|
hey ... below is an outline of some of the issues I think we'll
face in the next six months as we implement the new community
organization we are working on. It's not complete by a long shot, but
it's a start and I intentionally kept it small to initiate the
conversation on list. I also recommend a specific course of action at
the end.
Reorganization & Simplification: Current Status
Status Changes to Current Groups
- As the infrastructure team works on the new opensolaris.org
website, they need to know
what existing groups will be changing status when the new
community organization and website are implemented. For instance, I
already know
of 72 Projects that will migrate to become User Groups, so I'll work
that part and
communicate with them and get that info to the infrastructure team. But
are there any other Communities that will become Projects? Or Projects
that will become Communities? The team will need to know this so we can
make the necessary changes in the application to accommodate those
migrations. I don't have a hard deadline for this right now, but we
should have this decision by the end of November if possible. If there
are changes to that rough time period, I'll let you know.
2009 Election Education
- The OGB's simplification/reorg is basically re-writing major
sections
of the Constitution that cover roles/groups, project creation,
and membership. These changes have clear dependencies that will
affect our intent to start implementing now:
- The community has to vote on these changes, and
- The infrastructure is not in place to support the bulk of the
changes.
- I realize the OGB voted to temporarily ignore the current
Constitution in order to fix it, but we still have to be mindful of the
scale of changes we are proposing. We shouldn't go too far without
making sure we have enough community participation, and we ought to
test our assumptions as well. We need to make sure we have this
consensus because the infrastructure team is doing website work based
on our decisions. I actually don't think we are that far away since
we've been discussing this in the open for many months now. I just
think it's the OGB's responsibility to do an education campaign as we
prepare well for the next election since that will involve voting on a
new Constitution as well as a new board.
Infrastructure
- The new site will be rolled out in stages and in parallel to the
current site for testing, updating, and, of course, migrations. Nothing
surprising here. We've
already had parts of the authentication application out for a couple of
rounds of testing, and we'll continue more of these releases this fall
and into the new year. The issues around these tests and other existing
infrastructure issues will determine
when we can have the final live site with the new community structure
and wiki. There will be a series of migrations (content, data, users,
etc), and some of that will be done by the team and some will be done
by the community. We are looking into building some tools to facilitate
the content migrations, but it's difficult to determine how long the
content migrations will take even with tools. Migrating the UGs to
projects manually took 3 months, and the scale we are talking about for
the entire site is obviously very much larger.
- We will look at automating the membership process that Simon/Alan
were talking about on list after the election and after the core
infrastructure pieces are in place.
- We can not make major changes to the poll application until after
the majority of the site is implemented, so we'll have to use the
current poll application to run the next election. That means that all
the current roles and associated groups will remain in place until
after the next election. Once the new OGB is in place and the community
has approved the new Constitution and the new site is functioning
properly, we can rebuild the
poll application to account for the new organization and the 2010
election. Using the existing poll application for the 2009 election
will not
affect the election, per say, but it will enable us to focus on
finishing core infrastructure projects first and it will enable the
community to approve the changes in the Constitution.
Recommendation
We should not try to implement all parts of the simplification/reorg
before the 2009 election and before the website can support everything.
We are only talking about 6 months till the end of our term with a
major holiday in the middle, so breaking it up into a few steps seems
wise. We have time to finish this if we plan properly and work
consistently. Trying to do it all now will only cause confusion and
distraction. But we can easily start
with these two items:
- Project Creation Process: The current process is manual and
involves members of the infrastructure team. As we implement the new
manual process, we'll have to communicate with the entire community and
with
the infrastructure team, we'll have to update website documents and
instructions to support the change, and we'll have to form any OGB
committee (if needed) as well. In the process of doing all this, we'll
have ample opportunity to characterize this change as one part of the
entire reorg. That community-wide education and communication is
necessary. And by
starting out changing one part first, it will help us to figure out our
own
process as we implement other parts in the future. We need a test case,
in other words.
- So, we need one person to lead this change. Volunteers?
- Rewrite the Constitution: I doubt we'll be able to simply
cut/paste the changes we've made into the current Constitution and have
it make sense. I think we are looking at a re-write. But that's fine
since we have time and we need that time to do this work. Also, this
should not take any longer than a few months since we have more focus
and agreement now on the board, and the community wants a simpler
structure. The new Constitution should be shorter and simpler as a
result. But we do have some writing and communication to do
to make sure that when voting time comes we have not forgotten
something important. If something is broken, we need to fix it now. Not
in March of 2000.
- So, we need one person to lead the re-writing effort. If there
are no objections, I'd like to volunteer to lead this part.
How about starting there? We can add more if we have the opportunity
to do so, but for now this seems like a reasonable place to start. If
we wanted to start with the new membership process as well, we could
add that to the mix, but we'd have to do so under the old roles -- in
other words, a Core
Contributor = a Member. Then the roles are consolidated under the new
system later. I'm fine with doing this, but I feel strongly that we
ought to bite off one thing at a time so we don't cause to much
confusion and get bogged down. I'd rather have slow and consistent
movement rather than risk stagnation by attempting to do too much too
soon. I think implementing the new project creation process and
rewriting the Constitution can be done in parallel, but another
implementation should wait until we are confident the first one went
well.
That's my pitch.
Jim
<pre class="moz-signature" cols="72">--
http://blogs.sun.com/jimgris/
</pre>
|
|
|
Posts:
1,218
From:
Registered:
3/9/05
|
|
|
|
Re: [ogb-discuss] Simplification/Reorganization Issues
Posted:
Sep 30, 2008 4:14 AM
in response to: jimgris
|
|
Jim Grisanzio wrote:
> *Infrastructure*
>
> * The new site will be rolled out in stages and in parallel to the
> current site for testing, updating, and, of course, migrations.
> Nothing surprising here. We've already had parts of the
> authentication application out for a couple of rounds of testing,
> and we'll continue more of these releases this fall and into the
> new year. The issues around these tests and other existing
> infrastructure issues will determine when we can have the final
> live site with the new community structure and wiki. There will be
> a series of migrations (content, data, users, etc), and some of
> that will be done by the team and some will be done by the
> community. We are looking into building some tools to facilitate
> the content migrations, but it's difficult to determine how long
> the content migrations will take even with tools. Migrating the
> UGs to projects manually took 3 months, and the scale we are
> talking about for the entire site is obviously very much larger.
The intention is to do several dummy runs of migrating the membership
data from the current database into the auth application, with
validation and tweaking after each run. As well as testing the auth
application this will allow us to make sure the resulting structures are
correct before we start moving the content. As we anticipate moving the
content will be a substantial amount of effort, we want to make sure
that the structures we move it to are correct before we start.
--
Alan Burlison
--
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
Posts:
5,504
From:
US
Registered:
3/9/05
|
|
|
|
Re: [ogb-discuss] Simplification/Reorganization Issues
Posted:
Sep 30, 2008 9:33 AM
in response to: jimgris
|
|
Jim Grisanzio wrote:
> *
> Status Changes to Current Groups*
>
> * As the infrastructure team works on the new opensolaris.org
> website, they need to know what existing groups will be changing
> status when the new community organization and website are
> implemented. For instance, I already know of 72 Projects that will
> migrate to become User Groups, so I'll work that part and
> communicate with them and get that info to the infrastructure
> team. But are there any other Communities that will become
> Projects? Or Projects that will become Communities?
Why would a community or project want to change to the other? In the old
system, only communities could initiate new projects or grant voting rights
in OGB elections, but now anyone can initiate a project, and both projects
and communities can grant voting rights. The current webapp restricts
source code repos to projects - will the new webapp continue that restriction?
Will there be any other differences between a project & a community in the
new webapp?
If so, consolidations like ON & X which are currently communities may want
to become projects to host their own gates instead of having most of their
work done in child projects like ONNV & FOX.
> 1. Project Creation Process: The current process is manual and
> involves members of the infrastructure team. As we implement the
> new manual process, we'll have to communicate with the entire
> community and with the infrastructure team, we'll have to update
> website documents and instructions to support the change, and
> we'll have to form any OGB committee (if needed) as well. In the
> process of doing all this, we'll have ample opportunity to
> characterize this change as one part of the entire reorg. That
> community-wide education and communication is necessary. And by
> starting out changing one part first, it will help us to figure
> out our own process as we implement other parts in the future. We
> need a test case, in other words.
I'm not sure I understand the infrastructure implications you're talking
about here, probably because I'm not one of the few people who creates
projects. The change we approved is that, from the user side, community
members request projects by filing bugs in bugzilla instead of sending
mail to a sponsoring community - where are the webapp changes in that?
Other than the bugzilla category setup, the changes I see to implement
that would be all around updating site content that documents the processes
and user education, informing them that:
1) To start a project, the process is now go to defect.os.o and file a bug
as described at:
http://www.genunix.org/wiki/index.php/OGB_2008/010_group_creation#Creation_Process
No sponsoring community is needed any more. (We'll probably want a more
user-friendly/focused instruction page instead of a link to the actual
policy wiki page, but the steps are there for now.)
2) The "Projects endorsed by this Community" and "Communities endorsing this
Projects" link in the web app, are still, like they've always been, just ways
for communities to highlight related projects, and have no connection to
governance or official sponsorship in any way.
3) Until the new membership process is rolled out, project contributors who
want voting rights in OGB elections need to request contributor status from
either a related community or the OGB for membership-at-large status.
--
-Alan Coopersmith- alan dot coopersmith at sun dot com
Sun Microsystems, Inc. - X Window System Engineering
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
Posts:
3,835
From:
JP
Registered:
4/6/05
|
|
|
|
Re: [ogb-discuss] Simplification/Reorganization Issues
Posted:
Oct 1, 2008 12:57 AM
in response to: alanc
|
|
On 10/01/08 01:33, Alan Coopersmith wrote:
<pre wrap="">Jim Grisanzio wrote:
</pre>
<pre wrap="">*
Status Changes to Current Groups*
* As the infrastructure team works on the new opensolaris.org
website, they need to know what existing groups will be changing
status when the new community organization and website are
implemented. For instance, I already know of 72 Projects that will
migrate to become User Groups, so I'll work that part and
communicate with them and get that info to the infrastructure
team. But are there any other Communities that will become
Projects? Or Projects that will become Communities?
</pre>
<pre wrap=""><!---->
Why would a community or project want to change to the other? </pre>
</blockquote>
<br>
Well, the option is there. We had talked about actively reorging the
community earlier -- making some Communities into Projects, etc. I
don't recommend this, personally, but if someone wants to change (such
as the UGs) than we should know now. <br>
<br>
<br>
<blockquote cite="mid:48E254BF dot 3000302 at sun dot com" type="cite">
<pre wrap="">In the old
system, only communities could initiate new projects or grant voting rights
in OGB elections, but now anyone can initiate a project, and both projects
and communities can grant voting rights. The current webapp restricts
source code repos to projects - will the new webapp continue that restriction?
</pre>
</blockquote>
<br>
Yes. That's my understanding. <br>
<br>
<blockquote cite="mid:48E254BF dot 3000302 at sun dot com" type="cite">
<pre wrap="">Will there be any other differences between a project & a community in the
new webapp?
If so, consolidations like ON & X which are currently communities may want
to become projects to host their own gates instead of having most of their
work done in child projects like ONNV & FOX.
</pre>
</blockquote>
<br>
That's fine. But also keep in mind that Communities can stay
Communities for the purposes of continuing their social structure if
that's what they want. Then people in those Communities can spin off
related Projects to do code-related work. They don't /have/ to switch. <br>
<br>
<br>
<blockquote cite="mid:48E254BF dot 3000302 at sun dot com" type="cite">
<blockquote type="cite">
<pre wrap=""> 1. Project Creation Process: The current process is manual and
involves members of the infrastructure team. As we implement the
new manual process, we'll have to communicate with the entire
community and with the infrastructure team, we'll have to update
website documents and instructions to support the change, and
we'll have to form any OGB committee (if needed) as well. In the
process of doing all this, we'll have ample opportunity to
characterize this change as one part of the entire reorg. That
community-wide education and communication is necessary. And by
starting out changing one part first, it will help us to figure
out our own process as we implement other parts in the future. We
need a test case, in other words.
</pre>
</blockquote>
<pre wrap=""><!---->
I'm not sure I understand the infrastructure implications you're talking
about here, probably because I'm not one of the few people who creates
projects. The change we approved is that, from the user side, community
members request projects by filing bugs in bugzilla instead of sending
mail to a sponsoring community - where are the webapp changes in that?
</pre>
None. That's why I'm suggesting that we can do this now without
waiting. Anyone want to lead this change?
<pre wrap="">Other than the bugzilla category setup, the changes I see to implement
that would be all around updating site content that documents the processes
and user education, informing them that:
1) To start a project, the process is now go to defect.os.o and file a bug
as described at:
http://www.genunix.org/wiki/index.php/OGB_2008/010_group_creation#Creation_Process
No sponsoring community is needed any more. (We'll probably want a more
user-friendly/focused instruction page instead of a link to the actual
policy wiki page, but the steps are there for now.)
2) The "Projects endorsed by this Community" and "Communities endorsing this
Projects" link in the web app, are still, like they've always been, just ways
for communities to highlight related projects, and have no connection to
governance or official sponsorship in any way.
3) Until the new membership process is rolled out, project contributors who
want voting rights in OGB elections need to request contributor status from
either a related community or the OGB for membership-at-large status.
</pre>
Good point on #3. Once we create projects under the new process we'll
potentially have new members coming our way as well. We should probably
begin forming the OGB committees necessary to do the project and
membership parts of the reorg. I had proposed one at a time, but it's
probably more likely that we'll have to do them at the same time. If
so, we'll need a lead for the membership change as well.
Jim
<pre class="moz-signature" cols="72">--
http://blogs.sun.com/jimgris/
</pre>
|
|
|
|
|
Posts:
3,835
From:
JP
Registered:
4/6/05
|
|
|
|
|
|
Posts:
3,835
From:
JP
Registered:
4/6/05
|
|
|
|
Re: [ogb-discuss] Simplification/Reorganization Issues
Posted:
Oct 7, 2008 2:27 AM
in response to: jimgris
|
|
On 09/30/08 18:42, Jim Grisanzio wrote:
<snip>
> *Recommendation*
>
> We should not try to implement all parts of the simplification/reorg
> before the 2009 election and before the website can support
> everything. We are only talking about 6 months till the end of our
> term with a major holiday in the middle, so breaking it up into a few
> steps seems wise. We have time to finish this if we plan properly and
> work consistently. Trying to do it all now will only cause confusion
> and distraction. But we can easily start with these two items:
>
> 1. Project Creation Process: The current process is manual and
> involves members of the infrastructure team. As we implement the
> new manual process, we'll have to communicate with the entire
> community and with the infrastructure team, we'll have to update
> website documents and instructions to support the change, and
> we'll have to form any OGB committee (if needed) as well. In the
> process of doing all this, we'll have ample opportunity to
> characterize this change as one part of the entire reorg. That
> community-wide education and communication is necessary. And by
> starting out changing one part first, it will help us to figure
> out our own process as we implement other parts in the future.
> We need a test case, in other words.
>
> * So, we need one person to lead this change. Volunteers?
>
Any takers to lead this part?
> *
>
>
>
> 1. Rewrite the Constitution: I doubt we'll be able to simply
> cut/paste the changes we've made into the current Constitution
> and have it make sense. I think we are looking at a re-write.
> But that's fine since we have time and we need that time to do
> this work. Also, this should not take any longer than a few
> months since we have more focus and agreement now on the board,
> and the community wants a simpler structure. The new
> Constitution should be shorter and simpler as a result. But we
> do have some writing and communication to do to make sure that
> when voting time comes we have not forgotten something
> important. If something is broken, we need to fix it now. Not in
> March of 2000.
>
> * So, we need one person to lead the re-writing effort. If
> there are no objections, I'd like to volunteer to lead
> this part.
>
I'm working this now.
Jim
--
http://blogs.sun.com/jimgris/
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
