Plan Legalpad v2
Open, LowPublic


We're close to unbetaing Legalpad for upstream use (see T3116). For now, it's primarily useful for tracking CLAs for open source projects.

From T3116, some features which might be good in the next iteration or two:

  • Versioning/Updates: Particularly, requiring users to re-sign after a major update. We have some support for this in the DB, but I scaled back a bit of the logic to make it easier to get a cohesive v1 out. When we do build this, I'd like to give editors more control over minor (typo fix, translation error, updated link) vs major (requires resignature) changes. It's not clear anyone needs this yet.
  • Internationalization: See discussion in T5257. WMF would like this.
  • Proxy Documents/Signatures: We occasionally have contributors who want to send us an out-of-band document rather than sign the Facebook CLA. Although I think this is mostly users who don't have a Facebook account and don't want one, or whose employers have some issue with Facebook, we (or other installs) may have similar issues in the future. It might be nice to let editors say "although use X has not signed this document, they've signed an equivalent, which is good enough to bypass checks elsewhere in the application". This would probably be a Signature object with a special flag and a new editor workflow. A similar case might be proxy documents, where signing a "Corporate CLA" serves as a proxy for an "Individual CLA". We might need this once we start using Legalpad.
  • Annotations/Markup: We could make it easier to format documents, and to contextualize/annotate/present them so humans can understand them. We don't have a need for this yet.
  • Print Support / Email Copies: You can print the pages now and it will work OK, but it would be nice to help users retain a durable record of the document they signed. Emailing them a copy of the document could be nice, for example. We don't have a need for this yet.
  • Signature Requests: There's no way to ask someone to sign a document right now. This would be pretty simple to build and probably make a lot of stuff better/easier. We don't have a need for this yet.
  • Signature Notifications: We don't push signature notifications anywhere. If a signature responds to a request, it would probably make sense to do so, at a minimum. It might make sense to let users "watch" documents to get emailed when anyone signs them. Updating revisions when users clear document roadblocks would be nice, too. We don't have a need for this yet.
  • Actual Signature Workflow: I've scaled the actual signature process back a little bit to streamline it, but we might have some documents which require more metadata (address/phone/blood type/etc). We don't have a need for this yet.
  • Signatures as Corporations: We probably don't need this right away, but at least some users are contributing work product which is really owned by their employer, and should be signing on behalf of their employer. This is mostly an issue around the proxy stuff -- once they sign the alternate corporate CLA, we need to let them bypass the roadblocks. This would be nice to have.
  • Install ToS: Mark some set of documents as being required for all users and roadblock them on account creation until they sign. This might be nice to have.
  • Separate editor/manager permissions?: Currently, you must be able to view a document in order to view its signatures. Especially once signing requests show up, this might need to be more granular.

Some stuff which is probably further out:

  • Some kind of handshake thing where a third-party site bounces a user through Legalpad to get a proof of signature.
epriestley updated the task description. (Show Details)
epriestley raised the priority of this task from to Low.
epriestley added a project: Restricted Project.
epriestley added subscribers: epriestley, chad, btrahan, qgil.
epriestley edited this Maniphest Task.Jun 29 2014, 2:24 PM
epriestley edited this Maniphest Task.Jul 2 2014, 3:21 AM
  • Unsignable Documents: It would be nice to mark our privacy policy as not signable.
J5lx added a subscriber: J5lx.Jun 3 2015, 9:42 PM
revi added a subscriber: revi.Jun 21 2015, 7:53 AM
eadler added a project: Restricted Project.Jan 9 2016, 1:05 AM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.
enckse added a subscriber: enckse.Dec 6 2016, 10:53 PM

Just as input: Versioning/Updates would be really useful if we update our ToS for our end-users and we need them to be required to review and re-sign on change

We would be prepared to step in for prioritization on this.

One more use-case you might want to consider:

  • we sometimes have documents where we require users to read them, but we also don't want them to be blocked immediately from Phabricator when not signing them. So we'd like to allow them to postpone the signature for X times/days or until a definitive deadline until this document has to be signed.

So we'd like to allow them to postpone the signature

This is a workaround, but one possible thing you can do is set application policies to "Signers of Legalpad Document: ...".

For example, make Diffusion's "Can Use Application" policy "Signers of Legalpad Document: Employment Agreement". Then users could log in without signing, but would need to sign before they could access source code in Diffusion. This probably isn't a perfect fit if the document is "Health Insurance Policy Agreement for New Hires", of course, since that really isn't relevant to anything and just needs to be signed by a particular date.

I think it otherwise would be reasonable to build a "due date" into signature requests and maybe let the "Require Signature" option send a signature request with a particular deadline instead of immediately require a signature, although it would be nice to have duration controls elsewhere in the product first since building a "Require Signature Within: [9] days" workflow that deals with timezones correctly is probably kind of a pain.

Per T12933, we never correctly implemented versioning, which is fix, but not backfilled. If we present a "history" view like Phriction, we'll need to do this.

I think it should be possible to backfill this from the transaction record, but definitely a bit involved. Holding it until we do history (and major/minor versions) makes sense.

We might also want to make the preamble part of the separate "body" object so it gets versioned with the title and main text at the same time.