launchpad-dev team mailing list archive

[curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

On 11/09/2011 06:50 PM, Martin Pool wrote:
> On 10 November 2011 00:27, Matthew Revell <matthew.revell@xxxxxxxxxxxxx> wrote:
>> Hey Curtis,
>>
>> On 8 November 2011 18:38, curtis Hovey <curtis.hovey@xxxxxxxxxxxxx> wrote:
>>
>>> At UDS, Laura Czajkowski ask me about how Launchpad could solve the
>>> problem where membership in a team is contingent on a signed code of
>>> conduct. This issue is not a priority for Lp stakeholders, and the
>>> implementation of the feature is complex. I think this feature would be
>>> valuable to several Lp communities and it might be developed in
>>> collaboration.
>>
>> As we've discussed, I think this is precisely the sort of feature that
>> will have benefits for the Ubuntu community and that is ideal for
>> community contributors to work on.
> 
> I wonder how we can make this easy for them to work on: perhaps
> finding someone who cares and Curtis or someone else can mentor them.
> 
>>> Do new versions always require new signing?
>>
>> Yes and no.
>>
>> If I were signing a new paper contract, I would expect that my consent
>> applied to the exact version I were signing.
> 
> Correct.

That is not what happen today with the Ubuntu CoC. This is largely
because we do support the case where a revision is uploaded. We have a
hack in the code that make the changed version appear to be compatible,
but the dates of the CoC and the signing are clearly in disagreement.

The only way to sign the current CoC is to delete your previous signing.

>> Even if the changes are
>> only to correct typos, I would consider myself bound only by the
>> version I'd signed. Whether that'd hold up in law, I dunno, but we can
>> be better than lawyers, right? :)
>>
>> However, wrt Canonical's contributor agreement, I believe that we're
>> happy for people who signed an earlier version to remain contributors
>> to Canonical's open source projects, despite our having a more recent
>> version of the agreement.
> 
> Also correct.
> 
>> So, I think it depends on whether the team admins would expect that
>> team members are bound by new versions. My instinct is that we should
>> make this an option but I'd feel happier if we researched this.
> 
> If it was a situation where people need to sign the new one, then
> presumably that would mean that membership is disabled for people who
> signed the agreement and who have not yet signed the new one.  This
> seems like it would be disruptive.
> 
> Perhaps we start by saying just that you must sign to join the team,
> and then you stay in the team.  Then if it turns out that a particular
> team really does want to get everyone to update to the current
> agreement, they can handle that out of band: get a list through the ui
> or api of people who signed old agreements, tell them, perhaps with
> some reminders, and then after a grace period they can remove them
> from the team.  Then if it turns out this really does happen often, we
> can look at adding a feature to lp to automate the process.

I too was thinking of something like this. So long as Lp allow me to
query/see who has not signed, I, as a team admin, can run a script to
send emails to deactivate membership.


-- 
Curtis Hovey
http://launchpad.net/~sinzui

Attachment: signature.asc
Description: OpenPGP digital signature