launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

Thanks for looking at this; it would be nice to improve it for the
contributor agreement.

There is already an ISD project towards turning the harmony CA in to
some kind of web form.  You needn't block on them but at some point
Canonical needs to decide which one it will use.

It would be good if the signing can generally be just a click through
rather than a gpg dance, which does not seem to give any more legal or
technical security.  Your text below seems to imply people will paste
in the signed agreement and this gives a window by which they can
modify it.  That doesn't seem useful either.

> Can a team have more than one concurrent agreement?

The CA has separate 'natural person' and corporate forms.  But I guess
we would handle the corporate form by some external mechanism then
have an admin add the whole team (see below.)

My short answer would be no: make a second team if you need that.  We
can add it later if we must.

Admins should probably be able to bypass the mechanism, possibly with a warning.

> Do new versions always require new signing?

Again I think no, people can make a separate team.

> How do team admins know that users need to sign an agreement.

Won't it be obvious on the team page?

> Do users need to assign the agreement /before/ being approved, during
> approval, or after approval?

Is there any problem with them doing it before?

> Can I add a team to a team that has an agreement? Who signs?

Yes, it should be possible, because it lets us model corporate
agreements: xyzcorp signs the corporate CA and then ~xyz-staff is
added.

I think only the admin of the being-joined team can do this, and the
onus is on them to be sure it's reasonable.

Other questions:

 * If someone quits a team, must they re-sign to rejoin?  I think yes.

 * Do they get a warning before quitting a team with an agreement?  I
don't think it's needed.

>
>
> Example agreements
> ------------------
>
>    * Code of Conduct
>    * Contributor/ownership agreement
>
>
> Required information to operate
> -------------------------------
>
> class CodeOfConduct:
>    implements(ICodeOfConduct)
>
>    name = Attribute("The short name of the agreement used for URLs.")
>    dispaly_name = Attribute("The name of the agreement used in text.")

I realize this is the normal pattern in lp but for some types of
objects I think having two or more names just causes confusion: people
don't understand what to put in which.  Look at the random names on
ppas.  Could we get by with just a single name, eg 'harmony-2.0'.

>    version = Attribute("The version of the agreement.")
>    is_current = Attribute("is this the current version of the
>        agreement.")
>    datereleased = Attribute("The date the version was released.")
>    content = Attribute("The content of the signed agreement.")

s//Text of the agreement/

This probably needs to be presented with links clickable, in case they
go out to pdf forms, privacy policies, etc.

>    active = Attribute("Is this agreement signable.")
>
> The SignedCodeOfConduct will need to know the team and the agreement
> that was signed

I would not call the class CodeOfConduct, because that is too strongly
associated with one specific instance.  Think about calling it
something like MembershipAgreement.


>
>
> About Ubuntu's Code of Conduct
> ------------------------------
>
> The principle block to permitting teams to have agreements is the
> lack of Lp infrastructure to support them. The Ubuntu code of conduct is
> not extensible, it does not even support revisions to the CoC properly. The
> problem is hinted at in one bug.
>
>    CoC implementation needs to be revisited
>    https://bugs.launchpad.net/launchpad/+bug/54945
>
> The specific issue is that the Ubuntu CoC is a file on the launchpad
> code tree. There can be only one. It is not associated with a team. The
> actual Ubuntu agreement is a file in the Launchpad tree. The model class
> constructs an instance/version by loading a configuration that is hard
> coded in python and the agreement file on disk.
>
> This mechanism is not extensible for team agreements. Teams cannot add
> files to the launchpad tree and there is no mechanism to indicate the
> version or the team that it applied too.
>
>
> Refactoring the Ubuntu CoC so that is can be extended
> -----------------------------------------------------
>
> Since the Ubuntu CoC is not extensible, we may want to create team
> agreements as a separate feature, but solving the existing problem will
> ensure the design is general enough to be reused.
>
>    * We want a mechanism where agreements can be uploaded to launchpad
>      by users.
>    * User can upload a version that supersedes a previous agreement.
>      * The agreement may need to invalidate previous signed agreements.
>      * The agreement may be a minor revision/correction that is
>        existing signed agreements are valid.
>
> Does the Ubuntu CoC need a team to work? Are the signers a member of a
> team? Are there advantages to formally making the Ubuntu CoC signers a
> team, such as knowing who has signed?

I think new agreements are added rarely enough that this feature will
be valuable even if the first version requires losa intervention to
add one.

>
>
> Proposed steps to support team agreements
> -----------------------------------------
>
>    * Add db/librarian support to store team agreements.
>    * Migrate the Ubuntu agreement into the db/librarian.

Why Librarian?

>    * Create a new model to access the agreement.
>    * Update the existing signed agreements to know the team and
>      agreement that was signed.
>    * Add UI to upload an agreement.

As I say, I don't think that's needed right at the start, and perhaps
it's easier to shake it down just with some semi-hard-coded cases like
the CA.  I would focus on just adding the db tables, and then doing
click-through signing to get membership, and then go from there.

>    * Update the UI to retrieve an agreement to support teams
>    * Update the UI to upload a signed agreement to support teams
>    * Update the membership invite email
>    * Add UI to edit an agreement's metadata.
>    * Update the add member code to always send invitation emails
>      instead of adding the user immediately.
>    * Update the team invitation to explain there is an agreement and a
>      link to download it, and instructions about how to sign.
>    * Update the accept invitation form to also upload the signed
>      agreement.
>    * Update the team members view to show that the user has signed the
>      current agreement.
>    * Update the edit membership view to show the state of the signed
>      agreement.
>    * Add support send an email to members when the current agreement is
>      updated.

>    * Maybe update the upload signed agreement  form to do better error
>      checking and fixing since many user corrupt the data pasting it
>      into to form.