[Building Sakai] 2.7 Release Discussion - Basic LTI Portlet

[Clay Fenlason]

Thanks for pressing on these questions, Chuck. Some thoughts in no
particular order:

- Probably goes without saying, but let me say it anyway so that no
one gets the wrong idea: we're talking about the "heavy" process for
significant new capability, and people shouldn't imagine that anyone's
going to be insisting on a big effort for each new feature of an
existing tool.

- I should be an initial point of contact for these sorts of things,
yes. I think you express it well. I'll be delighted when the process
becomes so familiar and well-established that it doesn't need a lot of
back and forth, but for the moment we're still blazing a trail.

- I think things may get off on the wrong foot if the goal at the
outset is to get into a particular release (in this case 2.7). I
appreciate how that sort of approach can focus the mind, but I think
it weighs things down too much at the beginning, it may create a poor
set of expectations, and I fear it may encourage people to postpone
engagement until the run-up to a code freeze.  I think release
decisions will happen further down the road, and I don't want to
front-load the early conversation with those assumptions.

- At a certain point JIRA should be used to track progress, I agree,
though I also expect we'll need to wrap these JIRA issues with some
Confluence presentation in order for these things to be discoverable
and readable. sakai-dev is not a great place to work things out
systematically, true, but JIRA can be impenetrable.

- We need a simple "page" that can be filled out, agreed. This is
something we'll need to develop, and some attention will be given to
it in the coming weeks.  For now, although I'd once again refer to the
scorecard [1] as a set of considerations you'll want to keep in view
(though it's not yet a straightforward form to fill out, it's
suggestive), let me first suggest a brief introduction, like a kind of
speed-dating card:

Who is contributing to this work, and who should be the main point of contact?
What is this work trying to achieve, expressed simply? Why would this
be helpful, in words that the community would understand?
What is the current state of the effort and the plan/roadmap going
forward, however sketchy?
If you have any documentation - whether requirements, wireframes, or
some sort of specification - where can that be found?

- I'm not quite as confident as you that the lesson of our history is
that a long-term commitment from a dedicated resource is a better
tradeoff. It may work in some instances, but many of our contributors
simply cannot make credible promises of that scale, while the managers
who can make (slightly more) credible promises have difficulty tying
it to particular individuals, and so on some level we need a way for
maintenance efforts to be shared and distributed.  This is partly what
the maintenance team idea is about.

~Clay

[1] http://confluence.sakaiproject.org/x/CgDi

On Sun, Jul 19, 2009 at 10:01 PM, csev<csev at umich.edu> wrote:
> Clay,
>
> I have some functionality I would like to add to 2.7 and am happy to
> be a guinea-pig for the new process for new functionality.
>
> I would like to add a BasicLTI Portlet to 2.7 - This is an evolution
> of the SimpleLTI portlet which has been in production at UM for a
> year.  BasicLTI is going to be an approved IMS spec so I figure it
> makes sense to update the portlet and then get it into Trunk and in
> the release.
>
> The code is in pretty good shape but does not yet have a "perfect"
> score card - but since it is pretty small, I can quickly fix those
> things where I see a short fall and likely respond to any concerns
> raised in the process. The very fact that my code is small and
> "imperfect" will give us an opportunity to have the PC look it over
> and raise issues and then watch me fix them and see how the process
> helps improve incoming software to meet the needs of the community and
> insure the long-term viability of a product before we take it into the
> trunk.
>
> I also think that this is a nice example because the I am the creator
> and maintainer of the software and I will be making a commitment to
> maintaining the software going forward. In effect I am making a
> "motion" to add the software (as compared to a situation where the PC
> looks around for tasty bits and "pulls" software from contrib in
> because a lot of people like it).
>
> I think that an important part of including anything in the release is
> those people committed to maintaining that software for the long term
> and making a public statement to that effect.  We have had bad
> experience in the past where the community took "pretty good" code
> from a team that decided not to support the new code and then
> supporting the code defaulted to be "community responsibility".  The
> "community resources" available to support code that they have not
> initially written have been pretty hard to find - so we should only
> take software with an agreed-to commitment to long-term support from
> the proposers.  I would recommend that the PC be very wary of
> decisions where - "this software is so good that we are sure that it
> will get maintained".  When there is not an active team - actively
> asking their software to be included and publicly agreeing to long-
> term commitment of that software - we should simply leave the software
> in contrib.
>
> I also think that the right way for me (the proposer of the new
> functionality) to work is to have you (the Product Manager) be my
> primary point of contact and for you to shepherd me through the
> process.  The process already is starting to seem a little complex and
> I would like a human guide to talk to.  In that process I might
> interact with the product manager, the council or others at your
> direction, answer questions on the dev list, etc etc etc and all of
> that interaction will help decide if I am willing and able to meet the
> community's needs (i.e. If I am unresponsive - perhaps you don't want
> my functionality).
>
> So my first suggestion is that one function of the PM is to be a
> single point of contact and to mentor me and shepherd me.  It would be
> great if there were a page that said "Fill out this form and send it
> to Clay." :)
>
> A second suggestion is that we use JIRA somehow.  Once you accept
> something for consideration - lets make a new JIRA category for it and
> concerns/issues get managed in JIRA - the dev list is just too big and
> unstructured to facilitate this kind of conversation - JIRA would be
> much better and it provides a natural tracking mechanism that shows my
> responsiveness and makes sure that any outstanding issue that has been
> raised is tracked until it is successfully resolved.   Effectively
> there could be "blockers" on my new software that blocked me getting
> into the trunk and if I did not fix them in a timely manner - then I
> wold not make the release.
>
> A last suggestion is to start early and give a few months between the
> time where we "apply" to be in the release and "code freeze" - this
> allows you and the PC to lok things over, give feedback and allows me
> and others to respond to your feedback.
>
> Where do I start?
>
> /Chuck
>
> On Fri, Jul 17, 2009 at 4:42 PM, Clay Fenlason <clay.fenlason at et.gatech.edu
>  > wrote:
>
> At a minimum, it was thought, any new functionality should be
> documented before it could be considered for 2.7. It was proposed that
> the "scorecard" criteria be used as a model for what the documentation
> should include. [1]  New features and capabilities would fall into one
> of two rough categories: light (eg new features to existing tools) and
> heavy (eg entire new tools). Both classes would require documentation
> in order to be considered, but lightweight additions could be reviewed
> by the release management team and the product manager without
> involving the Product Council except as a court of appeal.
> Heavyweight additions would have to be reviewed by the product
> council.
> ----------
> _______________________________________________
> 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"
>



-- 
Clay Fenlason
Director, Educational Technology
Georgia Institute of Technology
(404) 385-6644