Looks like the fetch from github failed, so the progress bar and release notes are missing.

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.

@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)

See discussion here: #15

We can discuss alternatives:

• dev
• net
• org
• com

I think dev is cool, but project is not only about developers. So maybe org would be nicer.

@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 should move the registry from OpenTracing to this site, and enhance it if needed.

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):

• v0.1
• v0.2
• v0.3
• v0.4
• beta
• rc
• v1.0

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:

• In the website repository, make a PR that modifies data/progress_source.yaml and adds a new entry to the data collection in that file.
• Be sure to follow the format of the other entries exactly - the 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!

We need a place to collect OSS learning resources (workshop slides, sample apps, etc.) on the page.

The page on how to get involved is, quite sadly, bare! (https://opentelemetry.io/get-involved/) We need to add content here -

• Links to each SIG
• Links to the community repo
• Links to the website repo
• Code of conduct
• Links to public calendar (maybe even a widget?)
• Etc.

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?)

Information about downloading hugo and running the website locally is missing.

Just making sure folks can find what they need.

Why, tho?

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)

tl;dr: There are a few significant issues with the .io TLD.

• Political issues: There are some political concerns around the .io registry that many people feel strongly about. All debate about the actual concerns aside, it seems unnecessary to alienate users and potential users of OpenTelemetry by using a .io URL when we're in a great position to use something else, e.g., opentelemetry.dev.
• Security: This article explains a vulnerability in which a researcher hijacked nameservers, which would allow rogue redirection
• Support: As discussed here, it sounds like the registry itself has pretty rough support

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.

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.

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:

https://docs.google.com/presentation/d/1CyBn74KtRMQCMMKLl4ckIfopsdHUL9owVWIGfvMeQSg/edit#slide=id.g6ecdd256ae_0_5

TIA for any feedback!

This is a thread to collect things that we'd like to see done to the website in a more 'big picture' sense.

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/

• Sidebar feels to far from the left edge
• Content is too far from the sidebar.
• Content registration is different depending on whether the sidebar is present. It "jumps" to the left when the sidebar appears.

Does what it says on the tin...

The project status page has a link to the milestone document in GitHub, but the text should be updated to reflect these milestones.

We need to create initial documentation for tracing. It should include -

• A quick start guide that includes information such as:
  • Initialize/configure the tracer.
  • Create a span, add attributes/events, finish the span.
  • Propagate the trace context to another process over HTTP.
  • Propagate the trace context inside the process.
• API documentation, or a link to the API documentation if it exists somewhere else.

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 a 60 day lock on the domain that @bogdandrutu picked up

CNCF/LF use namecheap so we will have to wait.

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 display the release notes (cribbed from GH Releases) for each SIG on the project status page.

We need to create initial documentation for tracing. It should include -

• A quick start guide that includes information such as:
  • Initialize/configure the tracer.
  • Create a span, add attributes/events, finish the span.
  • Propagate the trace context to another process over HTTP.
  • Propagate the trace context inside the process.
• API documentation, or a link to the API documentation if it exists somewhere else.

We need to create initial documentation for tracing. It should include -

• A quick start guide that includes information such as:
  • Initialize/configure the tracer.
  • Create a span, add attributes/events, finish the span.
  • Propagate the trace context to another process over HTTP.
  • Propagate the trace context inside the process.
• API documentation, or a link to the API documentation if it exists somewhere else.

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?

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

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.

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.

We need to create initial documentation for tracing. It should include -

• A quick start guide that includes information such as:
  • Initialize/configure the tracer.
  • Create a span, add attributes/events, finish the span.
  • Propagate the trace context to another process over HTTP.
  • Propagate the trace context inside the process.
• API documentation, or a link to the API documentation if it exists somewhere else.

We need to create initial documentation for tracing. It should include -

• A quick start guide that includes information such as:
  • Initialize/configure the tracer.
  • Create a span, add attributes/events, finish the span.
  • Propagate the trace context to another process over HTTP.
  • Propagate the trace context inside the process.
• API documentation, or a link to the API documentation if it exists somewhere else.

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.

Need to reword the about page so that it:

• Focuses more on the project rather than the scope / industry
• Better reflects the beta status
• Move "Get Involved" content to this page
• Link to CNCF branding page

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.

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?

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 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.

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

The documentation page should pull README data from each language.