[WG: Accessibility] FW: [Management] Questions about the relationship between the Product Council, Release Management, QA

[Richwine, Brian L]

I found this forwarded email informative from the Sakai Management list. I wonder what place accessibility has in any inclusion criteria that is developed.



I am also inspired by the "Characteristics of Strong Projects" section of the "How Sakai Development Works" Sakai wiki page (http://confluence.sakaiproject.org/display/MGT/How+Sakai+Development+Works#HowSakaiDevelopmentWorks-CharacteristicsofStrongProjects) - especially that it lists "designing for accessibility from the beginning" as a characteristic of strong projects. In the Sakai 2 vs. Sakai 3 note, it mentions that the criteria for Sakai 2 and Sakai 3 could differ, since some standards like accessibility are far more expensive to retrofit into a project than if they were planned for in the beginning. It looks like the time is now for our efforts to make a big difference in Sakai!



Also note the bit about choosing the CKEditor vs. FCKedit discussion under item 3 in the forwarded email below. It looks like there is discussion ongoing to determine who decides such questions.



-Brian



From: management-bounces at collab.sakaiproject.org [mailto:management-bounces at collab.sakaiproject.org] On Behalf Of Berg, A.M.
Sent: Wednesday, November 18, 2009 9:59 AM
To: management at collab.sakaiproject.org
Subject: [Management] Questions about the relationship between the Product Council, Release Management, QA



Hello Management List



Anthony as Release Manager and I as QA director wish to clarify the relationship between the Product Council, Release Management and the QA process. Below are a few topics for discussion.


1.  Communications.  It has been difficult to follow Product Council discussions and activities, particularly regarding the status of actionable items.  This makes QA and release management planning a more challenging exercise than we think it ought to be.  Perhaps all that is needed is the posting of regular status updates to the Community.  Or perhaps regular briefings.  Or maybe something more is required.


2. Measurable criteria for new capabilities.  It would benefit QA and Release Management greatly if the Product Council can define inclusion criteria that are measurable. We suggest the forming of a small work group to generate a small set of criteria which can be tried out during the 2.7 process.


3. Compatibility Issues.  We perceive something of a gap in the decision-making process regarding questions involving the ever changing relationship between a Sakai release and the technologies with which it must operate.  It is understood that the wisdom of the dev list is engaged regarding, for example, what version of ehcache or Apache commons we should be using.  But there are larger compatibility questions that require resolution since, at a minimum, they require QA servers environments to be adjusted or augmented.



Compatibility issues that impact release and QA planning have been raised on the dev list and elsewhere but no decisions regarding how to proceed have been taken.


For 2.7 the issue of Java 1.6 looms large since Java 1.5 has now reached EOL as does whether or not we should test 2.7 against MySQL 5.1 and Oracle 11, as well as what version of Tomcat we should be testing against, etc (a decision with implications for OSP).  Whether or not we choose CK 3.0.1 over Fck 2.6.4 requires resolution, especially so given recent efforts by accessibility folks to review CK.  Is the Product Council the body to decide such questions?  If not, who?

4.  Release Scheduling.  We prefer feature-driven as opposed to date-driven releases but understand too the trade offs required in order to put out a product that meets the deployment schedules of our user community.  However, it is unclear who is responsible for determining our release schedules.  Who decides?

5.  Right of Refusal.  We recommend that QA and Release Management be vested with a right of refusal should a new capability (or updated version) after evaluation and testing results in a measurable decline in the quality and/or performance characteristics of a release.



Alan

Alan Berg
Interim QA Director - The Sakai Foundation

Senior Developer / Quality Assurance
Group Education and Research Services
Central Computer Services
University of Amsterdam

http://home.uva.nl/a.m.berg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/accessibility/attachments/20091118/1f3799b0/attachment.html 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001.txt
Url: http://collab.sakaiproject.org/pipermail/accessibility/attachments/20091118/1f3799b0/attachment.txt