Closed alolita closed 1 year ago
bhs
commented
3 years ago IMO this is the single biggest execution gap we have as a project (especially if it's a roadmap we are actually committed to from a resourcing and timeline perspective)... and the lack of a detailed roadmap also hinders adoption in the short term. Huge +1.
I'm most interested in the "short roadmap of big things", at least from a GC perspective.
tigrannajaryan
commented
3 years ago I think having a published roadmap would be very valuable. Some SIGs/repos have their own roadmaps or milestones defined, but I think a summary roadmap for the entire project would be still useful to have.
One challenge here is probably going to be the maintenance of the roadmap to make sure we keep it up to date, unless someone commits to do periodic grooming and refreshing of the roadmap (probably easy to do for the high-level GC roadmap which changes slowly).
alolita
commented
3 years ago @tigrannajaryan I do this grooming and refreshing for several components today. I'd be happy to lead this effort to work closely with the TC on the detailed roadmap as well as maintain the high-level GC roadmap.
sharrmander
commented
3 years ago I believe this status and roadmap topic is vitally important to make the project more accessible for early adopters.
I chatted with an OTel end user today and asked them what their company would like to see with respect to an 'at-a-glance' roadmap. They immediately self-identified a gantt chart and wished to see a "one page view" that outlined every SDK and their current status w.r.t. tracing/metrics/logging implementation (using green if stable, red if not) and estimated timeline to declare stability. The end user uses multiple language SDKs and has been getting this information through CNCF slack channels.
From my perspective, I've also gravitated towards gantt-like charts in google sheets to represent similar information for my companies agents. I sketched out what I think would be helpful for OTel and was surprised to see it was more like a table with dates written instead of visualized gantt-style.
tigrannajaryan
commented
3 years ago "one page view" that outlined every SDK and their current status w.r.t. tracing/metrics/logging implementation
Technically the compliance matrix is that one view but it may be too detailed / too long to understand the big picture at a glance. Maybe a different representation or coarser granularity of items can help. The current matrix is targeted more to the Otel community to help keep track of the progress and is likely not very well suited for the occasional visitors.
sharrmander
commented
3 years ago Technically the compliance matrix is that one view but it may be too detailed / too long to understand the big picture at a glance.
Yes, I think that compliance matrix is too low level. When I think one page I imagine a single page without the need to scroll. To elaborate on that table style sketch I did - it is a combination of a visualization the top half of this page + a table of languages and their status with reference to the various specifications/timelines to stability.
sharrmander
commented
3 years ago I think we it would be worthwhile to capture the main questions we want a roadmap to answer so that we can design to those questions. For example my end-user (observability group architect) wants to know ~"When can I trust the .NET SDK's metrics stability enough to introduce the project to one of my engineering teams without them having a lot of changes to navigate?"
A question I want to answer is "When will the OpenTelemetry project reach "GA" state so that I can organize our marketing efforts to align with the project?" or perhaps more realistically "As a vendor, when should I start initiating marketing workflows to highlight our platform compatibilities with OpenTelemetry?"
jsuereth
commented
3 years ago A question I want to answer is "When will the OpenTelemetry project reach "GA" state so that I can organize our marketing efforts to align with the project?" or perhaps more realistically "As a vendor, when should I start initiating marketing workflows to highlight our platform compatibilities with OpenTelemetry?"
The project has gone with a "stabilize a signal and move to the next" style approach, even with instrumentation + components. I don't think there will be an overall "GA" anymore, instead I think you'll see "Metrics are ready", "Logs are ready", "XYZ is ready" type announcements over time. I totally understand this concern though (and share it). I'll be working w/ @alolita as the TC representative to get an outline on the roadmap/state of open telemetry and get individual owners of efforts to comment.
They immediately self-identified a gantt chart and wished to see a "one page view" that outlined every SDK and their current status w.r.t. tracing/metrics/logging implementation (using green if stable, red if not) and estimated timeline to declare stability. The end user uses multiple language SDKs and has been getting this information through CNCF slack channels.
I'm not sure we can provide such a gantt chart effectively, due (in some part) to the nature of OSS. Specifically, while some contributors have assured funding and known timelines, some contributions come from independent sources, and with unknown timelines. OpenTelemetry is quite open, so it's hard to lock down someone's time/focus + attention. That said, where we DO know time/focus/attention for core contributors, we should provide such a view (and we'll see what we can do).
bhs
commented
3 years ago I'm not sure we can provide such a gantt chart effectively, due (in some part) to the nature of OSS.
There is certainly some truth to this, and we've heard many variations on this theme over the years, but there is also something to be said for well-understood timelines informing scope (rather than well-understood scope informing timelines).
I would perhaps point to something like Ubuntu's 6mo release cadence as prior art, though admittedly it's also totally different (being a distro rather than a standards-ish project).
I do recognize that I'm basically suggesting a different way of running the project, but given that we're arguably 18mo behind schedule and yet continue to add more scope to OTel, we may greatly benefit from a forcing function that reduces the scope creep temptation.
jsuereth
commented
3 years ago @bhs - I hear what you're saying. We could do scoped releases but then we need to be able to cut features. We have been taking that approach to specification work (we cut features from the specification). However, when it's about language compliance against a specification, there is no ability to cut feature work :). We're doing what we can.
jsuereth
commented
3 years ago Putting this in its own comment, here's the start (outline with basic overview and lots of TODOs to fill out from the communty) of a roadmap + state of otel as of 2021 Q4 - https://docs.google.com/document/d/1aR44ErKLPfJLBQBiDIolWs8vM2WBpjGxIi5siGj9CcY/edit#
cc @alolita for help on this.
Also, if you're willing to contribute content to this, please request write access with what you'd like to contribute and I'll add you with write privileges.
In my discussions with end-users and developers, a question I get asked often is about the OpenTelemetry roadmap, release plan and what's in development. It is tough for people who do not participate in the project day-to-day to get an at-a-glance update of the project's development roadmap and progress. I point them to opentelemetry.io/status and the feedback I've received is that they would like to see a version that is more "management friendly". Perhaps this could be represented by a Gantt chart or a bar chart.
I'd like to see a roadmap for the project posted on GitHub, perhaps in this Community repo, which gives me a At-a-Glance snapshot which is updated on a bi-weekly basis.
Examples of other open source project release roadmaps are:
The GC could help maintain this high-level at-a-glance roadmap. The TC could maintain a more detailed release plan.
Would love to hear what other contributors think. Please +1 if you think this would be useful.