Wiki source code of License Review Tool Requirements, Candidates, and Selection
Version 19.1 by Chris Lamb on 2020/04/25 16:46
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. Note that the license-review list and corresponding that license review process in general is related yet distinct from the license-discuss mailing list, which this document does address further. | ||
| 2 | |||
| 3 | The License Committee recommends hiring a person to aid in the identification and implementation of a better workflow for the review of licenses. We have decided that the current email-based system (Mailman) is inadequate as 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 attributes below | ||
| 6 | * Implement the vehicle on an OSI-approved host | ||
| 7 | * Document the expected process for reviewing a license and the roles of all participants in the process | ||
| 8 | * Document the solution and any maintenance tasks so they can be handed off to a new maintainer | ||
| 9 | * 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) | ||
| 10 | |||
| 11 | ((( | ||
| 12 | The person may also be asked to: | ||
| 13 | |||
| 14 | * Create a maintainable system for making machine-readable licenses available | ||
| 15 | * Create a complete, searchable database of all license-review emails | ||
| 16 | ))) | ||
| 17 | |||
| 18 | == Requirements for license-review process == | ||
| 19 | |||
| 20 | ==== Must have ==== | ||
| 21 | |||
| 22 | * Ability to submit a license for review | ||
| 23 | * Being able to immediately identify the current state of review for a license (eg. "approved", "rejected", "new", "being redrafted", "invalid", "rejected", etc.) | ||
| 24 | * Ability to submit updated revisions of a license, without destroying previous ones or associated history. (Licenses often go through multiple rounds of revisions or drafts based on feedback received.) | ||
| 25 | * Ability to comment on specific sections/words/lines of a given draft of license. (Sections of licenses that have been revised are, by that very fact, areas of interest) | ||
| 26 | * Ability to comment on a license in a general sense | ||
| 27 | * Ability to moderate discussions (including removing comments, editing comments, banning users) | ||
| 28 | * Ability to close the process with the publication of an accompanying rationale document | ||
| 29 | * Discussions must be publicly accessible, ie. without authentication | ||
| 30 | * Users must authenticate and maintain a consistent identity in order to comment/participate in the process | ||
| 31 | * Time-stamping of all comments and submissions | ||
| 32 | * Entirely separate discussions for each license | ||
| 33 | * Discussions must be archiveable and available to reference | ||
| 34 | * Easy to learn and use by non-technical users | ||
| 35 | * Must not assume experience with specific technical tools (i.e. requirement to use Git, XML, or a specific programming language, etc.) | ||
| 36 | * Tools should be open source | ||
| 37 | |||
| 38 | ((( | ||
| 39 | |||
| 40 | ))) | ||
| 41 | |||
| 42 | ==== Nice to have ==== | ||
| 43 | |||
| 44 | * Ability to cross-reference a different comment in the same or different discussion | ||
| 45 | * Searchable discussions | ||
| 46 | * Canonical URIs for each license for review | ||
| 47 | * Machine-readable output from the license review process (text of the license + metadata such as Author, Date approved, Link to discussion, etc.) | ||
| 48 | * Low administrative overhead/hosted service (OSI does not have a good track record of hosting/maintaining new services) | ||
| 49 | * 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) | ||
| 50 | * Configurable notifications in order to watch and follow discussions | ||
| 51 | * Welcoming to new community members | ||
| 52 | * Badges to easily identify participants to provide context (e.g. OSI board members, long-time community participants, etc.) | ||
| 53 | * Not mandatory to use the tool in order to participate in review, i.e., system integrates with an email workflow |