-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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 the specification via opentelemetry.io #852
Comments
@chalin Per your note elsewhere, I will raise this with the GC today. |
@chalin I'm live-blogging the GC meeting that's happening right now :) You're welcome to check the recording, but the consensus is that, while we want the website to be the first port of call for end-users, we want to have a single source of truth for the spec and that must be GitHub. We will continue to push end-user getting-started docs/etc into OTel.io, though, as that will be better for the adopter community. |
@bhs we could pull the specification in via submodule if we wanted to have a single source of truth. |
Right! We're one step ahead already: the spec is already a submodule of this repo: see in https://github.com/open-telemetry/opentelemetry.io/tree/main/content-modules. |
As a first step, we should add a 'Specification' category to the left nav in |
@bhs - other than the obvious SEO benefit, hosting the spec on the website gives us the ability to do redirects: as the spec evolves over time, and pages or sections get moved or renamed, the website redirects can ensure that readers don't get 404s. This isn't something you get when linking directly to GH pages. |
Couple things need to be clarified:
|
Good questions. I'd suggest starting with the latest-stable version (no experimental). |
I'm good with posting a copy of the spec to the website as long as it gets updated automatically, and requests to edit go to the main spec docs rather than editing a fork. |
Thanks for the feedback @lizthegrey!
If that's what y'all prefer, it can be setup.
That's already working. For example, try the Edit page link of the following page: https://deploy-preview-866--opentelemetry.netlify.app/docs/specification/overview/ |
My only note (besides agreeing that it should be the latest stable version, which is released once a month) is that unless the change is a minor clarification, updating the spec is done through OTEPs. I'm not sure adding an "update this page" conveys the gravity of making a spec change. That makes it look too much like a doc change on the website. I don't believe we should provide that feature for the spec, we are not encouraging spec PRs without issues being opened first or OTEPs being created. |
I agree with @tedsuo. It's fine to have a link to the source page in the spec, without making it an Edit link. |
I chatted with bhs as well; The concern was specifically about synchronization issues. I'm going to summarize what I think the key blockers are here:
|
Looking at the layout, I also suggest that the spec should not be listed so prominently in our documentation. The spec is not intended to be end user documentation; I'm concerned that it will be distracting and confusing to list it at the top of the navigation, as that implies that it is a primary resource for end users which they need to read. Users should never have to read the spec to make use of OTel. |
Perhaps it should be under 'concepts'? |
Ok. Under the new IA (once it is defined via #770), I would imagine that it would make sense to have a Reference section, with the spec under that. Until we have a new IA I can I can think of a these options:
Thoughts? |
I like option 3. |
Option 3 sounds good |
@tedsuo @austinlparker et al - Done:
PTAL https://deploy-preview-866--opentelemetry.netlify.app/docs/reference/specification/ |
Since we've addressed the issues raised here outside of automation (which would take a bit to solve in a generalized fashion), we'll commit to a one business day turnaround for updates when new spec releases are cut from notification. With that in mind, unless there are other blockers we'll be merging #866 next Tuesday. |
Closed by #866 |
The spec is a core OTel resource, and as such it should be published through this repo. (#833)
The text was updated successfully, but these errors were encountered: