SAMigo Release Process

Each SAMigo release contains improvements that fall into the two following categories:

1. Code previously completed by Stanford: Bug fixes or improvements that Stanford completed locally which may benefit others. 
2. Improvements requested by the community: These are improvements suggested by the community, either in the form of a JIRA request, or contributed code. When requests from the community coincide with emerging local requests, Stanford will take on the work locally. Stanford may take on community requests that are not needed locally when we have the resource to do so.

In the past, Stanford has merged code contributed by other Sakai schools or organizations into SAMigo with the criteria that the code had to be fully QAed and updated with trunk code. While these conditions might help prevent performance issues, we have found that sometimes contributed code introduces usability issues. In light of this, Stanford began implementing a new release process for SAMigo starting with SAMigo 2.7. This process is adapted from a process suggested for community development of SAMigo back in 2006 as well as what the OSP group is doing to insure that enhancements are desired and well-designed. As part of the release process, contributions will be undergoing a user experience (UX) review to insure that contributed code does not negatively affect user experience or come in conflict with other recent contributions. This process is described below.

Release Process

SAMigo's release schedule follows Sakai's release schedule. Sakai's code freeze has historically been around September and spec freeze tends to be approximately one month prior to code freeze so the schedule below is based on the assumption that future Sakai 2.x release dates will follow historical trends. Schools wishing to contribute new features or enhancements to a future release of SAMigo are encouraged to do so as soon as possible, given that there is an increased interest within the Sakai community to make code contribution to SAMigo. The following outlines the process and timeline for a proposed SAMigo contribution to undergo a UX review in time for code freeze:

Should UX Review Occur Before or After Coding?

Our preferred process would be to conduct a UX review of your specification before any coding occurs in order to avoid a situation where major recoding is necessary. The UX review process should allow for two rounds of review, followed by 4-6 weeks to code your feature. If you think your feature will require more development time, adjust the date of your initial JIRA spec submission.

At present many schools have coded their feature or improvement by the time they submit it for inclusion in a future SAMigo release. This is understandable if you need to act quickly to take care of local needs. However, please understand that if you wish to contribute your code for general inclusion, you may be asked to recode your work following the UX review; the release date will depend on when you initially contact us and whether the updates are minor or fundamental. 

Clear specifications that describe both rationale and expected behavior are a must. The specifications also need to document all affected pages (e.g., if a proposed new feature will affect the authoring process and grading outcome, then the design specs need to document the changes on both authoring and grading pages). Part of the initial UX review will involve determining if others in the user community can agree with the need expressed in the spec, as well as the way it will be implemented. A good specification ensures that your need is understood correctly. The interface changes you describe are more likely to be approved if they do not introduce usability issues, such as 

• changes to default behavior
• changes to the view of one role, but not others
• implications for other screens other than the one that was changed

https://jira.sakaiproject.org/browse/SAM-939 provides an example of what we are looking for in a design spec document.

Please also note that this is NOT a process for having a feature request developed for your school by other development teams. Development teams may act on your JIRA request, but generally only do so if their users share your users' needs. This process is to ensure that developers who wish to improve SAMigo for their local users do so in a way that does not impede the experience of other users.