Currently, when a popover is open, the only way to close it is to click on the "x" button. Better UX would be to close the popovers on any click outside the popover.

Currently, PRs have a status check which builds a preview environment. Yay! But the only way to get to it is to click the "Details" link on the check. That's a bit hard to discover. Let's also post a comment into the discussion that makes it clearer the preview is available.

Currently, it's just a static image of the 2019/2020 SEM/BFD. Let's create a new BFD, based on Core, which clicks through to individual capability articles.

Let's replace bitly with a dora.dev link shortener (IMHO, dora.dev is short enough to serve as a link shortener URL, esp. since the slugs get shorter).

Step 1:
Create new links for existing bitly urls

• bit.ly/dora-sodr --> dora.dev/sodr
• bit.ly/dora-fourkeys --> dora.dev/fourkeys
• bit.ly/roi-of-devops --> dora.dev/roi
• ?

Step 2:
Create a system (either a front-end or a well-documented procedure for code edits) for adding new ones.

For the boxes on the homepage, make the wee arrows into something more CTA-ish.

it's all over the place

at /research/team

It'll be more future-proof if we use a theme instead of using templates in the repo root.

Per #55 we have a contact form which submits to the firestore db in our Firebase project. But then it just sits there. We need to add a notifier to the DORA team, who can be found at dora-advocacy @ google [dot] com

This extension will probably be of use: https://extensions.dev/extensions/firebase/firestore-send-email?authuser=0&hl=en

Create a page with a contact form. Inquiries may include SODR sponsorship, talk requests, research inquiries, .... ???

Netlify supports a few options in its redirect config

...let's add some of those here, in particular:

• 301 vs 302
• splats

Add SEMs, survey questions, etc. to the research section

Add the questions used in 2022 SOD surevey

Currently, tab_navigation is a shortcode, so it can be used in .md files. But really, it belongs in template files. (See the /research/archives/ content for an example of how the tabs are specified in the markdown, but really they should be specified in the template.)

This might be useful: https://mertbakir.gitlab.io/hugo/pass-arguments-in-partials-hugo/

Currently, these are implicit in the queries used in Four Keys (as well as spelled out in words to some extent on that site). Let's put those on this site, to extract the definition from the implementation.

How can we test that the site is properly built and deployed?

• availability test: do [key pages] return status 200?
• correctness test: do [key pages] have correct content?
• latency test (probably not needed; focus on performance optimization e.g. Lighthouse)
• redirect tests

(also see #36 )

...it's weird and washed-out

Currently, the site is hosted w/ NGINX, and uses NGINX server-side redirects. After #27 , we should rebuild those as Firebase Hosting redirects, and remove the current hosting config

Implement the /resources/ section, containing (at least):

• [ ] ROI whitepaper
• [ ] Four Keys
• [ ] Accelerate Book

Which ones do we have?

On devops-research.com, the interactive BFD includes wee summaries of the capabilities. Let's port these to dora.dev, and also make a page on dora.dev that lists out all the capabilities (use devops-research.com to define "all" [don't wait on core]). The list can include the summaries (or not) and can link out to the c.g.c articles, until those are ported to dora.dev

What it is (in broad strokes)
Inquiry form

Consult Firebase documentation for any platform-specific details.

Add a snipe on the publications page pointed to /contact

The top of the (2021+) quick check results uses a simple bespoke graph, but the "performance comparison" tab uses a js library. That library's adaptability is overkill, since we're only making one-dimensional graphs with well-known parameters. Let's replace the library with a bespoke dealie (though: consider DRYing it out into a partial).

In the menu, add the links for all items ("Community", "Capabilities", etc.)

Twitter @devops_research
YouTube playlist: https://www.youtube.com/playlist?list=PLIivdWyY5sqIcFlX94XzycCzssTEkyQ1Q

linkedin.com/company/devops-research-and-assessment/

Hugo's "bundle" concept encourages one to put all assets related to a specific section into that section's folder within content (at least, that's how I understand it). This seems cleaner than dumping everything into /static. Let's investigate.

All content on this site is licensed by Google LLC under [CC BY-NC-SA 4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/), unless otherwise specified.

On mobile, columnar FTW

Currently it's wicked wide on mobile.

// TODO: move #modal styles into `widgets.css` (but leave quickcheck-specific bits here)

undefined

• unit tests for javascript
• E2E user journey tests

AIUI, best practice is generally to avoid URLs with ".html" in them. So we'll use paths like /research/, rather than /research.html

...but existing links go to /research.html so we'll need to redirect those. Redirects can be added to firebase.json

Hugo supports taxonomies -- we could use this to make a taxonomy for capabilities. Maybe other things too?

For inquiries including:

• research collaboration
• sponsorship
• workshops/assessments
• ?

SCSS processing requires the "extended" release of Hugo. Update the CI builder to use it.

At launch, we will redirect all traffic from devops-research.com/* to dora.dev/* ... and then, most of the paths will need to be further rewritten to confirm to new URL patterns.

These intra-site redirects are configured in firebase.json (examples).

We need to add redirects for all current paths on the legacy site.

Establish i18n framework and translate content. See https://www.regisphilibert.com/blog/2018/08/hugo-multilingual-part-1-managing-content-translation/