Perhaps I've been working in big tech too long, but I find OKRs (Objectives and Key Results) to be a useful goal setting tool in my professional life. For me they're way better than the infinite flavours of Agile. I've internalised them to the point where I try to use them for my Open Source work, and I've been doing so for the last 2 years. Instead of keeping them to myself I figured I'm egotistical enough to share them; hopefully if you're reading this you'll be interested in stuff I'm working on and we can work together on it!

WTF is an OKR?

If you don't have big tech brain worms you might be wondering what an OKR is. As opposed to weekly/fortnightly sprints, every fiscal quarter a team sets a set of Objectives they wish to achieve, that are measured by Key Results - a quantifiable or verifiable rubric that gives verification and exit criteria for the Objective. Similar to Agile Sprints, the given OKRs will be distributed among the team (in my experience 1-3 engineers will be tasked with 1 OKR for the entire fiscal quarter, and a team might have 2-4 OKRs). The goal is to end the quarter having completed the Objective, as measured by the Key Result.

Open Source moves a little bit slower than the corporate world, so my Open Source OKRs happen on a 6 month cadence (not least because the majority of this will be done in my free time). I also find I work best with multiple OKRs, where I can dip in and out to sustain energy (if one project stalls or I lose energy, I just move onto the next).

With that said here are my priority ordered Open Source OKRs for the next 6 months, from November 2023 to April 2024:

Objective 1: Ship "Invokers" proposal to all major browsers

My job working on the Primer Design System for GitHub has lead me to spending time with the Open UI team, a standards community group tasked with extending the Web to provide useful new primitives common to Design Systems. Under the guidance of some great mentors like Mason and Scott (among others), I proposed Invokers, which will give <button> elements superpowers to be able to control interactive elements like <dialog>s.

This work actually began 6 months ago in April 2023, when I set out to resolve an issue I filed in 2018, asking for a way to open modal Dialogs without JS. My (not published) April-November OKRs were to try and land a proposal to fix this issue, which resulted in a mini proposal for dialogTargetElement, concerns were raised about it not being generic enough, and so that proposal evolved into the Invokers Proposal.

For the next 6 months, my aim is to continue this work to its conclusion, by getting implementations in all the browsers and write the formal specifications. To be clear, a lot of this work is underway. For example some of the implementation is already in Chrome Canary, and "intents to prototype" have been filed for Chrome, and Firefox. Luckily I have three fantastic colleagues helping me here; Tyler, a colleague at GitHub, is working on the Chrome implementation with me. Lindsey, a colleague at GitHub, has been working on the WebKit implementation with me. Additionally Luke, a colleague on the Open UI team, has been improving the proposal and working on the Chrome implementation.

A shoutout to GitHub here, who give their engineers the space and flexibility to make contributions to open source as individuals.

Key Results:

• invoketarget & invokeaction (feature flag opt in may be required) can open <dialog> elements without JavaScript in the 3 main browsers - Safari, Firefox, Chrome.
• The major elements requiring the above are specified in the HTML standard (minimimally: open PRs to the WHATWG standard ✅, maximally: merged PRs).
• MDN documentation PRs filed for the featureset ✅.

Objective 2: Ship "CustomStateSet" proposal to all major browsers

I've been a huge fan of native Web Components, and use them daily in my professional and personal projects. GitHub uses Web Components extensively among a whole host of other companies. Before joining GitHub class based React components were my go to, but then things got weird. When my colleagues at GitHub put Web Components in front of me I saw all the strengths that originally switched me onto React, I was hooked!

Web Components are not trouble free though; cross browser interop is spotty. Things have improved a lot over the last few years and browsers have made huge strides at interop, but there are still a few stand-out areas that I'd like to address.

My (unpublished) November 2022 - April 2023 OKRs set out to increase adoption and understanding of Web Components by building Web Components Guide, working together with great engineers like Kristján and Nathan. I'm proud of the work we've accomplished so far but started to find it difficult to write effective documentation without caveating all of the various compatibility issues. Of particular note was the lack of support for CustomStateSet - effectively custom pseudo classes for components. CustomStateSet is a really nice feature and works well in Chrome, and while ponyfills exist they're awkward to use due to the lack of ability to polyfill CSS.

For the next 6 months, my aim is to fix this. I'm going to work on getting viable implementations in Firefox and Safari, as well as work with Joey on the Chrome team to make sure this feature gets fully fleshed out including great test coverage.

Key Results:

• CustomStateSet exists in all browsers (feature flag opt in may be required) and can style a custom element using a pseudo class ✅.
• Web Platform Tests offer robust and comprehensive coverage for the featureset ✅.
• All browsers pass 90%+ of CustomStateSet Web Platform Tests.

Objective 3: Bring "hdx" closer to production readyness

A huge bug-bear I have when developing websites is just how poorly native CSS is utilised. It's a fantastic language that is, in my opinion, poorly invested in within the open source community as well as the teams I've worked in. Despite the csswg moving mountains and delivering amazing new standards such as new colour primitives, CSS nesting, layers, variables and even the long awaited :has(), I feel like the community surrounding CSS hasn't progressed at the same pace, and we're still stuck with the same methods and practices from the last decade. While SASS delivered incredible value in the 2010s, writing SASS files in 2023 feels archaic but it's still a blessing compared to CSS-in-JS.

My (unpublished) April 2023 - November 2023 OKRs set out to start work on a best-in-class CSS toolchain, in an aim to shift the industry back to writing CSS (a lofty goal reserved for developers with delusional amounts of hubris, like me). The eventual goal is to build out an LSP and compiler toolchain capable of giving engineers a developer experience that makes it easier to write fast, efficient, and modern native CSS but all projects have to start somewhere. This project started out as a JavaScript project (work began on the lexer with csslex) but I pivoted to using Rust to develop it after seeing the impressive work from Boshen on the oxc compiler which has acted like a blueprint for building hdx. A shout out here goes to Romain who's produced some excellent work to make CSS tooling better, including the CSS-import and css-tokenizer gauntlet tests, and offered some great guidance and mentorship.

I'm going to continue this OKR into the next 6 months, with the aim to get the parser fully parsing and minifying 3 more of the example files. This sounds like a comparatively smaller goal but there's still a lot of ground work to build out here, hdx doesn't do a good job of parsing CSS variables and I'm still new to Rust development, so I've spent the last month working on a large refactor of the existing code base to get it on track to doing these things.

Key Results:

• hdx parses 3 and minifies more example files, to the same quality and size as other popular CSS parsers.

Objective 4: Chai 5 as an ESM module

I've been the maintainer of the Chai JavaScript testing framework since 2014. The majority of my work here has been guiding other contributors and stewarding the project to try and keep it stable, as it's one of the most used testing libraries in the ecosystem (if you're not using it directly, you might be indirectly: @openwc/testing, Vitest, and Cypress make use of it). Chai is showing its age a bit, and it's been a lot of effort to try and get it working with new primitives like Maps, Sets, Promises and so on. One last major hurdle is to get it working with ECMAScript Modules (esm). I've tried a few times over the last few years but my enthusiasm has waned.

Luckily some great developers have stepped up to help in this effort. Both Kristján and James have put in serious effort to refactor Chai and its dependencies to support esm first class, breathing new life into the project. My aim here will be to continue to mentor and support them to ensure Chai 5 is released as a robust library, and an easy transition from the commonjs Chai 4. Make no mistake though, all the credit goes to them and the other contributors to Chai 5.

Key Results:

• Chai 5 is released as the stable latest version of Chai ✅.
• Chai 5 can be imported and used in an esm only project ✅.

Conclusion

There it is, those are my four big open source projects for the next 6 months. If any of them sound interesting to you, please reach out via the usual channels (links in the header). I'll be writing about this again in April, reflecting on these 4 and giving myself some new ones.