We had a great discussion at FOSDEM about where we wanted to take the development and contribution model for userland, and that was followed up by direct conversations with Alasdair, OI's fearless leader, and Andy Stormont. We also took feedback from recent group discussions on #oi-dev and userland@, and we hope you'll be as excited about these changes as we are.
What we're rolling out is essentially a variation on scrum. We chose this for a couple of reasons, mostly to do with resource and priority management.
Under the new model, development is timeboxed around fixed-period dev cycles. At the beginning of each cycle, we pick a list of priorities (e.g. sync'ing with userland, bringing in a new default compiler). We then have a three week "walk" where contributions are worked on in a shared WIPing post repo. Packages would potentially be available for anything that builds
successfully, and things like compiler changes would need to be available at the outset of the cycle.
At the end of the three week walk, there's a one-week sprint. The sprint starts with a sanity-check of the priorities against the work that's been done (i.e. to make sure that anything that's clearly overreaching is set aside for a later cycle). Then all the components are polished and prepared, reduced to minimum requisite change and rationalized as changesets, and lined up for commit. At the end of the sprint, there's a review and commit cycle that looks at the changes as a block.
We've asked Andy to take on the role of userland scrum master, responsible for negotiating deliverables for each cycle, clearing blocker issues, and shepherding changes through the review process.
I'll be stepping in as development manager for OI generally. As such I'll be on the other end of the negotiations. Andy's job is to advocate for userland and its deliverables, whereas my job is to think about getting releases out the door and to provide an alternate perspective on resources and priorities. Andy works for Nexenta, who employs all of our paid contributors, and has unparalleled experience in developing FOSS distributions around illumos and its successor projects via StormOS, NCP, and illumian, our sibling distro and userland partner.
Supporting both of us as project manager will be Lou Picciano, whom most of you know as DrLou. His role is to make sure that we don't lose track of our priority deliverables or completely forget about the things we said we would defer.
So, those are the people, but what we really care about is getting the community working together more effectively to deliver product. We have a mix of full-time and part-time developers, so we wanted a model that could work for both. Having the ability to drop code that's still a WIP and pick it up from a teammate is a model designed to accommodate people who are juggling other obligations and want to contribute in time that they can't organize around userland.
Given the more collective approach to development, one area where we'd like to hear back is in terms of how to attribute changes and recognize work. We want people to feel a clear sense of accomplishment as contributors, and we don't think that a team model should diminish that. If you have thoughts on this, please provide comments or trackback responses on your own blog.
Under the new model, final reviews and commits are handled by the dev manager and the scrum master. Nothing will be committed from the WIP to the dev repo unless it can build and test cleanly. Changes that may be handed off between people without being able to clean or test will be reduced to a single changeset before by the time they are migrated between repos.
We want to have peer review throughout the process, so the scrum master will also have the ability to set up peer review arrangements between cycle participants to make sure that quality is maintained and that changes are clearly conceived, implemented, and documented. The best measure of this is whether peers with a reasonable background in the change area agree that this is the case.
Dev cycles needn't target just porting and packaging: tools, test suites, and CI in particular seem fair game, as they can enhance productivity. Part of the scrum master role is to identify these issues and advocate their priority.
I've mentioned testing a few times, so I'll underscore this before concluding: quality is a core value of the OI project. We're solidifying this value by making sure that we're running available test suites, tracking known issues, and working with the upstream to fix test suite issues or clean up any issues with the port. We hope to engage the wider OI community as this model matures to broaden our definition of quality and expand it based on the use cases people build around the technology.
Finally, with the concept of a separate WIPing post and dev/canonical repo, we expect that we will no longer be constrained to use mercurial exclusively. We know that there is a strong interest in introducing git, and we expect that the WIPing post is the place to do it. We also expect that this more collaborative dev model will adopt an SCM workflow closer to this much-discussed git model, and Andy will be primarily responsible for fleshing this out.
Monday 5 March 2012
illumos applying for GSoC 2012
illumos is applying to participate in Google Summer of Code 2012. I will be serving as org admin, and we need volunteers from
the community to serve as mentors, as well as project ideas. Students
will begin showing up the developer lists shortly, and we hope that
community members will engage them to begin contributing to the project
by fixing bite-sized bugs, learning how to navigate the codebase, and
talking about work that needs done and can be done by a student in the
course of a summer. Students will be treated as regular community
members, with all the consideration and responsibility that entails, and
will be expected to engage through regular community channels
(developer mailing lists and IRC channels).
Submit Ideas for illumos Development
We have an Ideas List - but these are not the only possibilities - we encourage both students and illumos community members to submit more ideas for projects that need work and/or you'd like to work on.
Please bear in mind that our students are students. We want to make them long-term contributors to open-source projects and preferably illumos. Projects should be demanding but nevertheless pitched as three months of work that is doable for a student likely making a first, serious contribution. Students may not have had to work on such an extensive practical assignment previously. Projects should be conceived at least as much in terms of pushing the student to grow from where they are into an
open-source contributor as providing a deliverable otherwise aligned with community priorities.
Work should be able to be submitted and integrated by the conclusion of the mentorship on August 21.
Community Involvement
illumos is applying as a project, with a deadline of March 9.
By March 17 we will provide links to materials advertising illumos participation in GSoC 2012. We encourage community members to advertise these opportunities through appropriate channels. If you have contacts in university departments that teach potentially qualified students or access to students through alumni social networks, it would be especially appreciated if you let them know of our participation and encourage them to make it known to their students.
GSoC is a commitment for the community, as well as for anyone who volunteers as a mentor.
Students will appear on IRC and mailing list from March 17 (some enterprising ones possibly earlier) to April 6 (the application deadline) seeking to learn more about illumos and project prospects. We strongly encourage applicants to learn more about illumos by building and installing illumos-gate on top of an existing distribution, fixing bite-sized bugs, learning to navigate the codebase, discussing projects either from the community suggestion page or on their own initiative, and otherwise becoming involved as contributors before submitting applications.
We encourage all community members to engage positively with promising potential applications who demonstrate such interest, capability, and commitment before and during the application period. Applicants will be evaluated in part based on public community interaction. If students contact you privately about their interest, respond as you feel comfortable, but please also remember that pubic interactions are a substantive basis for evaluation, both for acceptance and completion, and be sure that students are aware of this.
Students are expected to engage the project sufficiently before the official beginning of their mentorship that they can begin working on their official start date of May 21. Students will be expected to devote sufficient time to the project between being accepted on April 23 and starting on May 21 to begin development work on their start date.
During GSoC students will be active on the developer lists and IRC channel. Projects that treat students like regular contributors tend to have much more successful mentorships. We do not want to make students unnecessarily dependent on mentors, so we also encourage all community members to help answer questions, make students aware of self-service resources, and provide guidance and domain expertise. Please be aware that students will be expected to check in regularly and share work-in-progress over existing developer channels.
Mentoring
GSoC provides some general manuals:
* General manual
* What makes a good mentor
Mentors must be registered with Google no later than April 20, but illumos will need to rank students and projects and thus have firm commitments by mentors no later than April 16. Mentors are expected to check student reports to the mailing list daily, regularly (at least weekly) review progress and provide feedback over three months from May 21 to August 21, to complete mid-term evaluations the week of July 9 and final evaluations the week of August 20. and to hold students accountable for delivering on-schedule and communicating promptly about any difficulties they may encounter, particularly those that may require changes to deliverables.
Mentors can make arrangements for backup coverage (e.g. for holidays, in case of conflicting work obligations), but they must have the bandwidth to communicate with students on a daily basis for basic status checks, weekly for work review, complete midterm and final reviews, and otherwise to assist students with legitimate issues, either directly or by finding available resources elsewhere in the community. Time commitments will necessarily depend on the student, the project, and the wider base of community members able to assist. We expect mentors to evaluate this and to communicate these particulars to the org admin during student and project selection period from April 7-20.
Organizational Administrator
The org admin (I've volunteered for this year, and Albert Lee will be supporting me as last year's admin) will help mentors keep track of student progress and make sure that students have development resources available to them, including remotely accessible development systems. If you are a potential mentor wishing to discuss applicants or projects during the application period, please contact the us privately.
Submit Ideas for illumos Development
We have an Ideas List - but these are not the only possibilities - we encourage both students and illumos community members to submit more ideas for projects that need work and/or you'd like to work on.
Please bear in mind that our students are students. We want to make them long-term contributors to open-source projects and preferably illumos. Projects should be demanding but nevertheless pitched as three months of work that is doable for a student likely making a first, serious contribution. Students may not have had to work on such an extensive practical assignment previously. Projects should be conceived at least as much in terms of pushing the student to grow from where they are into an
open-source contributor as providing a deliverable otherwise aligned with community priorities.
Work should be able to be submitted and integrated by the conclusion of the mentorship on August 21.
Community Involvement
illumos is applying as a project, with a deadline of March 9.
By March 17 we will provide links to materials advertising illumos participation in GSoC 2012. We encourage community members to advertise these opportunities through appropriate channels. If you have contacts in university departments that teach potentially qualified students or access to students through alumni social networks, it would be especially appreciated if you let them know of our participation and encourage them to make it known to their students.
GSoC is a commitment for the community, as well as for anyone who volunteers as a mentor.
Students will appear on IRC and mailing list from March 17 (some enterprising ones possibly earlier) to April 6 (the application deadline) seeking to learn more about illumos and project prospects. We strongly encourage applicants to learn more about illumos by building and installing illumos-gate on top of an existing distribution, fixing bite-sized bugs, learning to navigate the codebase, discussing projects either from the community suggestion page or on their own initiative, and otherwise becoming involved as contributors before submitting applications.
We encourage all community members to engage positively with promising potential applications who demonstrate such interest, capability, and commitment before and during the application period. Applicants will be evaluated in part based on public community interaction. If students contact you privately about their interest, respond as you feel comfortable, but please also remember that pubic interactions are a substantive basis for evaluation, both for acceptance and completion, and be sure that students are aware of this.
Students are expected to engage the project sufficiently before the official beginning of their mentorship that they can begin working on their official start date of May 21. Students will be expected to devote sufficient time to the project between being accepted on April 23 and starting on May 21 to begin development work on their start date.
During GSoC students will be active on the developer lists and IRC channel. Projects that treat students like regular contributors tend to have much more successful mentorships. We do not want to make students unnecessarily dependent on mentors, so we also encourage all community members to help answer questions, make students aware of self-service resources, and provide guidance and domain expertise. Please be aware that students will be expected to check in regularly and share work-in-progress over existing developer channels.
Mentoring
GSoC provides some general manuals:
* General manual
* What makes a good mentor
Mentors must be registered with Google no later than April 20, but illumos will need to rank students and projects and thus have firm commitments by mentors no later than April 16. Mentors are expected to check student reports to the mailing list daily, regularly (at least weekly) review progress and provide feedback over three months from May 21 to August 21, to complete mid-term evaluations the week of July 9 and final evaluations the week of August 20. and to hold students accountable for delivering on-schedule and communicating promptly about any difficulties they may encounter, particularly those that may require changes to deliverables.
Mentors can make arrangements for backup coverage (e.g. for holidays, in case of conflicting work obligations), but they must have the bandwidth to communicate with students on a daily basis for basic status checks, weekly for work review, complete midterm and final reviews, and otherwise to assist students with legitimate issues, either directly or by finding available resources elsewhere in the community. Time commitments will necessarily depend on the student, the project, and the wider base of community members able to assist. We expect mentors to evaluate this and to communicate these particulars to the org admin during student and project selection period from April 7-20.
Organizational Administrator
The org admin (I've volunteered for this year, and Albert Lee will be supporting me as last year's admin) will help mentors keep track of student progress and make sure that students have development resources available to them, including remotely accessible development systems. If you are a potential mentor wishing to discuss applicants or projects during the application period, please contact the us privately.
Subscribe to:
Posts (Atom)