We (defined here as "Bonnie and Mark, with help from lots of smart people") are working on what I somewhat cynically call "scoping for success:" refining our definition of "open development" such that we are left with problems that are both tractable and appropriate for our pay grades.
Much less cynically, we've got good support all the way up our now-slightly-longer management chain, and this feels like the beginnings of progress. While that redefinition is evolving, we're also working on reducing some major dissatisfiers, and getting some quick hits out of the way. So after a couple of days of talking amongst ourselves (defined here as "Bonnie's team," both scm and otherwise, plus John Beck, David Marker, and David Comay), we came to the following as some high yield, short term activities: 1. Fix up bugs.opensolaris.org to allow greater participation by community members. By "greater participation," we include the ability to provide attachments, sign up for notifications, and add notes to already-existing (ie previously submitted) bugs. 2. Figure out, and then express concisely, policies and processes around use of bugs.opensolaris.org vs defect.opensolaris.org. And then work on the bugzilla instance as needed to facilitate such proper usage. 3. Investigate evolving the sponsor program, possibly in the direction of patch submission. Regardless of direction, escalate the need for rewarding Sun participants. Much of this conversation was relatively data free. We don't have a great deal of information to quantify what (dis)satisfies our community members, or about what's going on in the heads of other defect tracking stakeholders (like RPE or the CTO). So much of the rest of the week involved canvasing some folks in the trenches, and some that are nominally driving change. And it turns out we got this pretty close to correct, as a starting point. So in regards to above: 1. Bill Rushmore has the source code to bugs.opensolaris.org, and is actively investigating extensions as noted. And, oh yeah, bugster just made another incremental release, including the introduction of some more publicly-visible fields, so I believe that gets rolled in here. 2. We labor under NO false notions about item #1 being sufficient. It is merely necessary. Like rock n' roll, bugzilla will never die, we cannot decommission the bugzilla instance without utterly disenfranchising multiple opensolaris projects and communities. Ergo, Alan is looking at minimal changes to bring that instance into the Tonic embrace, and several of us are engaging other dts stakeholders to determine and enunciate usage. 1st corollary to 1+2: we know that we need bidirectional cross referencing capabilities between our two systems of record, and we know that we must avoid bidirectional bridging. Both are much easier with actual tools modifications, but we're not optimistic about gaining much traction there. 2nd corollary to 2: we're planning to define the appropriate way to handle a bugzilla bug in our process backend. Obvious tradeoffs between "move it to bugster at the last minute," as opposed to "allow internal webrti to reference bugzilla." 3rd corollary to 2: we're engaging Solaris/Bugster folks to help us align Bugster product/cat/subcat and Bugzilla product/component tuples. That's necessary as part of a clear, concise policy. 3. We're looking at running the sponsor program through an opensolaris project, and providing support for aggregated testing and process overhead on patches pushed to the project repository. Or we're looking at allowing more complete handoff off submissions at multiple points along the way, rather than contributor/sponsor working in lockstep for every step of the entire, tedious way. We don't know what it will look like, but we've got some ideas and welcome others. Explicitly, we're making OpenRTI a non-goal for the nonce, and deferring discussion of a gate move. (But not indefinitely, at least for the latter.) Explicitly, we're treating external advocacy as a separable problem, related to both WebRTI access and the form taken by the aforementioned sponsor process changes. So lots of vague info in this note, but watch this space for further conversation, and for a straw man on our first steps. Some of which will be SCM team tasks, and some of which won't. And, oh yeah, we (really the SCM folks) should sync up on tools work in progress and previously planned, because it needs to not be accidentally affected by a scramble to get other stuff in place. --Mark
