[License-review] exploring tracking tool for license-review

Allison Randal allison at opensource.org
Fri May 13 21:40:22 UTC 2016


On 05/13/2016 04:29 PM, Christopher Sean Morrison wrote:
> 
> On the surface, these labels still seem to overlap to me or require documentation instead of being obvious.  I think that will likely be confusing to the reviewers and submitters alike in the long run.  The problem stems from mixing indicators for current state and current action.  It needs to stick with one or the other strictly so that they are more clear, or embrace both more consistently.  I suggest something like this:
> 
> OPEN - NEW UNREVIEWED LICENSE
> OPEN - REVISED AWAITING REVIEW
> 
> PENDING - UNDER DISCUSSION
> PENDING - MINOR CHANGES REQUESTED
> PENDING - MAJOR CHANGES REQUESTED
> PENDING - AWAITING VOTE
> 
> CLOSED - INVALID
> CLOSED - REJECTED
> CLOSED - ACCEPTED
> CLOSED - WITHDRAWN
> 
> When it’s OPEN, it’s in the legal team’s court waiting on them to review.  When it’s PENDING, the submitter can make changes (returning it to OPEN) or withdraw (CLOSED).  When it’s CLOSED, it’s no longer under consideration.
> 
> Ideally feedback is provided on all CLOSED that explains the determination.  INVALID is to weed out anything that does not qualify as a license submission (e.g., not a license, unknown provenance, fake authorship, etc.).  REJECTED and ACCEPTED submissions went to vote and did not or did pass respectively.  WITHDRAWN is self-evident.

Ah, I should explain further. The status names are the headers on the
Kanban board. Each status has additional attributes associated with it
(which are visible on the detail page), configured for the project:

- OPEN/CLOSED
- ARCHIVED

Further, each Kanban card can contain tasks, which have another set of
status names we can define, and are also OPEN/CLOSED. So, the main set
of statuses don't need to capture every detail on the type of action
required. Things like whether major or minor changes are requested can
be specified as tasks instead.

So, with that level of detail, and in the interest of keeping the
headers on the Kanban board readable, I'd modify your list more like like:

OPEN - NEW
OPEN - UNDER DISCUSSION
OPEN - CHANGES REQUESTED
OPEN - AWAITING VOTE

CLOSED - ACCEPTED
CLOSED - REJECTED

CLOSED+ARCHIVED - INVALID
CLOSED+ARCHIVED - WITHDRAWN

As a status name, INVALID is vague enough that I've seen it become
problematic in other issue trackers. Entries that aren't actually
license submissions can just be deleted. For the most part, submissions
that aren't accepted will either be REJECTED or WITHDRAWN, though some
will be rejected without ever going to vote. Maybe STALLED is a better
third option, noting a submission in a state where it can't be ACCEPTED,
where the submitter hasn't WITHDRAWN it, and where it wasn't REJECTED so
there's some potential it could be revised and resubmitted at some point.


> If it can be set up such that the submitter is able to change status (at least to OPEN - REVISED AWAITING REVIEW), the Kanban transitions should operate much more smoothly (and with less burden on the legal team).  Alternatively, we could eliminate the second OPEN status and require all revisions be submitted anew with the former getting WITHDRAWN.

We have the granularity to set up different types of users, and grant
them access to update cards or task. But, once they have the permission,
it applies to all cards or tasks in the License Review project, so we
might not want to be handing that out to everyone who submits a license.
Also, we might not want to force all the license submitters to figure
out our tracking system anyway, it's easy enough for us to update the
tracker as a result of communicating with the submitter.

Allison



More information about the License-review mailing list