[Building Sakai] [Management] Gradebook Situation

[Michael Feldstein]

I don't think anybody here is proposing to circumvent the managed project structure. I certainly am not. But the reality is that (a) we already have groups developing Sakai 2 functionality that it may make sense to move to Sakai 3 in some process that stops short of complete re-implementation, and (b) we already have groups developing Sakai 3 capabilities that are working outside the structure of the managed project. If the Sakai 3 managed project meets its goals, the number of people and organizations working outside of it that wish to develop and contribute in some complementary way will only grow. John, you have called for groups interested in contributing to join the single distributed team. But remember, there were standards set for participation in the steering committee that not everybody can meet. The idea was that a second circle would be formed in which others could participate without having to commit X number of full FTEs, but as far as I know, that's just an idea right now. 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 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.
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.
3. Set some early guidelines about which frameworks are adviseable to use and which are not.
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.

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 makes 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


-- 
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: Ian Boston [mailto:ieb at tfd.co.uk] 
Sent: Friday, July 30, 2010 2:26 PM
To: David Ackerman
Cc: sakai-dev sakai-dev; Sakai UI Development
Subject: Re: [Building Sakai] [Management] Gradebook Situation


On 30 Jul 2010, at 18:45, David Ackerman wrote:

> Ultimately, the final decision would be by the Sakai 3 Project Director, Alan Marks. 


Agreed.

I hope/expect Alan will make any decisions with input from those who are doing the work based on the results of evaluations aimed at providing sufficient hard evidence to make a decision. When we started Nakamura we spent over 6 months evaluating all sorts of approaches and then spent a further 6 months experimenting with a short list, at every step determined not to repeat and mistakes that we might have made in the past (we even wrote done honest evaluation based on evidence as a aim of the project), and always prepared to start again based on tangible evidence. (Which we did).

The development methodology we chose is one that is becoming mainstream in web dev, just watch the sessions from Google IO 2009 and 2010 for proof of that, but even so, we are not doing anything that explicitly excludes other approaches.

I do find it interesting that this discussion is happening here, potentially making decisions and there is hardly anyone from the team tasked with doing the work responding on the list. How about cc'ing the UI dev list for comment ? (done)

Ian



_______________________________________________
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"