2018-10-01 OEP-0030 Review

Owned by Alexander Dusenbery
Last updated: Apr 07, 2021
2 min read

Date

Oct 1, 2018

Attendees

  • @Alexander Dusenbery @Nimisha Asthagiri (Deactivated) @Wes Mason [he / him / his] (Deactivated) @Brian Mesick (Deactivated) @Calen Pennington (Deactivated) @Troy Sankey @Jeremy Bowman (Deactivated) @Matt Tuchfarber (Deactivated) @Bill Filler (Deactivated) @David St. Germain (Deactivated) @Ned Batchelder (Deactivated) @Douglas Hall (Deactivated) @Julia Eskew (Deactivated) @Brittney Exline (Deactivated)

Goals

  • OEP-0030

Discussion items

Time

Item

Who

Notes

Time

Item

Who

Notes

Overview of the OEP

Brian

  • We talked about the responsibilities that will be expected of developers and code reviewers if this OEP is accepted.


15min

Suggestions for Annotations

Wes, Nimisha, Cale, Troy, Brian, Jeremy, Alex

  • Suggestions that we make annotations more structured to capture the fields that do contain PII, or the category of PII.

  • If an entire repo doesn’t store any PII, add documentation to the README, in English, specifying that no PII is contained there. The doc annotation tool would not run on such a repo.

  • For library dependencies that don’t store PII: possibly add a comment/annotation in the requirements.in/txt files that specify library dependencies, asserting that they (and their transitive dependencies) do not persist PII.

  • Is there some “thresholding” we can do here? e.g. every time you touch a part of code, update some number of models with annotations to get us across different thresholds of PII annotation coverage.

  • Open edX YAML and OEP-0002 checker. Is this a good place to track repo-level PII status?

2min

Resourcing for compliance with annotations

Nimisha, Wes

  • Having a metric for compliance is important, lets us have a feedback loop with management about where we’re at, where we’d like to be as an org, and relative priority.

15min

Design of Annotation Structure

Brian, Wes, Troy, Nimisha

  • Things we’re tracking: PII/no-PII, human-readable description of what the PII is, severity (maybe), and means of data retirement.

  • One proposal

.. pii:: Human Readable description .. pii_types:: email, phone (describe the type of PII being stored) .. pii_retirement:: Strategy for retirement # In the case of no PII, just do: .. no_pii [:: Option description]

Above, pii_types and pii_retirement are intended to be tags/labels that are re-usable across annotations (maybe). Breaking out a retirement section helps prevent us from committing code that does track PII but doesn’t specify a retirement strategy.

 

 

 

 

Action items

@Alexander Dusenbery Add these notes to the pull request for this OEP

Decisions