2016-02-22 MVCR - Meeting Minutes + Call Agenda Housekeeping
Date
Feb 22, 2016
Quorum
Roll Call
@Mark Lizar (Unlicensed)
@iainh1 NA (Unlicensed)
@John Wunderlich
@Former user (Deleted)
Read In Minutes for Approval
Action Item Review
(moving forward in agenda)
New Items -
problems with skype,
Mark sent msg to Oliver to troubleshoot
Discuss Call Agenda Creation Workflow
Item 1 - Agenda Workflow
Mark posted suggested workflow to Github - as prep for agenda discussion
suggesting process for capturing issues and discussion points and adding these to wiki and agenda by priority
working with consensus items on calls in order to expidite Spec Dev.
we discuss the json being a part of the main MVCR.
John No - should go in to appendix
Mark Yes - its not that simple.. partially yes, we can seprate it , but difinively no to moving out of spec into appendix
Mary Yes
like the logic of having the JSN filelds makes sens in opening technical side or use, at least as example
good to take time and ask opinions of people with experience
Mary - what would the questions be to others? how do we involve others?
should the consent receipt be a policy format agnostic to any format like JSON
should the consent receipt have a framework as a suggestion, recommened with caveat that any others can be made.
What examples should we look at ?
calendar
mac, yahoo, msft
micro formats
Pop-SMTP
Do Not Track
Ad-Blocker
Cookie implementations
number of instances in the existing formats - how (in what way) to pick what micros format for the fields -
bottom up is the date and time example
suggests looking at five.
Iain
marketers want a spec - and common standard. No competitors to this yet, we need to get it out.
- as long as it delivers a minimum viable policy for implementation - lets get it done
ineeds an output simple marketing language
needs to be able to be used as a marketing tool. (business requirements)
(everyone agree's)
Mary - Brought up Uber as interested in the consent receipt and UST
may be able to get implementaton wth them
Mark Suggest that spec can have the guidance for the policy of putting a receipt in any format or a single format be open, (and still be compliant with MVCR spec) while also, using a common JSON format for example and development of v.1 - (as apart of main spec) for help with implementation, needed to make MVCR useful for inter-op. (which is a key priority)
asking can this can be done via a table in main spec as (default example)
we ta tabled this issue for github and asking advice
going forward- general proposal
use call time to go through fields and write spec to consensus. (5 min max to discuss item/5 min to write item as issue)
if we have an issue or discussion item, (5 min to record it/5 to discuss it )
(notes)
Try to bring issues you might have for the spec up on the list before the call so that we can have best chance of dealing with issues in consensus on the call
all items that people need time on can be tabled for one week. (upon request)
************* Notes - Here are the Agenda for Calls Houskeeping
# Current MVCR Call & Dev Plan & Agenda:
**MVCR Call Agenda**
1. 1. Start using Github and move to Github from MVCR project management (done)
1. 2. Clean up and remove text via call, move around data to fields (done)
1. 3. Walk through and review fields, clean these up (done: issues created) Created issue
1. 4. CR Header Fields
1. 5. Data Controller Fields
1. 4. Purpose Specification table, fields and documentation
1. 5. PII collected & Sensitive Data Categories Specification table, fields and documentation - [Issues #12](https://github.com/KantaraInitiative/CISWG/issues/12)
1. 6. Sharing
1. 7. Extension (optional items that may be required in some circumstances but are not always required, listed with the section and description)
**Priority Field Item Discussion/Issues**
1. [Issue #15](https://github.com/KantaraInitiative/CISWG/issues/15) - (Mark recommends tabling this issue until the last item of the priority fields, providing most time to consider issue as possible)
2. [Issue #14](https://github.com/KantaraInitiative/CISWG/issues/14) - Header Field Addition : Consent Type
**All other issues/discussions by priority or order of appearance. **
(check issues list)
Objective: finish the work of the spec and adopt changes on the call that we can get as near to 0.8 as possible.
Method: Go through and focus on the fields and their definitions, put them in a table and clean them up.
As v0.7 was accepted by the workgroup, we are working as a group via calls and from consensus to update the specification to version 8.
- if there is any disagreement about the spec - we create an issue in git hub and then added in priority to the agenda.
First fixing up what we agree on, collecting all disagreements or possible issues and creating a Github issue. Each Github issue is a single item, the issue must have a clear title and description of what needs to be addressed.
- All issues can then be worked on asynchronously and then once resolved added put into the current version via a call.
Note: The aim is not redo work that has already been approved in v0.7 but to work by leveraging our current point of consensus to get as much done with this consensus as possible saving all non-consensus work until the core fields are completed updated as far as we can. Then field issues are addressed in the priority lists, then all other issues and discussion are raised by priority until we have a consensus built v0.8.
Once Core work Items are finished then the Agenda will be filled by priority first/ then order of appearance.
(Note: To make an item a priority - just ask for it to be on the list. )
Action Items