[sakai2-tcc] Captcha support 2.8 for new accounts (Roll Call vote in effect)
May, Megan Marie
mmmay at indiana.edu
Tue Sep 28 08:32:08 PDT 2010
Looks like Seth and I were sending mail at the same time (although mine was hung in my outbox). I will defer to Seth's direction on the roll call
~Me
From: sakai2-tcc-bounces at collab.sakaiproject.org [mailto:sakai2-tcc-bounces at collab.sakaiproject.org] On Behalf Of May, Megan Marie
Sent: Tuesday, September 28, 2010 11:14 AM
To: Anthony Whyte; Noah Botimer; Jean-Francois Leveque
Cc: sakai2-tcc at collab.sakaiproject.org Committee; Alan Berg
Subject: Re: [sakai2-tcc] Captcha support 2.8 for new accounts (Roll Call vote in effect)
Hi all,
Some quick comments as I'm pressed for time today
- Alan, I think you should find someone other than yourself to test this. (I hear there are some folks from Marist will to aid in this area ;-) ). My 2 cents is that the community outside of this group needs to become more engaged in testing for 2.8
- We need to follow our governance procedures. As Stephen pointed out, it's time for a roll call active TCC members.
Let's begin that now and end in 24 hours.
Thanks,
Megan
From: sakai2-tcc-bounces at collab.sakaiproject.org [mailto:sakai2-tcc-bounces at collab.sakaiproject.org] On Behalf Of Anthony Whyte
Sent: Tuesday, September 28, 2010 9:12 AM
To: Noah Botimer; Jean-Francois Leveque
Cc: sakai2-tcc at collab.sakaiproject.org Committee; Alan Berg
Subject: Re: [sakai2-tcc] Captcha support 2.8 for new accounts
Comments Inline.
On Sep 28, 2010, at 4:42 AM, Jean-Francois Leveque wrote:
1. Are we sure all the code provided won't be used at all by default?
Look here: http://jira.sakaiproject.org/browse/SAK-12489?page=com.atlassian.jira.plugin.ext.subversion%3Asubversion-commits-tabpanel
UsersAction.java. . .
Boolean systemEnabled = ServerConfigurationService.getBoolean("recaptcha.enabled", false);
Boolean toolEnabled = Boolean.parseBoolean(config.getInitParameter("recaptcha-enabled", "false"));
Boolean enabled = systemEnabled && toolEnabled;
if (enabled)
. . .
2. Who in QA will test it? Is all else covered?
Alan Berg. "Is all else covered"--what's else? If you mean, does it have a test plan, looks like not yet. Have the new properties been added to default.sakai.properties in trunk--not yet.
3. Time will run out quickly, as far as I can remember from previous releases and their quality.
We want to time to run out quickly. :) As for quality, the 2.7 release cycle was shorter than the 2.6 release cycle with no apparent loss in quality. The goal for 2.8 is to shorten the release cycle still further, again with no loss in quality. I doubt adding captcha as a new feature will impair the timeline.
4. I know lots of things have been expected for a long time but this is not a criterion for me in the case of a late merge.
We should evaluate each proposed new feature on its merits, risk, etc. We missed this one. Is that sufficient justification to dismiss it for another year? I say no. If we can work a new feature into a release under known circumstances we should not fear to do it.
Flexibility is regarded as a virtue; Inflexibility is not. The TCC should aim to be flexible.
Is more than one person in one institution outside the MT gonna support this for at least one year?
Overkill in my opinion. The criteria you cite was originally framed with regard to tool additions. This is a new feature of modest proportions added to an existing tool, one supported by the MT. For this particular commit (r82537) I'd argue it went into maintenance mode the second after it was committed.
Cheers,
Anth
On Sep 28, 2010, at 9:01 AM, Noah Botimer wrote:
I agree with this and will add that we had a significant lack of clarity around 2.8 until near/after the conference. It was not an appropriately measured process throughout, so a bit of careful subjectivity will serve us well. This doesn't mean anything goes; just that we gathered to bring together good judgment and progressively add the structure that we saw lacking.
Feature identification, work, ramp down, and freeze were simply not on the calendar long or specifically enough for everything that we should ship to be handled 100%. If we see a very hard-nosed release in our future, now is the time to start that process with clear milestones -- for some release beyond 2.8.
Thanks,
-Noah
On Sep 28, 2010, at 4:51 AM, Berg, Alan wrote:
If the code is in Alpha 2, I will volunteer to test it.
The biggest risk for Sakai 2.X is that we don't evolve the product fast enough. That is why I am happy with profile2, sitestates, BasicLTI and feature changes. Change does'nt make QA's life easy, but thats not the point.
Alan
Alan Berg
QA Director - The Sakai Foundation
Senior Developer / Quality Assurance
Group Education and Research Services
Central Computer Services
University of Amsterdam
http://home.uva.nl/a.m.berg
________________________________________
From: sakai2-tcc-bounces at collab.sakaiproject.org<mailto:sakai2-tcc-bounces at collab.sakaiproject.org> [sakai2-tcc-bounces at collab.sakaiproject.org] on behalf of Jean-Francois Leveque [jean-francois.leveque at upmc.fr]
Sent: 28 September 2010 10:42
To: Anthony Whyte
Cc: sakai2-tcc at collab.sakaiproject.org<mailto:sakai2-tcc at collab.sakaiproject.org> Committee
Subject: Re: [sakai2-tcc] Captcha support 2.8 for new accounts
1. Are we sure all the code provided won't be used at all by default?
2. Who in QA will test it? Is all else covered?
3. Time will run out quickly, as far as I can remember from previous
releases and their quality.
4. I know lots of things have been expected for a long time but this is
not a criterion for me in the case of a late merge.
Is more than one person in one institution outside the MT gonna support
this for at least one year?
I have no problems giving time to get votes contradicting me. Maybe I'm
playing it too safe.
Cheers,
J-F
Anthony Whyte a écrit :
JFL objection:
"-1 because we are past the code freeze/branching and this might slow down the process."
Jean-Francois, would you be willing to withdraw your -1 vote? As I noted in my +1 vote:
1. It's off by default which helps mitigate risk.
2. QA supports inclusion.
3. We have branched in mid-September, not mid-November; we have time before the XMas holidays to test it
4. It does not appear "rushed" to me. Expedited after a long lag seems to me the more appropriate description.
I doubt adding captcha support will slow down the process. But that's my opinion and it may not be shared by others.
However, if -1 holds I propose we hold a roll call vote on this one. This is a feature that we should have added long ago.
Cheers,
Anthony
On Sep 27, 2010, at 6:55 PM, Steve Swinsburg wrote:
Hi all,
Apologies for the lateness of this summation (long weekend), but voting is now closed. We had 4 explicit +1 votes from TCC members, one implicit +1 from myself (in making the proposal), and one -1 vote. Considering the -1 vote and in accordance with our charter, action is now blocked.
I am not sure how we should proceed. Our charter says this can be overridden with a 2/3 majority roll call, but I will defer to our humble and wise TCC leaders Seth and Megan.
cheers,
Steve
On 22/09/2010, at 2:52 PM, Steve Swinsburg wrote:
Committed to trunk (2.9)
I propose that this goes into 2.8. Voting is now open and will close at midnight on Friday the 24th September 2010 (US EST).
As per the Sakai 2 TCC Governance (http://confluence.sakaiproject.org/display/TCC/Home) voting is by lazy consensus, or you may nominate a +1, 0 or -1 vote. -1 votes must be accompanied by a detailed explanation. A single -1 vote based on a material objection will block action. However, -1 blocking votes can be overridden by a 2/3 majority roll call vote of active TCC members.
cheers,
Steve
p.s. Thanks very much to Alan for picking this up and to Chuck for reviewing. Well done!
On 22/09/2010, at 2:31 PM, csev wrote:
I just tested this and it is fine - I added some commentary to the JIRA:
http://jira.sakaiproject.org/browse/SAK-12489
I recommend Steve that you commit it to trunk (2.9-SNAPSHOT as of a few hours ago) and let the TCC contemplate if it can go into 2-8-x as it sees fit. If it does wait until 2.9, then at least this way it does not languish in JIRA for three more years.
I would also note that Alan originally proposed this for inclusion, Steve agreed, and now I agree. So that makes 2.1 TCC votes for inclusion already (given that most people discount everything I say).
/Chuck
On Sep 21, 2010, at 8:01 PM, Steve Swinsburg wrote:
Ok I've reviewed this and it looks good.
I've attached an updated patch to the JIRA that works in trunk, as well as a screenshot.
I would *really* like to see this in even though it slipped the documentation dates.
It is disabled by default.
cheers,
Steve
_______________________________________________
sakai2-tcc mailing list
sakai2-tcc at collab.sakaiproject.org<mailto:sakai2-tcc at collab.sakaiproject.org>
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
_______________________________________________
sakai2-tcc mailing list
sakai2-tcc at collab.sakaiproject.org<mailto:sakai2-tcc at collab.sakaiproject.org>
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20100928/03a4c174/attachment-0001.html
More information about the sakai2-tcc
mailing list