Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

We also made some decisions around the shape of the radar and the next steps in the process.

Approaches

  1. Combine

    1. Combine listing of tools into

    description of
    1. the single 'technique' that they support.

    2. Combine or exclude blips that only a small percentage of engineers need to know about. For example, engineers are consumers of all the coverage and linting tools. They don't need to know about each one we use and don't use. They can be listed within a description, if needed.

    3. Combine blips where one is an important subset of the other, or a sub-technology integral to the adoption of the other.

  2. Remove

    1. Remove blips that are obvious and can be taken for granted. (eg Django).

    2. Remove blips that are not used in the platform at all right now. If the idea is a consideration for the future, have it first be prototyped with a provisional OEP. Exception: If it's a commonly asked question of our opinion on it and we've made a decision against it, consider including it.

  3. Move

    1. Move blips that are abstracted away by cookie-cutters or Open edX APIs (since those choices are made for developers) to the 2nd tier Radar.

    2. Move blips that developers need not know about within their first 30 days to the 2nd tier Radar.

Decisions

  • Tiers of Radars.

    • 1st tier includes information that we expect developers will want to know within 1st 30 days.

    • 2nd tier includes additional decisions to learn post-30 days.

    • 3rd tier includes edX.org-specific decisions.

  • Rings. Align name of rings with status of OEPs. We want to update OEP-1 to remove the "Final" state and clarify the difference between Provisional and Accepted. We also want to add a description for the "Adopted" state we propose using in the Tech Radar.

    Tiers of Radars.

  • 1st tier includes information that we expect developers will want to know within 1st 30 days.

  • 2nd tier includes additional decisions to learn post-30 days.

  • 3rd tier includes edX.org-specific decisions

    .

  • Descriptions Next. We'll write blip descriptions first, then use that additional context to determine what ring it belongs in.

  • Quadrants. Our quadrants will differ from those used by Thoughtworks. One of our quadrants should be "Open edX Technologies" and include technologies specific to the Open edX ecosystem. The "Techniques" quadrant from Thoughtworks radar feels appropriate for ours, so we will use it. The remaining two quadrants are currently differentiate between "BackendFrontend" and "Frontend"specific technologies and “Technologies” in general, reflecting the natural divisions in our code-base.

We then populated a spreadsheet with all of our blips and set the quadrants appropriately, and the rings to “Hold” pending Step 8. https://docs.google.com/spreadsheets/d/1ntg2fy7EBR0TFGktyORyv3W-K1bOmhr5Z4EU6WzdSWE/edit#gid=0

(tick) Step 7: Descriptions (Spreadsheet)

This is our current step. The goal of this process is to generate descriptions for all of the blips on the radar. We believe that we will more accurately categorize blips into rings equipped with descriptions of what each blip is, and what it means - qualitatively - to the Open edX platform. We intend to do this collaboratively in the Tech Radar spreadsheet. Participants can sign up to be an Author or Reviewer of a blip description.

(tick) Step 8: Rings

Once we have had descriptions of our blips, it’s time to categorize we categorized them into rings by their level of adoption. We haven’t chosen a process for this step yet. One proposal is to use a set of Google Surveys to ask participants to assign a ring to each blip and optionally give a rationale.This was done by a small group for expediency, and then submitted for review from a broader audience to catch any discrepancies.

(tick) Step 9: Publish!

We want to share our Technology Radar with the broader Open edX community to help onboard and educate everyone about our technology stack. As part of our broader information architecture goals, we expect to be prominently linking to the Tech Radar from our documentation. New engineers should be familiar with the technologies in the “Primary Radar” within their first 30 days.

➡️ Step 10: Iterate

Once we’ve published the radar, that’s not the end. As we all know, technology continues to change constantly, and our Tech Radar will be both the vehicle for how we adapt to changes in technology, as well as our outward expression of those decisions.

...

Our rings are intended to correspond to OEP states. The “Adopted” state is a new addition identifying those technologies that are not only Accepted - a comparatively low bar for an OEP - but thriving and recommended. The intention is to update OEP-1: OEP Purpose and Guidelines to adjust the states to map onto the rings in our radar.

Adopted

Technologies we have high confidence in to serve our purpose, also at large scale. Technologies with a usage culture and established best practices in our production environment, low risk, and which are recommended for widespread use.

Accepted

Technologies that we have seen work with success in projects and solve real problems; we have serious usage experience with them that confirmed their benefits and uncovered limitations. New projects may want to seriously evaluate using these technologies when considering options. These technologies are slightly more risky; some engineers in our organization walked this path and will share knowledge and experiences.

Provisional

Technologies that are promising and have clear potential value-add for us; technologies worth an initial investment of research and prototyping efforts to see if it has impact. These technologies have higher risks; they are often brand new and/or highly unproven in our organization. You will find some engineers that have knowledge in the technology and promote it, you may even find teams that have started a prototyping effort.

DEPR / Hold

Technologies not recommended to be used for new projects, but may already exist in the code base. Technologies that we think are either not (yet) worth (further) investment, or have been proven to be inadequate or directionally inappropriate for the platform. These technologies should not be used for new projects, but usually can be continued for existing projects. Many will have corresponding DEPR tickets in Jira describing their sunset timeline.

Quadrants (To be Finalized)

...