[Deploying Sakai] OAE mail list changes/additions

Anthony Whyte arwhyte at umich.edu
Wed Sep 7 08:10:23 PDT 2011

Below is a summary of a proposal regarding OAE list communications that I floated over the course of the last few days to David Goodrum (OAE steering group chair) Ian Dolphin (Sakai Foundation Director), Alan Marks, the OAE leads (Nico, Chris, Carl, Zach and Kent) and their managed team colleagues as well as other OAE contributors such as Ian Boston and Ray Davis.

For developers, the chief change involves combining both front- and back-end discussions into a single public list called oae-dev.  I proposed that both the nakamura list (sakai-kernel at googlegroups.com) and sakai-ui-dev at collab.sakaiproject.org be retired in favor of the new list.  I also recommended the creation of an oae-production list for deployers, the elimination of private chat channels and private Google groups such as s3leads and s3team in favor of oae-dev and the #sakai freenode IRC channel as well as use of existing lists such as the Sakai security and security contacts lists for sensitive security-related discussions.  The rationale for each suggestion together with recommendations and questions regarding other lists are outlined below. 


The proposal has thus far received a unanimous +1 from all parties surveyed.  When asked when we should initiate the cut over to oae-dev (sensitive as I am to the impending oae-1.0 release), the response was "now", "yesterday", "last week", "months ago."  Given these sentiments  I see no reason to delay switching list discussions to the new oae-dev and oae-production lists.  Let's do it now.

OAE developers of all persuasions should subscribe to oae-dev now; deployers, developers and others concerned with running OAE pilot/production instances should also subscribe to oae-production now.  Links to the subscription pages are listed below.

There are currently several important ongoing threads on the nakamura list regarding IMS CP imports, a call for feedback on tech specs for an upgrade bundle and sparsemapcontent performance issues, among others.  We need to make sure that these discussions are not interrupted as we move to the new list.   I should also note that a thread on the oae-list regarding versioning started last yesterday.  It's an issue that warrants discussion.

I'll be adding notices to both nakamura and sakai-ui-dev lists and will also post the info below in Confluence and elsewhere.





oae-dev at collab.sakaiproject.org

Type: public list, public archives, moderation limited to non-member posts only although it is expected that "pilot/production-related" questions posed on the list will be re-directed to oae-production (see below).

Rationale: This list SUPERSEDES both the Google sakai-nakamura list AND sakai-ui-dev.  oae-dev will provide a single public mail list for non-security-related OAE developer/development conversations.  The goal is to encourage developer engagement across the entire code base as well as reinforce further the solid working relationships that currently exist between the UI Dev and Server Dev teams.  oae-dev uses the Sakai Community collab infrastructure and aims to simplify list subscription choices for new developers (e.g., go here, not go here, there and elsewhere).  

Join: http://collab.sakaiproject.org/mailman/listinfo/oae-dev

Note: oae-dev has already begun to garner traffic.  See the list archives for current threads:


Finally, deployer-related questions should be referred to "oae-production" in order to maintain list focus on development discussions, issues and concerns (see below for more details).


oae-production at collab.sakaiproject.org

Type: public list, public archives, moderation limited to non-member posts only

Rationale: this list is intended for those who are responsible for deploying and maintaining OAE pilot and production instances.  Installation, configuration, tuning, clustering strategies and other non-security-related deployment topics are the grist for this list.  Apache projects, for example, try to route user-related questions to mail lists such as users at sling.apache.org in order to keep the dev list focused on development-related discussions.  I think we should attempt the same approach and route deployer-related questions to this list rather than oae-dev.  It will take some discipline to achieve as well as pointers fro new subscribers.

I believe OAE deployment issues are sufficiently distinct from that of the CLE (despite hybrid or perhaps in part because of it) to warrant a separate list as opposed to using the existing [CLE] production list.

I considered "oae-user" instead of "oae-production."   However, Sakai tends to envision its user community rather more broadly than what is typical for an Apache "user" list so I think it best to reserve "oae-user" for the day (hopefully soon) when a user community emerges and desires a list to discuss their experiences using the OAE.

Join: http://collab.sakaiproject.org/mailman/listinfo/oae-production


Recommendations:  There are a number of @sakaifoundation.org Google group aliases provided for the managed team.  These include:

s3leads at sakaifoundation.org
s3team at sakaifoundation.org
s3bl at sakaifoundation.org

These will be wound down and then eliminated in favor of the public OAE lists and IRC #sakai channel for team communications.  


Recommendation: public #sakai and #sakai-design IRC chat channels exist but of late the OAE leads have been using a private Skype chat session in order to facilitate OAE 1.0 release work.  The bulk of conversations that I have observed on Skype can and should be held in public and I recommend that the leads (including myself) utilize oae-dev and, when a quick chat is required, the public #sakai channel set up at irc.freenode.net.

1) I understand that the IRC channels are logged.  Is logging actually necessary?
2) The Confluence IRC guide notes that the #sakai-design was "created for design-related conversations, but most people tend to hang out in #sakai."  If this is the case do we actually need this second channel.  I recommend we eliminate it in favor of a single channel.


public list, public archives

sakai-ui-dev-tracking at collab.sakaiproject.org

Question: created Jan 2011, 41 members, Jira event notifications (e.g., create, assign, update, comment).  Is this actually needed?  The SAK project, for instance, simply uses ye olde "bugs-admin at sakaiproject.org; the Nakamura Jira project uses k2-jira at sakaproject.org


security at collab.sakaiproject.org

Type: private list, private archives

Recommendation: utilize existing security team list in order to facilitate sensitive security discussions and work.  Using the existing list would plug OAE into the considerable security expertise currently resident in the CLE Security Work Group.

Join: if assessing and/or addressing possible security vulnerabilities is a competency you possess please write me at arwhyte at umich.edu.


sakai-security-contacts at collab.sakaiproject.org

Type: private list, private archives

Recommendation: use existing security contacts list for providing OAE-related security alerts and patches.  Provisioning two security contact lists from what is expected to be a common pool of subscribers will lead to administrative inefficiencies that is best avoided.

Join: institutional security contacts interested in joining this list can send an email to me at arwhyte at umich.edu


infrastructure at collab.sakaiproject.org

Type: public list, public archives

Purpose: a new list created to support the activities of Chris Maurer, myself and others who provide infrastructure services for the Sakai Community (not just OAE).  Jira, Confluence, SVN, Nightly2 and Jenkins CI server related requests and issues are handled by a volunteer team of contributors.  There is also a companion Jira INFRSTR project for logging requests and work performed.  If you need assistance write us; if you want to help, write us or log a ticket in Jira.

Join: http://collab.sakaiproject.org/mailman/listinfo/infrastructure

Jira project: https://jira.sakaiproject.org/browse/INFRSTR



Type: public list, public archives

Recommendation: it's been suggested that we need an oae-general or oae-announce list.  I'd like to hold off on creating this list for the moment, relying instead on the announcements at collab.sakaiproject.org which serves everyone in the Sakai Community.

Join: http://collab.sakaiproject.org/mailman/listinfo/announcements


Type: public list, public archives

Recommendation: it's been suggested that we need a oae-qa list.  I'd like to hold off on creating this list for the present in favor of centering QA discussions on oae-dev and, when required, oae-production.  A key reason for me is that I consider QA integral to the development process and embedding QA in oae-dev and oae-production discussions seems natural to me.  Second, the current OAE QA team is at present small (hopefully that will change) and bug bashes at this point rely on a good deal of developer participation.  Third, the venerable [CLE] sakai-qa list suggests we should consider carefully the case for yet another oae list.  It is currently a light traffic list and many of the posts to it are infrastructure-related (e.g., QA server X is going down for a new tag) as opposed to QA-related.


oae-urg at collab.sakaiproject.org

Type: public list, public archives, posts from subscribers who are not named URG members are currently moderated.

Recommendation: no changes other than to encourage URG members to consider winding down list moderation rules applied to subscribers who are not named members of the URG in order to encourage broader participation.  Clay Fenlason outlines current URG moderator practices here: 


Join: http://collab.sakaiproject.org/mailman/listinfo/oae-urg


Type: public list, public archives

oae-trg at collab.sakaiproject.org (public list, public archives, list moderation limited to non-member posts only)

Recommendation: this group has yet to be formed.  I recommend that list moderation be limited to non-subscriber posts only.

Join: list does not exist at present.


oae-ux at collab.sakaiproject.org

Type: public list, public archives

Question: an existing list I ran across with 8 members, 0 posts.  It appears to be misconfigured (missing entries in /etc/aliases) which may explain the lack of list traffic.  I assume the intent here is to support user experience design discussions.  Nico tells me that at this point we do not need a separate design list.


oae-private at collab.sakaiproject.org

Type: private list, private archives

Purpose: A low traffic list modeled on the Apache "private" list where operational topics of a sensitive nature can be discussed.  Initial membership would include the chair of the steering group (SG), other SG members, the project manager, leads and other contributors as determined by the SG.


The OAE steering group (SG) may soon utilize the collab listserv.  If so, it is expected that any lists supporting SG discussions will be set up as private lists with private archives.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/production/attachments/20110907/bc77ac21/attachment-0001.html 

More information about the production mailing list