Legal Team/Minutes/2018-01-11 - Revision history

Brad.edmondson: /* Agenda */ wording

2018-01-12T03:07:24Z

‎Agenda: wording

Jlovejoy: /* Agenda */

2018-01-11T23:27:48Z

‎Agenda

Jlovejoy: Created page with "== Attendees == * Steve Winslow * Gary O’Neall * Jilayne Lovejoy * Brad Edmondson * Dennis Clark * Alan Tse == Agenda == 1) 3.0 release - plan to do 3.1 around end of Jan,..."

2018-01-11T23:10:59Z

Created page with "== Attendees == * Steve Winslow * Gary O’Neall * Jilayne Lovejoy * Brad Edmondson * Dennis Clark * Alan Tse == Agenda == 1) 3.0 release - plan to do 3.1 around end of Jan,..."

New page

== Attendees ==
* Steve Winslow
* Gary O’Neall
* Jilayne Lovejoy
* Brad Edmondson
* Dennis Clark
* Alan Tse

== Agenda ==
1) 3.0 release - plan to do 3.1 around end of Jan, what should we aim to tidy up?
* LLVM exception - should hear from them soon (JL has been in contact)
* assembly exception that Wayne requested - need to follow-up (JL to follow-up)
* AGPL-1.0-only and AGPL-or-later need to be added
* automated testing and deployment: any time anyone commits anything into repo (whether merged, PR, etc.) a test runs to see if it is valid (e.g.,. missing end tags, or misspelled XML tag) & will run test to run a match against license it is based on. Gary has seen a lot of the latter, this way person submitting can fix it. Typical errors to this end he’s seen are just structural (XML tags) or typos; most of matching errors are due to trying to get too fancy with alt/var tags; some are problems with tools themselves.
** only change will be that when you add a new license, you need to add text of license in
* there is also an automatic deployment PR - so that when a change is merged, it will automatically updates the license-list-data repo and then when there is a release tagged. (this will be really helpful for Gary!)
** question as to automatic tagging or review before tagging - do we want some kind of formal review of license-list-data before we way that is complete (there isn’t now)
** there is also question as to updating website - should that be automated as well? could push to preview site for every commit and then for live site for a tagged release automatically. All agreed that preview push is kind of nice, as we can see things in advance and fix weird formatting issues, but maybe hold off on automatic release for tagged releases for time being. Also consider using release candidates in between and use that for review.

* change settings as to who can merge directly / identify process of who’s doing what
** for example: tech team goes through PRs on call to decide what release and assign tasks; and then actual work done off call (for PRs). Usually have a couple people for each repo who do the actual merges - for license list repo, we probably want both legal folks and tech folks, maybe two of each: Jilayne, Brad for legal; Gary, and maybe Alexios (Gary to reach out); Dennis offered to be assigned to anything content oriented
** discuss on call anything content-related
** always add milestone, even if merge right away

other thoughts:
* should we test for broken URLs to test run? this is not part of test now, could add this later
* we might also add a note in the field list on Overview page - might be worth adding a note that we can’t control external URLs - ok to PR to do so; but need to make sure new link is actually same license and/or use web archive for original link

went through some of issues

@@ Line 23: / Line 23: @@
 Process for reviewing issues and PRs:
-* we need change settings as to who can merge directly, we had more people on this at first to get through review (not that we don't trust people, but have too many right now and some of those people aren't actively contributing at this point in time). JL to sort out, may need advice from more Github-savvy folks!
+* plan to change who can merge directly. we had more people on the XML repo at first, to get through initial review. (not that we don't trust people, but have too many right now and some of those people aren't actively contributing at this point in time.) JL to sort out, may need advice from more Github-savvy folks!
 * identify process of who’s doing what, etc. - discussed how tech team operates for its repos:
 ** each repo has main owner - in our case, we really have one and probably need designated reviewers/committers for both technical issues and legal issues, preferably at least 2 of each kind so we don't have logjams (or 3)

@@ Line 18: / Line 18: @@
 ** there is also question as to updating website - should that be automated as well? could push to preview site for every commit and then for live site for a tagged release automatically. All agreed that preview push is kind of nice, as we can see things in advance and fix weird formatting issues, but maybe hold off on automatic release for tagged releases for time being. Also consider using release candidates in between and use that for review.
-* change settings as to who can merge directly / identify process of who’s doing what
+other thoughts (that are not urgent, need to be dealt with for 3.1):
-** for example: tech team goes through PRs on call to decide what release and assign tasks; and then actual work done off call (for PRs). Usually have a couple people for each repo who do the actual merges - for license list repo, we probably want both legal folks and tech folks, maybe two of each: Jilayne, Brad for legal; Gary, and maybe Alexios (Gary to reach out); Dennis offered to be assigned to anything content oriented
+* should we test for broken URLs as part of test run? this is not part of test now, could add this later
-** discuss on call anything content-related
+** we might also add a note in the field list on Overview page that we can’t control external URLs - ok to PR to do so; but need to make sure new link is actually same license and/or use web archive for original link (may not want to dictate one over the other?)
-** always add milestone, even if merge right away
-other thoughts:
+Process for reviewing issues and PRs:
-* should we test for broken URLs to test run? this is not part of test now, could add this later
+* we need change settings as to who can merge directly, we had more people on this at first to get through review (not that we don't trust people, but have too many right now and some of those people aren't actively contributing at this point in time). JL to sort out, may need advice from more Github-savvy folks!
-* we might also add a note in the field list on Overview page - might be worth adding a note that we can’t control external URLs - ok to PR to do so; but need to make sure new link is actually same license and/or use web archive for original link
+* identify process of who’s doing what, etc. - discussed how tech team operates for its repos:
-went through some of issues
+went through some of issues open and set milestones, assigned with rest of time on call