Page Comparison

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.