open-telemetry / opentelemetry.io Goto Github PK
View Code? Open in Web Editor NEWThe OpenTelemetry website and documentation
Home Page: https://opentelemetry.io
License: Creative Commons Attribution 4.0 International
The OpenTelemetry website and documentation
Home Page: https://opentelemetry.io
License: Creative Commons Attribution 4.0 International
We need to create initial documentation for tracing. It should include -
The project status page has a link to the milestone document in GitHub, but the text should be updated to reflect these milestones.
Need to reword the about page so that it:
@austinlparker thank you for getting the registry live!
The Find out how to add your project to the registry here!
link is broken – just wanted to record that, hopefully the fix is easy.
We will have a fair amount of content in the community and spec repos which we also want to be available directly on the website. This content needs to live in these other repos, due having a different approval process. How should it live in both places? We could copy the changes over to the website by hand, but that feels both brittle and tedious.
Since the content in all three repos is written in markdown, the simplest solution might be to just embed these other repos as submodules, along with a build script that automatically updates them to the latest commit. @lucperkins, having done this song and dance a couple of times now, do you have a preferred approach?
Information about downloading hugo and running the website locally is missing.
Update timeline to reflect the latest changes in https://github.com/open-telemetry/opentelemetry-specification/blob/master/milestones.md
If the spec is the root source of trust we could add a pointer to it in the UI.
It appears the left nav width is set to 8.3333% for all devices. This is too narrow on desktop. The bulma theme has not been updated in a while so I am not sure if we want to patch or manually adjust.
This is a thread to collect things that we'd like to see done to the website in a more 'big picture' sense.
We need to create initial documentation for tracing. It should include -
I installed hugo with homebrew, then:
❯ make serve
hugo server \
--buildDrafts \
--buildFuture
Building sites … ERROR 2020/02/11 15:42:27 Transformation failed: SCSS processing failed: file "stdin", line 16, col 1: File to import not found or unreadable: bulma/sass/utilities/initial-variables.
Built in 1484 ms
Error: Error building site: logged 1 error(s)
make: *** [serve] Error 255
Just making sure folks can find what they need.
We need a place to collect OSS learning resources (workshop slides, sample apps, etc.) on the page.
See discussion here: #15
We can discuss alternatives:
I think dev
is cool, but project is not only about developers. So maybe org
would be nicer.
tl;dr: There are a few significant issues with the .io TLD.
There's a 60 day lock on the domain that @bogdandrutu picked up
CNCF/LF use namecheap so we will have to wait.
We need a guide on how to set up Prometheus in order to see metric data from OpenTelemetry. This can be similar to the Jaeger one, just a quick start for running it locally at first.
Currently the link on the organization page (for all projects) doesn't work. It points to probably old location http://opentelemetry.dev .
The new fixed one is https://opentelemetry.netlify.com/ I assume.
In addition this project could be renamed. Maybe some domain neutral name would be good, such as opentelemetry-website
.
Similar to the quick start guides for other languages, this should be a quick start guide for deploying the OpenTelemetry Collector and configure it to accept telemetry data/export it to Jaeger/Prometheus.
We need to create initial documentation for tracing. It should include -
The rows are currently clickable, but it's not very clear that they are. We need some way to indicate that you can go to a SIG repo by clicking on its row.
Per open-telemetry/community#290, OTel is a "wide" project with many decoupled components that can and should mature on different schedules. The YAML file in that PR is an attempt to define the "schema" for maturity of both APIs and implementations across OTel.
This issue is a place to discuss how we might represent the maturity matrix on opentelemetry.io. As certain languages reach beta (and others do not), it's vitally important that OTel end-users can easily assess the maturity of the project for their environment, ideally without having to visit individual repos and try to read the tea leaves that way.
Here's an intentionally rough wireframe showing how this could look... of course we'd want a designer to clean this up before implementing, my goal here is just to get feedback about the basic approach:
If you're interested in making a counterproposal, feel free to copy-pasta any of the "slides" (sic) in this deck:
TIA for any feedback!
Currently we only have the latest blog post in the content cards, but it'd be good to have a component that was three wide and displayed 'top level' information (a link to the progress chart, for example, or highlighted videos)
Looks like the fetch from github failed, so the progress bar and release notes are missing.
Does what it says on the tin...
Navigate to https://opentelemetry.io/ and look for Status item, in the list of libraries you will see the Node.js and Javascript. I think we should only keep one, which is Javascript.
We need to create initial documentation for tracing. It should include -
Similar to the card for latest blog content, we should have a card that links to the OpenTelemetry Tuesday streams and archive. In addition, this card should have some visual assets (maybe even a logo for the stream?)
The documentation page should pull README data from each language.
We should display the release notes (cribbed from GH Releases) for each SIG on the project status page.
The OpenTelemetry website will be updating shortly (see #30 for more details) with a new feature, an automatically generated SIG progress chart. This chart is generated automatically when the site is published, using data from the GitHub API.
For existing SIGs
In order for each SIG's progress to be accurately reported, each SIG needs to create milestones that match the progress labels in the chart config. Each SIG should create milestones with the following names (note that the label can be a substring of the milestone name):
Once a milestone is completed (by that version releasing), the milestone should be closed.
For new SIGs
If a SIG is being created that wants to add its progress to the chart, the following steps should be taken:
data/progress_source.yaml
and adds a new entry to the data
collection in that file.sourceUrl
and label
fields are of special note. The sourceUrl
should be in the same format (https://github.com/open-telemetry/<repo_name>
) as the others. The label
field will be used exactly as written as the row label in the chart.If you find any issues with the chart, please open an issue in the website repository. Maintainers, please use this issue to ask any questions about creating the milestones. Thanks in advance everyone!
The project status chart re-populates information every time the site is rebuilt, we should have a trigger to re-deploy the site every day in order to get fresh data. GitHub Actions might be suitable for this, need to investigate.
There's currently a wide variety of existing OSS instrumentation available for OpenTracing (see https://opentracing.io/registry), much of which should work 'out of the box' with OpenTelemetry through a bridge. It would be great if there was a page that had a chart showing which packages had been tested and verified to work, along with any steps required to make it work.
We should move the registry from OpenTracing to this site, and enhance it if needed.
We should make these available for folks who wish to print their own stickers/swag to make it easier to get.
Ideally both RGB and CMYK versions in full color should be added. I can create the files we need, but not sure if the best bet is to put these on a "brand" page of some kind?
@lucperkins are you able to add me to the netlify team? #30 requires some build changes (need to put a API key in the env vars to pull github milestones)
The page on how to get involved is, quite sadly, bare! (https://opentelemetry.io/get-involved/) We need to add content here -
We need to create initial documentation for tracing. It should include -
The list of items in the registry top-level page isn't great for a couple of reasons:
1: Client-side search is nice but we're pretty limited in what we can easily do through the search templating. You lose the ability to do loops or whatever, for example, like you might in Hugo. Might be a way to tackle this in the JS but I'd need to look at it more, I remember having trouble with it for the original implementation of the registry on opentracing.
2: The card layout doesn't scale well. My druthers is towards something that's more of a list to increase information density.
3: The information architecture is a bit confusing. I think we should generally hew to whatever the main project is going with in terms of order/versioning, so that leaves us with a few basic categories (api, sdk, instrumentation, whatever) and a maturity schema for them (these are in-progress issues). That said, should we consider languages the primary key and roll things up under that, or should we group by type, etc. etc.?
Mostly using this thread to collect ideas/notes on what we should do, we can figure out a plan to do it later down the line.
Just feels a little pushed in.
For example, here with sidebar: https://opentelemetry.io/docs/js/metrics/
Versus here with no sidebar: https://opentelemetry.io/get-involved/
We need a quick start guide for configuring traces to be sent to the Jaeger exporter, which should also include setting up Jaeger (locally, at least?). Basically the idea is "here's what you need to do in order to run Jaeger so you can see traces" as a starting point.
Why, tho?
When loading the site on 0.58.3, the error 'Transformation failed' occurs. This appears to be a result of this hugo issue: gohugoio/hugo#6274
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.