github/balanced-employee-ip-agreement

Prior Art: Reviewers Editions

kemitchell opened this issue · 1 comments

kemitchell commented

Noticed the "versioning" bit in CONTRIBUTING. Folks may be interested in the "Reviewers Edition" system I cooked up for functional prose:

https://www.npmjs.com/package/reviewers-edition-parse

The intended use case was legal forms on commonform.org, but I've applied it to tagged releases on GitHub, as well.

For those coming from SemVer:

  1. No x.y.z software-style numbers, but still machine-readable. SemVer-looking version numbers applied to functional prose can't mean what SemVer says they mean. Versions with different meaning ought to look different.
  2. No 0.y.z "hole" in the semantics.
  3. Direct focus on the message intended from maintainers to consumers, rather than vague functional criteria that only get fuzzier when applied to prose, rather than code. New Reviewers Editions tell users what they should review and assess, based on the Reviewers Edition of the copy they're already using.
mlinksva commented

Thanks for pointing out this prior art. It is very close to the twist on SemVer we came up with:

BEIPA CONTRIBUTING Reviewers Editions
MAJOR version when objectives of agreement change. A company using BEIPA would have to fully evaluate a new major version to determine fit. When authors recommend users review a new edition in its entirety to ensure it meets their needs, they increase the edition number.
MINOR version when agreement changes do not change objectives of agreement but are substantial enough to merit legal scrutiny from any user. When authors recommend users review at least the new or changed parts of a new edition, they increase the update number.
PATCH version for corrections which any user would likely want to accept with minimal additional review. When authors make only typographic or other, minor corrections that users need not review, they increase the correction number.

I like your take because it's more general, and even more accurate for the potential version 2 of BEIPA (the objectives haven't really changed, but it is a big enough change to fully re-evaluate).

I'm not really thrilled with lack of 0 and .. The result, eg BEIPA 2e or eventually BEIPA 2e1u5c and similar looks really foreign, or rather computer-y and maybe (ironically) not intended for consumption by most humans, though I appreciate the direct focus on the message.

Maybe we should use your definitions but stick with SemVer formatting. 🤔