[Building Sakai] [Management] Gradebook Situation

Sat Jul 31 12:44:48 PDT 2010

I don't perceive myself as arguing with you--or anyone else, for that matter. I have had the issue of the UI framework in the back of my mind because of several conversations I had at the conference in Denver. This thread reminded me that I should surface the question so that conversation can happen about it. In the course of the conversation about frameworks, we got into another conversation about governance and process. I am not complaining about how either of these has been handled and I recognize that the managed project has just gotten started (which is why I suggested putting this issue on the roadmap rather than assuming that it could be dealt with immediately). As long as the issues have been raised, noted, and put in the work queue, then I am happy.

- m

-- 
Oracle
Michael Feldstein | Principal Product Manager
Phone: +1 8188172925 | Mobile: +1 9179218895 
Oracle Academic Enterprise Solutions
25 Christian Hill Road | Great Barrington, MA 01230 

Green Oracle	 Oracle is committed to developing practices and products that help protect the environment	 

-----Original Message-----
From: John Norman [mailto:john at caret.cam.ac.uk] 
Sent: Saturday, July 31, 2010 5:28 AM
To: Sakai UI Development
Cc: sakai-dev sakai-dev; Sakai at collab.sakaiproject.org
Subject: Re: [Building Sakai] [Management] Gradebook Situation

Michael

I feel we are arguing unnecessarily. I think many of your ideas are fine, just the team/project is not ready for them. Some detailed comments inline On 30 Jul 2010, at 20:33, Michael Feldstein wrote:

> [...] In the meantime, development is happening, and it is happening without clear guidance. HEC is doing Sakai 3 development with GWT for sure, and there may be others using some server-side framework or other.

I see 2 distinct issues here. (1) insufficient resource dedicated to communication, we are working on it but more would be good (2) Taking HEC Montreal to illustrate the point (I hope I don't cause offence through incomplete understanding of their motives and actions) I don't know if Montreal actually want to be part of the team vs. have complete liberty to do their own thing as they did in Sakai 2. We know there is goodwill to join the team, but it hasn't always been followed up by action. It may just be that they got missed in the invitations to  join the initial group, it may be they didn't respond. Both scenarios (join team or do your own thing) are fine BTW. Remember Alan is only 4 weeks into the job and is still getting to know the main partners. Drawing in Montreal seems realistic on a 1-3 month timescale /unless/ they are willing to drop what they are doing and help the initial milestones get delivered (i.e. join the team and work on team priorities). I don't think th  e hurdle for Steering Group membership is a hurdle to contribution. Stanford has contributed a full time resource without any needed extra 'organisation' and is not on the steering group.
> 
> I see a few options for handling such situations:
> 
> 1. Kick the can down the road. Discourage out-of-band development until the managed project is further along and make a decision then about blessed frameworks.
We can't discourage it. But I would certainly suggest the gradebook story is a good example of how things can go wrong.
> 2. Declare now that client-side development is the only kind of development that will make it into Sakai 3 core and let developers working with other UI frameworks decide what they want to do with that.
As above, moreover sends the wrong message about the flexibility intended with the platform
> 3. Set some early guidelines about which frameworks are adviseable to use and which are not.
Is underway, but severely limited by resource constraints that are beginning to be partially addressed. In fact, this is the ideal way to get into the team by helping with documentation as you find your way around...
> 4. Create that second ring of participation, including mechanisms for coordinating that group with the steering committee, and feed any questions like these through those mechanisms.
May not be necessary if you have [5] below:
5. Start contributing as Stanford have (and we expect Cape Town will), or at a lower level as Michigan has done. It only requires communication on the list and fitting into the git infrastructure.
> 
> There may very well be others that I'm not thinking of.
> 
> The idea that there would be support for a server-side framework in Sakai 3 is not a new one and I did not make it up. Michael Korcuska brought it up a year ago at the pre-conference working session. Some members of the community are still operating under the impression that this will be the case. I know that I have been. If it is not the case any longer, then that should be made clear.
> 
> It is also important to recognize that this decision has implications 
> beyond Sakai 3, particularly for schools that intend to run in hybrid 
> mode for some period of time (an idea that I am under the impression 
> we are encouraging). Take grade book as an example. Re-thinking and 
> re-implementing a grade book from the ground up is a pretty major 
> undertaking. I would be very surprised (though delighted) if the 
> managed project will be able to deliver a grade book that the majority 
> of Sakai schools would consider to be feature-complete within 12 
> months. It is entirely possible that even schools using mostly Sakai 3 
> for their classes will be using Sakai 2 grade book for an extended 
> period of time. To the degree that that is a possibility, and to the 
> degree that we may have community members who need to build 2.x 
> functionality today but want to do what they can to ensure that at 
> least some of their code will still be relevant and usable when their 
> institution moves to Sakai 3, it mak
 es
>  sense to think about what recommendations to make to these developers.  
> 
> If Alan and the Sakai 3 Steering Committee are taking the lead on addressing the question on the table, that's fine with me. The point is, there's a question on the table. It evolved organically out of discussions regarding grade book work for 2.8. It seems natural that, in a world in which there are two products under the Sakai umbrella that are supposed to interoperate at some level, conversations around goals, priorities, and standards for one of those projects may start to bleed into discussion of the other. Nobody was trying to circumvent the managed project or suggest that decisions should be made elsewhere, but at the same time, there needs to be a mechanism for surfacing and addressing boundary-crossing concerns. 
> 
> - m

_______________________________________________
sakai-dev mailing list
sakai-dev at collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"