[Building Sakai] [Management] Gradebook Situation

[John Norman]

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