[Building Sakai] 2.7 Release Discussion - Basic LTI Portlet

[csev]

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