OGB Elections: Proper Positioning
By alanc on Mar 11, 2007
I haven't had a chance to write full position papers like some of the other candidates, so for my positions, you'll mainly have to rely on these answers I wrote to some of the questions submitted via e-mail to the candidates:
- My answers to “Questions for OGB Candidates from DTrace”
- My answer to a followup on opening the ARC process
I did vote in the poll being used to test the OpenSolaris elections system, so will share my vote there, and explain some of my choices to help further show my positions on the issues facing the community.
The poll asked (and the order of these is the one I was shown - the order is randomized for each voter to reduce bias if people just start voting "1 2 3 4..."):
QUESTION 1.1: ("Priorities") Which of the following items, presented in a randomized order, should be prioritized by the Governing Board in order to promote OpenSolaris and increase its developer mindshare? 1 - Deploy a public defect management system ('Defect_Mgmt') 2 - Remove inactive Communities or Projects ('Remove_Inactive') 3 - Provide an x86/AMD64-based kernel/project build facility ('X64_Build') 4 - Deploy a public Request To Integrate (RTI) system ('RTI') 5 - Provide a SPARC-based kernel/project build facility ('SPARC_Build') 6 - Create an infrastructure project to run opensolaris.org ('Infrastructure') 7 - Replace or remove Jive forum interface ('No_Jive') 8 - Reorganize the existing Community/Project organization ('Reorganize_Community') 9 - Replace opensolaris.org tools with an open source CMS or wiki ('New_CMS') 10 - Deploy a public wiki on opensolaris.org ('Wiki') 11 - Deploy a public code review facility on opensolaris.org ('Code_Review') 12 - Eliminate reliability issues with opensolaris.org web pages ('Reliability')
My vote was:
RESPONSE 1.1 --> 1 6 9 8 4 5 3 11 10 2 7 VERIFY: Your ballot is: Priorities: [Defect_Mgmt Infrastructure New_CMS Reorganize_Community RTI SPARC_Build X64_Build Code_Review Wiki Remove_Inactive No_Jive ]
So why these?
- Deploy a public defect management system
Right now bugs.opensolaris.org is not truly a two-way communication system - for people outside Sun, it's Write Once Read Many (WORM) - they can file a bug, search for bugs, and read bugs, but not update them or have them assigned to them to work on. Additionally many of the bugs and bug fields are still restricted to internal users only, though that's a harder nut to crack due to various legal and customer privacy issues.
This means projects with external contributors are at a gross disadvantage, and has led to projects such as ksh93 using a separate bug tracking system (Steve Lau graciously set up a bugzilla for them on his system), which segregates their bugs from the rest of the community, so bugs.os.o no longer has all the relevant data. This needs to be solved before non-Sun employees can be first-class members of the development community.
- Create an infrastructure project to run opensolaris.org
Right now, too many improvements are stalled because the team running opensolaris.org can't keep up with the everything they need to do to implement them. Open it up now, let the community help you, and let us all move forward.
- Replace opensolaris.org tools with an open source CMS or wiki
The current infrastructure is customized and weird - Project & Community Leaders are the only ones who can edit pages in their areas, so to add someone to edit anything, even just one project subpage, they have to be made a leader, even if they're not doing any leadership. The syntax is also strange and confusing to those used to just about any other wiki-like system in the world.
- Reorganize the existing Community/Project organization
This has been discussed to death elsewhere already, and a big part is just cleaning up the original set of communities created before projects were done. The election confused many people since those doing the most work (projects) are not given voting rights, while those just interested in the technology (communities) are.
- Deploy a public Request To Integrate (RTI) system
This is specific to the ON family of consolidations that use the RTI system (Desktop consolidations, including X, don't - I don't know about all the others), but once the code repository is outside, this will be the biggest obstacle to letting non-Sun people commit code on their own without any internal sponsor.
- Provide a SPARC-based kernel/project build facility
- Provide an x86/AMD64-based kernel/project build facility
SPARC is higher priority than x86, since more people have x86 system access on their own, but commits to most OpenSolaris consolidations require you to build and test on both platforms first, and that's hard to do if you aren't working at Sun or another place with both kinds of machines around and installed with the build environment.
- Deploy a public code review facility on opensolaris.org
- Deploy a public wiki on opensolaris.org
For both of these, while it would be nice to have on opensolaris.org, we've got community ones already that work fine - for instance, I'd be happy just making wiki.opensolaris.org redirect to http://www.genunix.org/wiki/ and declaring that one done.
- Remove inactive Communities or Projects
These clutter up crowded pages and cause confusion, but don't stop any real work from being done.
- Replace or remove Jive forum interface
Again, as much as it annoys me, it's not preventing real work, and can be mostly ignored if you truly hate it. (It would be nice if it didn't break threads and cross-posting and such for people who use the mailing lists instead.)
- Eliminate reliability issues with opensolaris.org web pages
As much as I was tempted to vote for this just to tweak stevel, I just haven't seen enough of a reliability issue to declare this a major problem that needs attention, so I just left it off my choices completely.