I’m happy to announce that we’ve got the Tech Radar almost complete! A small group of us got together over the past two weeks and finished cleaning up and reviewing the “blip” descriptions. We also chose the placement of the “blips” along the “rings” (as a reminder, the rings are Adopted, Accepted, Provisional, and Hold/DEPR - defined here).
Our ask is that you - yes, you! - take about 5 minutes and look over the interactive Open edX Tech Radar. Skim through the four quadrants and see how the placement of each blip feels to you. If you have any feedback, please leave it here in this thread, or reach out to me on Slack.
Finally thank you to @djoy and @nimisha for all their hard work getting this process off the ground, and for continuing to see this through to completion.
Ah yes. @djoy was messing around with how we serve up the content on GitHub - that is now the correct link. Note that the new link has FOUR radars present - we’re only concerned with judging the Primary radar. Thanks for pointing that out!
Thanks a lot @sarina. I went into each of the blips and the placement of the blips feels right to me. Even if there are blips that I would want to have in different rings. To me they are an accurate representation of where the open edX landscape and community currently are.
Thank you for bringing this over the line. Unlike Thoughtworks’ Tech Radar that denotes movement of industry adoptions and trends, the Open edX Tech Radar is intended to be an evolving source of truth of community-wide technical decisions. Other organizations have also adopted this technique and I hope it will serve its long-term purpose for this community.
A meta-comment for future consideration: It’s a little odd to me that things like software frameworks like “Django”, servers like “MySQL”, and low level tools like “isort” are all living at the same level. The tech radar is great at tracking what’s new and what’s stabilizing–definitely useful information, but I don’t think it’s as good a format for laying out what the default path should be.
If the goal is to quickly answer, “I’m building a new THING. How should I build my THING?”, it might be clearer if we gave that story in stacks for certain use cases like “backend application” or “documentation”. For instance:
This shifts the emphasis away from the maturity of solution (“are ADRs Accepted or Adopted?”), and instead focuses it on the default path for particular use cases (“document architectural decisions with ADRs”).
Definitely agree @regis - Tutor would be good to add.
@dave I don’t think you’re wrong here, but I’m hesitiant - when we’re at the point, after 3 months of work, where we really want to publish this and iterate as people use it - to blow up the structure. I’m also not sure how that structure works with the Thoughtworks format - are you proposing this would be four differently-named rings, or a new, non-Thoughtworks format altogether?
To both of you, it would be easy to make a PR to address the things you see as needing improvement (especially simply adding a blip). I have less time than thought this week to do incorporate any improvements so PRs would be very welcome. Tag me on them.
Sorry, I should have been clearer. When I said “for future consideration”, I meant, “let’s consider this the next time we’re looking at re-doing the tech radar”, not “let’s scrap what we have now and do this instead”. I whole-heartedly agree that we should get a version of this completed in its current format as quickly as we can.
This would be a new, non-Thoughtworks format. Probably just a series of tables of Default Choices. The two aren’t really in conflict–they’d just be emphasizing different aspects. So I can always generate that documentation based on the radar later, without blocking anything.