John Plocher wrote: [replies inline]
> > > Opening the ARC process - A Proposal > > Goal: The existing ARC process and its OpenSolaris bound > projects and artifacts needs to be both observable > and usable by external members of the OpenSolaris > community. > > Tasks: > > Task 1: Publish content of selected historical ARC cases > Iterate as requested. > > Done. "some" material from the following cases > has been manually collected, redacted, folded and > mutilated: > > 1991/031/ 1992/059/ 1993/226/ 1999/289/ > 1991/061/ 1999/645/ > > 2001/313/ 2004/471/ 2005/220/ 2006/030/ > 2001/679/ 2004/472/ 2005/378/ 2006/062/ > 2002/240/ 2004/532/ 2005/441/ 2006/082/ > 2003/172/ 2004/620/ 2005/485/ 2006/134/ > 2003/687/ 2004/652/ 2005/711/ 2006/153/ > 2003/690/ 2004/770/ 2006/163/ > 2006/269/ > 2006/307/ > 2006/369/ > > This effort has shown us that it is extremely labor > intensive to manually publish archived materials. > > Task 2: Publish synopsises of historical ARC cases > > Need to decide what the synopsis should contain > (name, casenumber, date, status) and what cases > to expose (all, open, how to differentiate?) I don't think differentiating open cases will be easy. Also this would have to be re-done whenever other consolidations open themselves up. That said, there's several ARCs that seem to be hardware or otherwise related, that could perhaps be trimmed as unlikely to ever open to that degree (though those cases maybe meaningful despite that?) > as Glynn Foster wrote: > > While it's certainly encouraging ... to see > > detailed listings like - > > > > http://www.opensolaris.org/os/community/arc/caselog/testbed/ > > The various pages (1991, 1992... 2006) under this > testbed are my current attempt at this, trying to > balance the desire for "as much info as possible" > against the scalability constraints brought on by > "having over 5000 archived ARC cases". > > We are still working with Derek to figure out how to > present this much information without causing the website > to blow out the left hand nav structure on every ARC > community page. While I don't know about the guts of the web infrastructure, there's no real need to link cases in that menu. If you're viewing one case, you're unlikely to need to use the menu to navigate further (I'd assume any referenced cases would be linked within the body), and if you're not viewing a specific case, the chances are you're at the index already. > The current "simple pages" will replace the existing > "TBD" pages under arc/caselog/yyyy this week. > > Task 3: Publish content of the 240-ish ARC cases that > have integrated into OpenSolaris-ON and are referenced > by the ONNV Flagday pages. Also include the content > from the above manually produced pages so we don't regress. > > This is the other part of the effort - Danek has > identified about 240 ARC cases that have put back > into OpenSolaris. As such, we have more latitude > about the information we can publish about them. > At a minimum, I am trying to publish timeline > and contact information about each case with the > option for the various project teams to self-cleanup > their materials (see above link) so the publishing > script can auto update the opensolaris arc community > arc case web pages. > > This also pushes us into the nav bar explosion problem. I would expect other materials from the case being viewed to be linked in the menu, but in the absence of the Giant List of Cases being there as well, would that still pose a problem? > Task 4: Create a set of aliases and SAC infrastructure > that will allow participation in ARC reviews by > internal and external contributers. > > This is the real goal - as Glynn and Rich (and others) said, > > > are we getting to a point where we can substitute > > psarc/lsarc at sun.com for arc[-discu...@opensolaris.org? > > This is where I need help coming up with a plan that is > complete enough to be doable in the next month without > being so grandiose or disruptive that it fails. > > The following is an incomplete list of what I think needs > to be done from where we are today. It tries to balance the > following disjoint goals: > > o The need to keep the existing (Sun internal) ARC process > functioning smoothly for all the non-opensolaris things > that Sun does, > > o The desire to have a smooth transition from internal-only > to shared parallel processes to completely external ARC > processes (with a focus on getting to the 2nd stage) > > o The difficulty of creating automation *on* the opensolaris > site itself, and > > o The requirement to not violate Sun's internal network > security policies. > > > A. We need a way to communicate that ties into the > existing automated ARC tool infrastructure. This > includes a bunch of convenience aliases that are > backed by custom mail filters that direct the mail > based on case numbers found in the Subject line. > Create a new set of these aliases with -EXT at sun.com > to comply with Sun's net security policy. > Populate rosters with existing PSARC > members, interns, licensees and interest, > as well as arc-discuss at opensolaris.org > NetAdmin needs to allow 'postings to these > aliases from the Internet'. Need to figure out > how to manage SPAM and interactions with the > jive forums. A couple of things: Is arc-discuss really the right alias to land these on? I would think separate aliases under the ARC community for the various ARCs could be better, if the equivalents of the main <arc>@sun.com aliases are part of this, I certainly think separate aliases would be better. Given separate aliases for the mail above, I think hooking Jive to them in a read-only fashion would be best. I don't think it's unreasonable to expect anyone involved in ARC related communication to subscribe to the aliases (taking care of one spam problem). The other seems to be mostly taken care of by disallowing posts from non-subscribers. (which maybe rather heavy handed, but given the discussion on website-discuss regarding allowing anyone subscribed to any @opensolaris.org list to post to any other, would get better) > > B. We need a way for the community to initiate > fasttracks and full review projects. > Create one-pager-ext at sun.com that filters > incoming onepager templates and tags them > with a "contents are open source" tag > and sends on to SAC's existing onepager > processing toolchain. Modify the rest of said > toolchain to know about "open" cases and the > OS.o connection. And similar for fasttracks, I guess? > Worry about the architecture of what is being done > so that other open projects that are not part of > opensolaris can still tie into this open ARC > infrastructure. > > C. We need to make OS.o the host for all > these new OpenSolaris ARC related aliases. > Create NEWPROJECT at OpenSolaris.org that > points to one-pager-EXT at sun (pick a > better name?) If NEWPROJECT isn't a placeholder, Yes, I'd pick a better name :), though I have no idea what that would be. It's too suggestive of (opensolaris.org) Project's, I think. > Create PSARC-EXT (etc)@OpenSolaris.org, > have them point to the @Sun versions > > Create a set of interest aliases (agendas, > opinions, new cases) and cogitate about how > to tie into some sort of RSS scheme... > > D. Today, an approved ARC cases draft opinion gets > reviewed by the ARC that reviewed the case, and then > is peer reviewed by all the extended ARC membership. > This email-only exercise is called "sac-review". > > We need to figure out the logistics and > mechanics of doing sac-review of an "open" > case without running afoul of the "mail going > outside of Sun" net security restrictions. > > E. Figure out if/how we want to deploy > the per-case email logging feature out > on OS.o. Though the flow of mail between all the aliases isn't clear to me, assuming actual discussion mail flows back to an alias on opensolaris.org, why don't the mailman or jive archives satisfy this? -- Rich
