Wiki source code of License Review Tool Requirements, Candidates and Selection
Last modified by Stefano Maffulli on 2021/08/14 00:21
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
 |
24.1 | 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 license review process in general, is distinct from the **license-discuss** mailing list, which this document does not address. |
 |
1.1 | 2 | |
| |
35.1 | 3 | The License Committee recommends contracting for services 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: |
| |
1.1 | 4 | |
| |
20.3 | 5 | Stage 1: |
| 6 | |||
| |
43.1 | 7 | * Contact and work with stakeholders to further describe business, user, non/functional, and implementation requirements for an appropriate license-review vehicle(s) (including attributes below). |
| |
20.3 | 8 | |
| 9 | ((( | ||
| 10 | Stage 2: | ||
| 11 | ))) | ||
| 12 | |||
| |
38.1 | 13 | * Implement the vehicle on an OSI-approved host, including the configuration of users/roles/permissions, integrations, data transfer, workflows, etc. in order to meet the requirements identified. |
| |
14.1 | 14 | * Document the expected process for reviewing a license and the roles of all participants in the process |
| |
8.2 | 15 | * Document the solution and any maintenance tasks so they can be handed off to a new maintainer |
| |
20.3 | 16 | |
| 17 | ((( | ||
| 18 | Stage 3: | ||
| 19 | ))) | ||
| 20 | |||
| |
38.1 | 21 | * Evaluate the 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) |
| |
1.1 | 22 | |
| |
6.1 | 23 | ((( |
| |
7.25 | 24 | The person may also be asked to: |
| |
1.1 | 25 | |
| |
19.1 | 26 | * Create a maintainable system for making machine-readable licenses available |
| 27 | * Create a complete, searchable database of all license-review emails | ||
| |
22.1 | 28 | |
| 29 | The OSI would (% style="background-color: inherit; color: inherit; font-family: inherit; font-size: inherit;" %)execute each stage in turn, retaining the option to re-evaluate or even potentially terminate the project at the end of each stage. For example, if it turns out that we cannot identify a solution at the end of Stage 1, the OSI would end the engagement. | ||
| |
6.1 | 30 | ))) |
| 31 | |||
| 32 | == Requirements for license-review process == | ||
| 33 | |||
| |
8.2 | 34 | ==== Must have ==== |
| |
6.1 | 35 | |
| |
2.1 | 36 | * Ability to submit a license for review |
| |
6.1 | 37 | * Being able to immediately identify the current state of review for a license (eg. "approved", "rejected", "new", "being redrafted", "invalid", "rejected", etc.) |
| |
19.1 | 38 | * 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.) |
| |
20.2 | 39 | * Ability to comment on specific sections/words/lines of a given draft of license. (Sections of licenses that have been revised are areas of interest) |
| |
19.1 | 40 | * Ability to comment on a license in a general sense |
| |
12.1 | 41 | * Ability to moderate discussions (including removing comments, editing comments, banning users) |
| |
15.1 | 42 | * Ability to close the process with the publication of an accompanying rationale document |
| |
20.2 | 43 | * Discussions must be publicly accessible, without authentication |
| |
13.1 | 44 | * Users must authenticate and maintain a consistent identity in order to comment/participate in the process |
| |
6.1 | 45 | * Time-stamping of all comments and submissions |
| 46 | * Entirely separate discussions for each license | ||
| |
21.1 | 47 | * Discussions must be archiveable and available to reference through linking |
| |
12.1 | 48 | * Easy to learn and use by non-technical users |
| |
19.1 | 49 | * Must not assume experience with specific technical tools (i.e. requirement to use Git, XML, or a specific programming language, etc.) |
| |
32.1 | 50 | * Tools are principally open source |
| |
6.1 | 51 | |
| |
8.2 | 52 | ((( |
| |
6.1 | 53 | |
| |
8.2 | 54 | ))) |
| |
6.1 | 55 | |
| |
8.2 | 56 | ==== Nice to have ==== |
| |
6.1 | 57 | |
| 58 | * Ability to cross-reference a different comment in the same or different discussion | ||
| |
15.1 | 59 | * Searchable discussions |
| |
2.1 | 60 | * Canonical URIs for each license for review |
| |
11.1 | 61 | * Machine-readable output from the license review process (text of the license + metadata such as Author, Date approved, Link to discussion, etc.) |
| |
10.1 | 62 | * Low administrative overhead/hosted service (OSI does not have a good track record of hosting/maintaining new services) |
| 63 | * 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) | ||
| |
16.1 | 64 | * Configurable notifications in order to watch and follow discussions |
| |
17.1 | 65 | * Welcoming to new community members |
| |
14.1 | 66 | * Badges to easily identify participants to provide context (e.g. OSI board members, long-time community participants, etc.) |
| |
6.1 | 67 | * Not mandatory to use the tool in order to participate in review, i.e., system integrates with an email workflow |