A Simple History
The Requirements
- Timed Release
- Reordering
The Players and Roles
- Jim Eng (project lead)
- UNISA (Usability Design and QA)
- Whitman College (Design Mockups and Development)
- Boston University (Design and QA)
Getting the ball rolling
- Coming out of the Requirements Process
- the ranking of our requirements mattered little - we just needed this
- the articulation of these requirements helped little - we had to
rework that anyway - however, we may not have come together in quite the same way otherwise
- it did make it easier for us to talk about what we were doing
- it did make it easier to approach Jim with what we wanted to do
Preparatory Work
- early email discussions
- Jim put some DB work into 2.2.0 release in preparation for us needing it
- Chuck helped make the connection with Jim, and an initial meeting at Sakai conference
The Impact of the Community
- a lot of input early on, during the design phases
- some concerns about overlapping work
- some concerns about resources "bloat"
Where it succeeded:
- requirements met, on time
- a design-centered process
- extra functionality QAed and deployed outside the release cycle
- broad-based input and contributions
- work conducted transparently
- collateral communication (things we learned from each other that
were not specific to this project)
Where it could have done better:
- broadening resources technical skill (Jim still did all the
Sakai-centric work)- taking some of the development burden off of Jim
- didn't cement (at least not practically) a long-term investment or
productivity - clarity: who was making decisions, when and how (some time wasted here)
- communicating ourselves to the community (we were heads-down towards the end)
Risk Management
(or what made it bearable)
- start early: preparatory engagement with project lead
- get clear about commitments
- partner with those under similar pressures
- focused attention on QA, test plans
- extra attention from developer(s) when it counts
- a practical aim, well-defined goals
Lessons Learned
- don't just think about development resources
- design + mockups, refine requirements, QA, planning and coordination
- there are limits to how much community approval can be sought and
accommodated - understand what people are getting out of it: negotiate a useful exchange
- making use of the wiki as a record, keeping us on the same page,
and communication - don't force the project lead to do all the coordination
- start early, think about Sakai's release cycle, and how this can
leverage the broader process
Choosing the Right Project
- find a tool you have a long-term interest in (understand what your
users want and need)
- an area of Sakai that you want to develop an expertise with, and
be responsive with - a project lead you can work with
- local requirements that are not otherwise being met by other teams
- find a project of a suitable scope and kind for the resources you can commit
- developing it for broader use makes others more willing to contribute
- understand the incentives and limitations of your collaborators