-
Notifications
You must be signed in to change notification settings - Fork 254
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Publish an official project roadmap #1312
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mtwo thank you for doing this!
That said, no good deed goes unpunished :)
I have two pieces of meta-feedback...
- cosmetic meta-feedback: can we use a table for the heart of the roadmap? easier for my brain to understand, especially when looking across different aspects of the project...
- more significant process feedback: I almost guarantee this will fall out of date unless there is a process to revisit and revise this doc every X months... can we agree on the update cadence and include it in the doc itself? I like the idea of "quarterly" with updates requiring a roundtrip with the maintainers for each SIG, but that's just me.
Thanks again!
I also like the idea of quarterly. I would combine this responsibility with @tedsuo's project management proposal. The process I have in mind looks something like this: Each active project has have a charter approved by the TC which states project goals, timeline, scope, and leadership. The roadmap is simply a list of project charters with their expected start and completion dates (as specified in the charter). Each quarter there is a deadline for charter submission, a deadline for the TC to approve, reject, defer, or provide feedback, a second submission deadline to address TC feedback, and a final approval/rejection/deferral deadline. Charters which are already in progress would have a lighter weight quarterly renewal process where they provide a status report and optionally propose changes to the existing charter. If a project is stalled, abandoned, or otherwise should not continue its charter is simply not renewed by the TC. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made some suggestions to replace "instrumentation package" with "instrumentation library"
Co-authored-by: Juraci Paixão Kröhling <juraci.github@kroehling.de>
Co-authored-by: Severin Neumann <severin.neumann@altmuehlnet.de>
Co-authored-by: Severin Neumann <severin.neumann@altmuehlnet.de>
Co-authored-by: Severin Neumann <severin.neumann@altmuehlnet.de>
All-in-all, this looks really good. Something I’ve missed. Thinking about the format, when using the roadmap after the first time, you’d need to scroll down quite a lot to find the actual features. It would be useful to additionally have a more visual format (like a table @bhs mentioned) which you can easily create links to and copy to a slide to present. The roadmap could also include links to the corresponding project board issues for more details. |
In hindsight, I agree. I propose that we merge this as-is (the contents of the roadmap itself isn't going to change), and then I or someone else can update it with a table version when we have time. Does that sound ok? |
Yes, good plan! |
This is an attempt to catalog existing workstreams and combine this with the results of the roadmap brainstorming sessions that we held at the last two Kubecon events, so that we can better broadcast the project's major workstreams and releases to community members and to the people who use or follow OpenTelemetry.
Please comment and propose edits as your see fit!
Closes #871