THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx

Difference between revisions of "Legal Team/Templatizing/ReviewXML"

From SPDX Wiki
Jump to: navigation, search
Line 5: Line 5:
 
You will need to have a Github account to participate in the review.  Let Jilayne know your Github account ID to be added to the repository team.
 
You will need to have a Github account to participate in the review.  Let Jilayne know your Github account ID to be added to the repository team.
  
Key things to review before reviewing the XML files:
+
=== Key things to review before reviewing the XML files: ===
 
* SPDX License List Matching Guidelines: http://spdx.org/spdx-license-list/license-list-overview
 
* SPDX License List Matching Guidelines: http://spdx.org/spdx-license-list/license-list-overview
 
* Explanation of the SPDX License List fields: http://spdx.org/spdx-license-list/license-list-overview (at bottom of page)
 
* Explanation of the SPDX License List fields: http://spdx.org/spdx-license-list/license-list-overview (at bottom of page)
Line 14: Line 14:
 
* Using Git (on Windows): https://www.youtube.com/watch?v=nsSjT4cmVEc -- why/who needs this as pertains to process?
 
* Using Git (on Windows): https://www.youtube.com/watch?v=nsSjT4cmVEc -- why/who needs this as pertains to process?
  
Key things to look at during review:
+
=== Key things to look at during review: ===
 
# identify which parts of the license template are important or unimportant for purposes of matching (as per the Matching Guidelines), e.g., is optional tag in the right place, etc.
 
# identify which parts of the license template are important or unimportant for purposes of matching (as per the Matching Guidelines), e.g., is optional tag in the right place, etc.
 
# structural components - ensuring we have groups of clauses correctly identified (automated process takes care of most of this, but sanity check). Note that if a license does not have info for certain tags (e.g., Notes or a Standard Header) these tags won't appear in the XML  
 
# structural components - ensuring we have groups of clauses correctly identified (automated process takes care of most of this, but sanity check). Note that if a license does not have info for certain tags (e.g., Notes or a Standard Header) these tags won't appear in the XML  
Line 34: Line 34:
 
## comment in-line  
 
## comment in-line  
  
Labels created in Github: https://github.com/spdx/license-list-XML/labels
+
=== Labels created in Github ===
 +
See: https://github.com/spdx/license-list-XML/labels
 
* ''approved'' = someone looked at it, thinks it's good to go, there is nothing to review, but didn't merge it  
 
* ''approved'' = someone looked at it, thinks it's good to go, there is nothing to review, but didn't merge it  
 
* ''requires acknowledgement'' = if you find a license that requires the reproduction of specific acknowledgment text, then label it with "has acknowledgement" - for example see: https://github.com/spdx/license-list-XML/pull/279/files (if it's otherwise approved, then label with both, but do not merge it)
 
* ''requires acknowledgement'' = if you find a license that requires the reproduction of specific acknowledgment text, then label it with "has acknowledgement" - for example see: https://github.com/spdx/license-list-XML/pull/279/files (if it's otherwise approved, then label with both, but do not merge it)

Revision as of 21:54, 23 May 2016

Plan for review of XML license file

The files can be found here: https://github.com/spdx/license-list-XML

You will need to have a Github account to participate in the review. Let Jilayne know your Github account ID to be added to the repository team.

Key things to review before reviewing the XML files:

You may also want to watch:

Key things to look at during review:

  1. identify which parts of the license template are important or unimportant for purposes of matching (as per the Matching Guidelines), e.g., is optional tag in the right place, etc.
  2. structural components - ensuring we have groups of clauses correctly identified (automated process takes care of most of this, but sanity check). Note that if a license does not have info for certain tags (e.g., Notes or a Standard Header) these tags won't appear in the XML
  3. look at the labels created for other things to note whilst reviewing the licenses
  4. consider any changes that need to be made to the Matching Guidelines or License List Overview/description of fields as you go along

Process for Review

  1. go to https://github.com/spdx/license-list-XML (you need a Github account)
  2. go to pull requests (this represents all the licenses that need to be reviewed)
  3. to ensure you are working on licenses that have not been reviewed or are not being reviewed by others:
    1. filter the list using the facets on the right side by: Labels = unlabeled; and then Assignee = Assigned to nobody
    2. check off a handful of licenses you are going to work on and then Assign to yourself
  4. pick a license to review ; go to "Files changed" to view the actual file (in diff format)
  5. if everything looks good, then go back to "conversation" tab and you can either:
    1. merge the pull request if you feel confidant to do so; or
    2. leave a comment that you reviewed it and label this as "approved" - labels are found in the right side (see below for more on labels)
  6. if you see something you have a question about or think needs editing, then you can:
    1. if you want to actually edit the content, click on the pencil icon in the top right corner (you will need access to Kris' fork of this account); or
    2. comment in-line

Labels created in Github

See: https://github.com/spdx/license-list-XML/labels

  • approved = someone looked at it, thinks it's good to go, there is nothing to review, but didn't merge it
  • requires acknowledgement = if you find a license that requires the reproduction of specific acknowledgment text, then label it with "has acknowledgement" - for example see: https://github.com/spdx/license-list-XML/pull/279/files (if it's otherwise approved, then label with both, but do not merge it)
  • need legal discussion = there is a question that is legal/interpretation related that you want to discuss on the next call. leave a comment, so members of legal team review and comment in b/w calls - if 3 people agree with assessment, then no need to discuss
  • bug = if the text and substance looks good, but there is an issue with the tags only, e.g., list tags are not properly nested or some other such issue that Kris specifically needs to look at. If otherwise good to go, also add "approved" label
  • question = use if you have a question that does not fit into one of the other categories or cuts across other categories
  • help wanted = try not to use and put under one of other categories
  • has self-referring numbering = no longer in use