On 10/01/08 01:33, Alan Coopersmith wrote: > 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?
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. > 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? > Yes. That's my understanding. > 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. > 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. >> 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? > None. That's why I'm suggesting that we can do this now without waiting. Anyone want to lead this change? > 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. > 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 -- http://blogs.sun.com/jimgris/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/ogb-discuss/attachments/20081001/0a94d2dc/attachment.html>
