...
In the past, Stanford has merged contributed code code contributed by other Sakai schools or organizations into SAMigo ; with the only condition was that it was in production at the contributor's school for a year without any problems and that it might be useful to other schools. While that condition 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.
...
Clear specifications that describe both rationale and expected behavior are a must. The specifications also need to document all affected pagesscreens (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 pagesscreens). 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
...