Sakai Development Process Michael Korcuska July 8, 2009
Agenda A bit of history The proposed process The process applied 2.7 & 3.x Nominations for product council How to get started
A bit of history Inputs Community Survey Selected Interviews Open Source Comparison Projects Project Goals exercise 2-day retreat in February Post retreat work Much /phone follow up
Survey & Interviews 50+ Organizational Responses 150+ Individual Responses About a dozen minute phone calls Conducted by facilitator (Kim Thanos) Overall Result Sense of overall stability Trust in Sakai board Want to spend more time on community Sakai Believe that Sakai will be the best platform
Community Wants Clear product vision & direction More communication from Foundation Roadmap that allows campus advocates to effectively communicate with stakeholders Project structure that attracts sufficient resources and uses them effectively More input from functional experts & designers Allow diverse types participation Large and small, Formal and informal, Institutional and individual
Comparisons
Ways of Getting Work Done Organic – Contributors participate in the community based on personal/local interests and priorities. It is the responsibility of the individual to communicate and request broader contribution. Coordinated – Community structures actively seek to identify and align common contributions. Unmet needs are identified to leaders to encourage investment. Managed – Resources are committed to achieve a defined set of deliverables. Central authority determines priorities.
Product Life Cycle R&D Mostly Organic No criteria on activities or development team Incubation Coordinated, with selective support from Sakai Foundation Projects that intend to enter main product Product Development Major Projects: Managed, Smaller Projects: Coordinated High bar to leave this phase Maintenance Coordinated For bug fixes and minor feature additions End of Life Coordinated/Managed
Major Product Changes R&D Is it significant? Will it work? Incubation Is there a plan/team? Will it meet standards? Does it fit? Product Dev Meets standards? Maintenance plan? Generate new ideas Try new technologies Prove desirability Create dev team/plan Reduce dev risks Finish building Test Document Community Product Council
Product Development Structuring of work in this phase is key Projects probably need Project management Project schedule and plan Functional leadership UX (including accessibility and i18n) Multiple organizations involved Exceptions possible K2 using Apache-style management successfully Key: Ability to predictably deliver quality product
Product Council Authority: Decide what is in the official release How: Based on objective criteria as much as possible Open process and document decision-making Also: Provide guidance to incubation projects who are wondering what they need to do to make the release
Product Council Qualifications: A broad understanding of the Sakai product The ability to advocate for the needs within his/her area of expertise and maintain a broad view of community and product needs Demonstrated commitment to engage with and contribute to the community Expertise in more than one aspect of the product User experience, including accessibility and usability Teaching and learning Research Software design and architectures Software production management (deploying and administering)
Changes What’s the same? Open development process Low barrier to entry for R&D projects Independent projects possible/encouraged Small feature development remains the same What is different? Adherence to criteria from Incubation to Release Managed process for development team(s) Product Council to enforce criteria for making release The idea of a maintenance group R&D ≠ Contrib, Incubation ≠ Provisional, Product ≠ Core
Independent projects Contrib projects that don’t intend to become part of the main release (e.g. Melete) Desire to establish rating system for these tools Current proposal too complex My recommendation: 3 simple ratings (scale of 1-5) based on community consensus UX Does it follow Sakai conventions? Is it accessible/localizable/documented? Technical Does it follow Sakai conventions? Is it secure/scalable? Support How widely is it used in production? Is anyone maintaining code?
Product Council Nate Angell (rSmart) Noah Botimer (Michigan) Eli Cochran (Berkeley) Michael Feldstein (Oracle) Clay Fenlason (Georgia Tech & Sakai) David Goodrum (Indiana) John Lewis (Unicon) Stephen Marquard (Cape Town) John Norman (Cambridge) Max Whitney (NYU)