Community Involvement

Owned by Former user (Deleted)
Last updated: Nov 28, 2006 by Former user (Deleted)Version comment
3 min read

Community Involvement DRAFT

While the Stanford team of designers, developers, and project managers has been the main contibutor to the SAMigo tool, new contributions from the wider Sakai community are already being made. Most of the contributions to date have been on a smaller scale, but we strategizing for a future where more the wider Sakai community is able to make a more significant contribution to the SAMigo effort. Here are some examples of contributions already made by the Sakai community to Samigo:

  • A new question type for Numerical responses developed by Diego del Blanco Orobitg from Universidad Politécnica de Valencia, based on Fill in the Blank question type, has been included in 2.3.
  • Question pools import from assessments in QTI 1.2 developed by Lisa Wilson from UC Davis, will be included post 2.3.
  • Integration of FCK Editor for Samigo, and a few FCK editor related bugs, by Joshua Ryan, already included since 2.1.

The process outlined below is a first attempt and figuring out a way for the tool's stability and capabilities to be strategically, safely, and reasonably moved forward.

What Stanford will continue to do ... "air traffic control"

Beyond enhancing the tool to meet its own requirements, Stanford will assume an "air traffic control" role for those external efforts that are made to improve the tool. We intend to commit a limited percentage of Marc Brierley's (requirements coordination, functional design collaboration/review) and Lydia Li's (code review and committing) time to this effort. Between the two of them, they will attempt to coordinate efforts outside of Stanford to improve the tool. For the foreseeable future (at least through 2.4), Stanford will also have one full-time developer committed to the project for bug fixing and add/cleaning small features.

We'll be happy to help people get started if they are working on a new feature or fixing a bug. We can give them pointers as to where to start, which documents or files to look at, which tables are used, how we would go about implementing it...etc. Most of these could be done through emails or IM. It worked quite well from our past experience collaborating with the contributors listed above.

What Stanford needs from the community...

There are a whole range of community contributions that can be made, from small bug fixes to whole feature sets. Obviously, the more ambitious a contribution, the more coordination we anticipate. Below is rough process outline the steps and pieces of communication we think will help facilitate these contributions going forward.

Please provide...

  1. A basic "heads up" that you are working on something and to expect a specification.
  2. A reasonably detailed specification before implementation begins. If the enhancement requires changes the form or function of the tool, then a behavioral specification with mockups would be required. If the changes are to the underpinnings to the tool, then a technical specification is needed. This work should not be in conflict with 1) the main functional goals of the tool or 2) the performance or stability of its technology. As with any specification, it is likely that there will be questions to resolve, but we are committed to doing so in a timely manner.
  3. A preliminary schedule that we can all agree on for when this work will happen.
    Also...
  4. All new functionality code must be thoroughly QA'ed and necessary regression testing must be done.
  5. All code compiles with that in the trunk.
  6. Such code needs to be ready at least two weeks before any Sakai code freeze.