Show last authors
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.
2
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:
4
5 Stage 1:
6
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).
8
9 (((
10 Stage 2:
11 )))
12
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 * Document the expected process for reviewing a license and the roles of all participants in the process
15 * Document the solution and any maintenance tasks so they can be handed off to a new maintainer
16
17 (((
18 Stage 3:
19 )))
20
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)
22
23 (((
24 The person may also be asked to:
25
26 * Create a maintainable system for making machine-readable licenses available
27 * Create a complete, searchable database of all license-review emails
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.
30 )))
31
32 == Requirements for license-review process ==
33
34 ==== Must have ====
35
36 * Ability to submit a license for review
37 * Being able to immediately identify the current state of review for a license (eg. "approved", "rejected", "new", "being redrafted", "invalid", "rejected", etc.)
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.)
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)
40 * Ability to comment on a license in a general sense
41 * Ability to moderate discussions (including removing comments, editing comments, banning users)
42 * Ability to close the process with the publication of an accompanying rationale document
43 * Discussions must be publicly accessible, without authentication
44 * Users must authenticate and maintain a consistent identity in order to comment/participate in the process
45 * Time-stamping of all comments and submissions
46 * Entirely separate discussions for each license
47 * Discussions must be archiveable and available to reference through linking
48 * Easy to learn and use by non-technical users
49 * Must not assume experience with specific technical tools (i.e. requirement to use Git, XML, or a specific programming language, etc.)
50 * Tools are principally open source
51
52 (((
53
54 )))
55
56 ==== Nice to have ====
57
58 * Ability to cross-reference a different comment in the same or different discussion
59 * Searchable discussions
60 * Canonical URIs for each license for review
61 * Machine-readable output from the license review process (text of the license + metadata such as Author, Date approved, Link to discussion, etc.)
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)
64 * Configurable notifications in order to watch and follow discussions
65 * Welcoming to new community members
66 * Badges to easily identify participants to provide context (e.g. OSI board members, long-time community participants, etc.)
67 * Not mandatory to use the tool in order to participate in review, i.e., system integrates with an email workflow

Submit feedback regarding this wiki to webmaster@opensource.org

This wiki is licensed under a Creative Commons 2.0 license
XWiki 13.4.3 - Documentation