[Building Sakai] [Management] Gradebook Situation

[John Norman]

I am slightly stunned by this conversation, which I have only just caught up with.

There are many things I would like to say, but I will try to stick to what I see as the fundamentals.

1. On the question of technology standards for Sakai 3:
I would be against arbitrary decisions that became 'law' for many reasons. AFAIK the Sakai 3 architecture /could/ support many technologies including GWT. That is a good thing. However, I think the key thing for Sakai 3 is to develop a single distributed team supporting the product. Development should follow design and appropriate technical choices should be made by the technical team based on need. After all they (and their hosting institutions) are doing (and paying for) the work. The choices that the team has made for the initial work are simply that - choices for the initial work. The team would need to deal with the implications of any change and should have a strong voice in any such suggestion. I believe Sakai 2 is moving in a similar direction. As a corollary, the way to influence the technical choices should be to join the distributed team and contribute.

2. On the question of Gradebook options in Sakia 3:
I hope we can have a fundamental rethink of grading and gradebook in Sakai 3 and that we will have that fundamental rethink in conjunction with Kuali Student and other players in the SIS space. Much of the features that are listed on Clay's gradebook confluence page, seem to my uninformed eye to be grade processing rules that ought to be configurable (perhaps using a rules engine) rather than requiring code changes. Other thoughts include reviewing the use of a reporting tool like BIRT to present user interfaces.

HTH
John

On 30 Jul 2010, at 17:29, Michael Feldstein wrote:

> I'm not hoping to make any decisions on this list right now. I'm not even sure who is the right person or group to make a decision. I'm just hoping to have a discussion to get some input at this point. I'm not sure how to address a wider technical audience in the Sakai 3 community than posting to the dev list, but if you think this topic would be best raised to another group, then I welcome your suggestions (or your cc's to the relevant lists).
> 
> This isn't an abstract question and we aren't starting from a blank sheet of paper. Grade book and HEC's Syllabus tool are, from what I can tell, two of the projects that may migrate to Sakai 3 in some form or other rather than being ground-up rewrites. Both use GWT. HEC is also doing some Sakai 3 ePortfolio work that has gotten a lot of attention and is written in GWT. I could be wrong about the likelihood of these projects becoming part of Sakai 3 core, and there may be other projects that I am not aware of. I also agree that what people are talking about or using right now isn't necessarily the best indicator of what the community should be using. But adoption should be one consideration. I want to have a better understanding of what the other considerations should be, what GWT alternatives people think are worth considering, and whether I am even framing the problem correctly.
> 
> Which is why I'm asking.
> 
> - 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: Jim Eng [mailto:jimeng at umich.edu] 
> Sent: Friday, July 30, 2010 11:31 AM
> To: David Horwitz
> Cc: sakai-dev at collab.sakaiproject.org
> Subject: Re: [Building Sakai] [Management] Gradebook Situation
> 
> Michael,
> 
> Are you really hoping to make a decision about rendering technologies for Sakai 3 on a thread about Gradebook2 in sakai 2 on the dev list??  That seems wrong somehow.
> 
> I suspect if you raised a question to some wider audience about server-side rendering technologies for a CMS that is mostly using client-side rendering, the answer would probably gravitate toward something like PHP, Python or Wicket.  Most people would not choose GWT as a primary way to create an arbitrary UI.  For something like gradebook 2, with very specific needs that GWT satisfies, GWT makes a lot of sense.  But it makes little sense to tie the core of Sakai to GWT.  In my opinion.
> 
> Jim
> 
> 
> 
> On Jul 30, 2010, at 11:21 AM, David Horwitz wrote:
> 
>> 
>> snip
>>> 3. Of those people who believe a server-side UI framework is necessary, most of the preferences expressed so far have been for GWT, with one person raising Wicket as an alternative possibility.
>>> 
>>> 
>> 
>> I would however note that that person was the only developer who is 
>> developing code in the sakai core .....
>> 
>> 
>> D
>> _______________________________________________
>> 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"
>> 
>> 
> 
> _______________________________________________
> 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"
> _______________________________________________
> 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"