Wiki source code of License Review Tool Requirements, Candidates, and Selection
Version 12.1 by Elana Hashman on 2020/04/24 20:29
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | The [[License Review>>url:http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org]] mailing list [[is considering>>url:http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-June/003384.html]] using a project management tool for public tracking of the license review process. This page is for collecting information related to this tool selection. | ||
| 2 | |||
| 3 | The License Committee recommends hiring a person to aid in the identification and implementation of a better workflow for license review. We have decided that the current email listserve is inadequate because it is exceedingly difficult to follow discussions, which reduces participation. The tasks that this person will undertake are: | ||
| 4 | |||
| 5 | * Identify an appropriate license-review vehicle with the below attributes | ||
| 6 | * Implement the vehicle on an OSI-approved host | ||
| 7 | * Document the solution and any maintenance tasks so they can be handed off to a new maintainer | ||
| 8 | * Evaluate feasibility of creating a complete, searchable database of all license-review emails, either incorporated into the tool or separate from the tool (currently emails are at at least three different urls) | ||
| 9 | |||
| 10 | ((( | ||
| 11 | The person may also be asked to: | ||
| 12 | |||
| 13 | * create a maintainable system for making machine-readable licenses available | ||
| 14 | * create a complete, searchable database of all license-review emails | ||
| 15 | ))) | ||
| 16 | |||
| 17 | == Requirements for license-review process == | ||
| 18 | |||
| 19 | ==== Must have ==== | ||
| 20 | |||
| 21 | * Ability to submit a license for review | ||
| 22 | * Being able to immediately identify the current state of review for a license (eg. "approved", "rejected", "new", "being redrafted", "invalid", "rejected", etc.) | ||
| 23 | * Ability to submit updated revisions of a license, without destroying previous ones or history | ||
| 24 | * Ability to comment on specific sections/words/lines of a given draft of license | ||
| 25 | * Ability to comment on a license generally | ||
| 26 | * Ability to moderate discussions (including removing comments, editing comments, banning users) | ||
| 27 | * Time-stamping of all comments and submissions | ||
| 28 | * Entirely separate discussions for each license | ||
| 29 | * Easy to learn and use by non-technical users | ||
| 30 | * Must not assume experience with specific technical tools (i.e. requirement to use git, XML, a specific programming language, etc.) | ||
| 31 | * Tools should be open source | ||
| 32 | |||
| 33 | ((( | ||
| 34 | |||
| 35 | ))) | ||
| 36 | |||
| 37 | ==== Nice to have ==== | ||
| 38 | |||
| 39 | * Ability to cross-reference a different comment in the same or different discussion | ||
| 40 | * Canonical URIs for each license for review | ||
| 41 | * Machine-readable output from the license review process (text of the license + metadata such as Author, Date approved, Link to discussion, etc.) | ||
| 42 | * Low administrative overhead/hosted service (OSI does not have a good track record of hosting/maintaining new services) | ||
| 43 | * Previous license review emails can be added so that all license reviews are in the same place (we may need to engage someone separately to complete a migration) | ||
| 44 | * Not mandatory to use the tool in order to participate in review, i.e., system integrates with an email workflow | ||
| 45 | |||
| 46 | ((( | ||
| 47 | |||
| 48 | ))) | ||
| 49 | |||
| 50 | ((( | ||
| 51 | |||
| 52 | ))) |