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.