Does everything need to get code reviewed?
ADR for Studio/LMS boundaries.
ADR for Role of XBlock.
Open edX: Time-based releases (4-month cadence).
This is routinely asked in feedback on the security training course; I'm in the process of composing a FAQ and would like to hear opinions from the group on this one.
Small doesn’t necessarily mean innocuous. But being explicit about what kind of small changes we’re okay with would be better than a blanket "trust the developer" statement. For example:
Typos in strings
(Note: this is specifically for non-PCI-scope - there will be a separate FAQ for PCI-scope)
PCI = Payment Card Industry
Standard for data security that all organizations must follow if they access card-holder data.
edX’s PCI Scope
Impetus was for PCI - so took the opportunity to provide a guideline
What should be guidelines for code reviews?
Trust Judgment - Responsibility of the coder to decide what review and how many reviewers they need to feel confident before merging.
Note: coder may not know whether they need a review (unconscious incompetence)
This should be accompanied by guardrails since there are always exceptions when a seemingly innocuous change can have significance
Still Inform - Communicate post defacto of merging - ensure the team or someone else was notified
What are reviews for?
@Ben Holt (Deactivated) will put together a proposal, may return for further input/feedback
Security working group + policy group will make the final decision and update course
Still to be decided: cutoff boundary for XBlocks at Unit-level or at Component-level
Note: Blockstore would be able to support either level
Content and Settings scopes are stored in MongoDB
User scopes are stored in Django models
Lesson learned: overusing scopes for different usages that have different life cycles
Lesson learned: overused XBlocks for navigation layer
But, rationale: came in super handy when rapid prototyping
FYI: Coursera's Plugin API
May have a wider impact on other teams - since it impacts where data sits
For example: boundary between Cohorts (LMS concept) and Content Groups (Studio concept)
Idea: do the same for other boundaries, like LMS versus eCommerce, like LMS versus Discovery
For example: boundary between LMS (content access) and Discovery (enrollment / track / etc)
Would like to return to time-based releases.
This is opposed to feature-based releases.
The last one (Juniper) was 17-month release.
We are proposing a 4-month cadence (so 3x a year)
So this means, Koa would get cut in October. Lilac would get cut in February.
Note: Ubuntu upgrade - will want to coordinate a consistent version
How does this affect the DEPR process?
How does this affect our support process? (supporting 1 version back)
Ideas: Community could possibly backport security fixes to previous versions.
How can we support multiple versions of the OS for the native installation?
Idea: Transition Native to a containerized production installation.