Updated as per idpy Board guidance

no substantive changes to the incident response plan; added test coverage, incident response pointer, and license information to adding projects to idpy

Author: hlflanagan

idpy-incidentresponse.md

@@ -1,6 +1,8 @@
 # Security Incident Response Plan for Identity Python-governed Projects
 
-## DRAFT - Version 0.5 2021-02-02
+## Version 0.5 2021-02-02
+
+_Approved by the idpy Board on 18 March 2021_
 
 The following details the steps and actions that we should consider when
 responding to security issues related to projects governed by the Identity

idpy-projects.md

@@ -8,12 +8,14 @@ Scope: Programme
 
 Authors: Flanagan, H.
 
-Date: DRAFT - February 2021
+Date: March 2021
 
 Canonical copy available at <https://dracc.commonsconservancy.org/0025/>
 
 Copyright: This document is copyright: The Commons Conservancy and IdentityPython. It can be used under a Creative Commons Attribution 4.0 International license.
 
+*Updated on 18 March 2021*
+
 # Project addition
 
 ## Proposal format
@@ -48,9 +50,11 @@ Projects under the IdentityPython banner should include and support the followin
 * projects should include documentation posted on readthedocs.io
 * projects should follow semantic versioning as described at semver.org
 * new releases should include change logs
-* projects should include code tests
+* projects should include code tests with approximately 80% coverage of the code base
 * projects should add templates for issues and pull requests (see for example <https://github.com/IdentityPython/SATOSA/blob/master/issue_template.md> and <https://github.com/IdentityPython/SATOSA/blob/master/pull_request_template.md>.
 
+Should any security vulnerabilities be found in any idpy code base, the Identity Python [Incident Response Plan](https://github.com/IdentityPython/Governance/blob/master/idpy-incidentresponse.md) must be followed.
+
 ## People quality
 
 This is a lot harder to judge, but very important. The community is vital to the organisation’s lifecycle. Growing the organisation means growing the community and accepting more people in its core. While we cannot prevent people from fighting over (many times even non-) technical aspects, we can make a priority to make the community feel safe. Thus we must take notice of how communicative the new project’s maintainers are, what the project’s culture is, and whether this fits to the form of the environment we want to create - an environment where people are polite and try to understand rather than dominate.
@@ -69,6 +73,16 @@ The same way we require a project to be in a certain form to be accepted, the sa
 
 To put it in another way, the organisation should help its project move forward, and give tools and services to the community. If it is in a state that is struggling, then accepting a new project does not help neither party.
 
+## IPR and License
+
+As noted in the Identity Python statues [DRACC 0024],
+
+> All software and content created or maintained within IdentityPython is to be
+> made publicly available perpetually at no cost under one of the licenses on
+> the Free Software Foundation's list of "recommended copyleft licenses" or any
+> license approved by the Open Source Initiative on or after the submission
+> date.
+
 ## Discussion and consensus
 
 Everyone should do their homework, go through this list and then decide whether they think it is a good idea and timing to accept the project. While a message outlining their basic reasoning is wanted, a simple +1 or -1 should suffice.