[Building Sakai] [Management] Gradebook Situation

[Alan Marks]

[So glad my first post to the lists is on a non-controversial topic.]

So, I see this as a great conversation to have. I certainly understand that
we have two contexts here: that of the managed project and that of the
broader Sakai world. Let me address both:

>From a managed project perspective, especially as we're pushing hard towards
deadline, our approach will be to make reasoned, informed decisions on
technology choices, and to be public[1] about those choices. We have some
great technical staff at the core, and to keep driving forward we need to
trust that team. Mistakes may happen, but hopefully they'll be caught by the
community early.

>From the broader perspective, I don't think we know the best ways yet for
the managed project and the rest of the community to interact. We don't want
to discourage enthusiasm, far from it. But it makes sense to me to have
guidelines and a review process that would ensure we all make the right
technology investments. I will work with the Steering Group and Sakai 3
technical staff to come up with a proposal, which the community will have a
voice in as well. 

[1]. On being public: the managed team in general is not yet good enough at
being public - simply because they team is really just forming (although it
probably doesn't seem like the case), and because we're driving forward
quickly towards the Q1 deliverable. However that said, improved push
communication is one of my personal top priorities so it should get better,
soon. Really.

-----Original Message-----
From: sakai-ui-dev-bounces at collab.sakaiproject.org
[mailto:sakai-ui-dev-bounces at collab.sakaiproject.org] On Behalf Of Michael
Feldstein
Sent: Friday, July 30, 2010 12:34 PM
To: Ian Boston; David Ackerman
Cc: Sakai at collab.sakaiproject.org; sakai-dev sakai-dev; Development
Subject: RE: [Building Sakai] [Management] Gradebook Situation

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"
_______________________________________________
sakai-ui-dev mailing list
sakai-ui-dev at collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/sakai-ui-dev