Date

Feb 22, 2016

Quorum

Roll Call

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

Mark Lizar (Unlicensed) - Update wiki with revised method for agenda creation -
Mark Lizar (Unlicensed) work on timeline and roadmap for v1 - and present next week
John Wunderlich iainh1 NA (Unlicensed)Former user (Deleted)Mark Lizar (Unlicensed) Homework - look at examples of previous specs - like Tim Berners - URI, the ICAL format, Email, etc as examlples of do's and don't for spec dev. look at and discuss issues. . (from respective perspecitves)
John Wunderlich iainh1 NA (Unlicensed)Former user (Deleted)Mark Lizar (Unlicensed) --> proposal for offline discussion - if someone needs more time on an agenda item, then that person can table this issue to the next meeting, (1 week) before being discuss on the agenda

Browser not supported