A look at the open source annotation toolkit | GitHub Checkout 🔗 **Source:** [A look at the open source annotation toolkit | GitHub Checkout](https://www.youtube.com/watch?v=TjBO0bUK4bM) > [!note]+ Document Notes > tags: [annotation-toolkit, accessibility, figma, open-source] > author: [MISSING] > source: GitHub > reference: [https://www.youtube.com/watch?v=TjBO0bUK4bM] > date created: > > # 🏷️ Title: A look at the open source annotation toolkit | GitHub Checkout > <!-- deep-read:sections start --> ## 🧰 Action Inbox - [H1] Share toolkit intro in DevRel channels — context/https://www.youtube.com/watch?v=TjBO0bUK4bM #share - [H2] Add “use OSS toolkit” to design handover — context/https://www.youtube.com/watch?v=TjBO0bUK4bM #addendum - [H3] Publish “stamps for engineers” quickstart — context/https://www.youtube.com/watch?v=TjBO0bUK4bM #articleseed - [H4] Document numbered callouts convention — context/https://www.youtube.com/watch?v=TjBO0bUK4bM #xref - [H5] Write reflow/table guidance for themes — context/https://www.youtube.com/watch?v=TjBO0bUK4bM #xref - [H6] Track “48% preventable” as a hypothesis — context/https://www.youtube.com/watch?v=TjBO0bUK4bM #articleseed - [H7] Map labels to WCAG 2.2 checklist — context/https://www.youtube.com/watch?v=TjBO0bUK4bM #xref - [H8] Invite The WPOCC fellows to pilot — context/https://www.youtube.com/watch?v=TjBO0bUK4bM #share ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Include links cited in or relevant to the article. ## 📝 Summary - GitHub presents an open source Figma annotation toolkit. - The toolkit conveys design intent and accessibility details. - Stakeholders include designers, engineers, and product teams. - Risks include overconfidence and incomplete label coverage. - Bottom line: annotations reduce ambiguity and prevent accessibility mistakes. ## 📖 Main Content - The toolkit is a Figma library released as open source. [Video](https://www.youtube.com/watch?v=TjBO0bUK4bM) - It “stamps” designs with intent, behavior, and accessibility notes. [Video](https://www.youtube.com/watch?v=TjBO0bUK4bM) - It warns on risky choices, like non-responsive tables. [Video](https://www.youtube.com/watch?v=TjBO0bUK4bM) - GitHub cites internal research: 48% issues were preventable with clearer intent. [Video @ 3:36–3:45](https://www.youtube.com/watch?v=TjBO0bUK4bM&t=216) - Labels align with the Web Content Accessibility Guidelines. [WCAG 2.2](https://www.w3.org/WAI/standards-guidelines/wcag/) - Documentation includes tutorials and design checkpoints. [Video](https://www.youtube.com/watch?v=TjBO0bUK4bM) - The repo and Figma file are mentioned but not linked here. This limits verification. - Android annotations appear as novel coverage. [Video](https://www.youtube.com/watch?v=TjBO0bUK4bM) - Uncertainties: completeness, maintenance cadence, and cross-platform parity. ### 🗒️ Notes #### ⏱️ [00:00](https://www.youtube.com/watch?v=TjBO0bUK4bM&t=0) Designers’ inclusion goal ### [H1] Toolkit broadens collaboration beyond developers > [!quote] [YouTube](https://www.youtube.com/watch?v=TjBO0bUK4bM) by an unnamed author via [[GitHub]]. Published [MISSING]. Accessed . > “The annotation toolkit really helps us in achieving that goal.” Annotations support inclusive product workflows. [view highlight](https://www.youtube.com/watch?v=TjBO0bUK4bM&t=0) #share ID:rw_[MISSING] #### ⏱️ [00:23](https://www.youtube.com/watch?v=TjBO0bUK4bM&t=23) What the toolkit is ### [H3] Toolkit is a Figma library for intent > [!quote] [YouTube](https://www.youtube.com/watch?v=TjBO0bUK4bM) > “The annotation toolkit is a Figma library that can be used by developers, designers, product managers, anyone…” Clear intent reduces handover churn. [view highlight](https://www.youtube.com/watch?v=TjBO0bUK4bM&t=23) #articleseed ID:rw_[MISSING] #### ⏱️ [00:39](https://www.youtube.com/watch?v=TjBO0bUK4bM&t=39) Licensing ### [H2] Toolkit ships fully open source > [!quote] [YouTube](https://www.youtube.com/watch?v=TjBO0bUK4bM) > “The annotation kit now is fully open source.” Open licensing enables remixing and forks. [view highlight](https://www.youtube.com/watch?v=TjBO0bUK4bM&t=39) #addendum ID:rw_[MISSING] #### ⏱️ [01:28](https://www.youtube.com/watch?v=TjBO0bUK4bM&t=88) Stamps metaphor ### [H4] Stamps mark components with numbered notes > [!quote] [YouTube](https://www.youtube.com/watch?v=TjBO0bUK4bM) > “We also call them stamps in the toolkit.” Numbers connect stamps to descriptions. [view highlight](https://www.youtube.com/watch?v=TjBO0bUK4bM&t=90) #xref ID:rw_[MISSING] #### ⏱️ [02:54](https://www.youtube.com/watch?v=TjBO0bUK4bM&t=174) Reflow guidance ### [H5] Toolkit warns on non-responsive table settings > [!quote] [YouTube](https://www.youtube.com/watch?v=TjBO0bUK4bM) > “you'll see a warning pop up that points out that the table does not adapt responsively.” Warnings nudge toward accessible defaults. [view highlight](https://www.youtube.com/watch?v=TjBO0bUK4bM&t=186) #xref ID:rw_[MISSING] #### ⏱️ [03:36](https://www.youtube.com/watch?v=TjBO0bUK4bM&t=216) Preventable issues ### [H6] Clearer intent could prevent many audit issues > [!quote] [YouTube](https://www.youtube.com/watch?v=TjBO0bUK4bM) > “48% of the accessibility audit issues… could have been prevented… if there had been more clear intent…” Treat this as a working estimate. [view highlight](https://www.youtube.com/watch?v=TjBO0bUK4bM&t=216) #articleseed ID:rw_[MISSING] #### ⏱️ [04:07](https://www.youtube.com/watch?v=TjBO0bUK4bM&t=247) WCAG alignment ### [H7] Labels aim to prevent WCAG violations > [!quote] [YouTube](https://www.youtube.com/watch?v=TjBO0bUK4bM) > “This toolkit aims to prevent pretty much every possible violation of those guidelines…” Ambition is high; scope likely bounded. [view highlight](https://www.youtube.com/watch?v=TjBO0bUK4bM&t=247) #xref ID:rw_[MISSING] #### ⏱️ [04:40](https://www.youtube.com/watch?v=TjBO0bUK4bM&t=280) Docs and repo ### [H8] Repository includes tutorials and deep dives > [!quote] [YouTube](https://www.youtube.com/watch?v=TjBO0bUK4bM) > “this contains a ton of tutorials, guidelines, deep dives, and information…” Strong docs support adoption and contributions. [view highlight](https://www.youtube.com/watch?v=TjBO0bUK4bM&t=280) #share ID:rw_[MISSING] #### ⏱️ [05:28](https://www.youtube.com/watch?v=TjBO0bUK4bM&t=328) Platform coverage ### [H9] Toolkit includes Android-specific annotations > [!quote] [YouTube](https://www.youtube.com/watch?v=TjBO0bUK4bM) > “support in this toolkit for… annotations… such as Android annotations” Mobile parity matters for WordPress apps. [view highlight](https://www.youtube.com/watch?v=TjBO0bUK4bM&t=328) #xref ID:rw_[MISSING] #### ⏱️ [06:10](https://www.youtube.com/watch?v=TjBO0bUK4bM&t=370) Why engineers care ### [H10] Annotations turn Figma into a spec vehicle > [!quote] [YouTube](https://www.youtube.com/watch?v=TjBO0bUK4bM) > “Annotations are a tool to enable Figma to become more than just a canvas…” Designs communicate behavior, not only pixels. [view highlight](https://www.youtube.com/watch?v=TjBO0bUK4bM&t=370) #articleseed ID:rw_[MISSING] ## 📚 References - [Video: A look at the open source annotation toolkit | GitHub Checkout](https://www.youtube.com/watch?v=TjBO0bUK4bM) - [WCAG 2.2 overview — W3C](https://www.w3.org/WAI/standards-guidelines/wcag/) - [Figma Community (general entry point)](https://www.figma.com/community) — specific file link not in transcript. - Repository URL is mentioned verbally but not provided in the transcript. ## 🗣️ Paraphrase - GitHub released an open source Figma annotation library. - It improves handoffs, flags accessibility problems, and invites contributions. ## 📰 Newsletter - GitHub dropped an open source Figma annotation kit. - Use stamps to share intent, behavior, and accessibility needs. - It even warns on risky choices like non-responsive tables. - WordPress teams can standardize handoffs and reduce audit churn. - Watch the demo and start piloting. [Video](https://www.youtube.com/watch?v=TjBO0bUK4bM) ## ✅ Action Items #### DevRel - Record a five-minute “stamps 101” video for engineers. - Run a workshop on reflow annotations for tables. - Add example handoffs for avatars, tables, and forms. - Publish a quickstart in docs with screenshots. - Track adoption and developer satisfaction quarterly. #### OSPO - Clarify contribution guidelines for the toolkit upstream. - Review license compatibility with internal design assets. - Propose issue templates for accessibility label gaps. - Add the toolkit to design governance checklists. - Report adoption and defects to executives. #### Community - Host a Figma-to-code clinic using the toolkit. - Pair designers with contributors for pilot handoffs. - Share before/after examples at meetups. - Collect feedback through a public survey. #### WordPress - Core: annotate complex tables and avatars in issues. - Core Performance: document reflow expectations in patterns. - Core AI: label data inputs, outputs, and error states. - **Core Program Team:** standardize stamp legends across teams. - Mobile: test Android annotations with the apps team. - Playground: publish a guided lab on annotation review. - Training: add a lesson on intent labels and reflow. - Marketing: showcase annotated designs in release posts. - Support: add stamp references to KB articles. - Design: define color contrast checks within labels. - Documentation: include “view stamp” screenshots. - Meta: expose annotation examples in .org handbooks. - CLI: document UI flag impacts with stamps. - Hosting: include reflow checks in theme tests. - Tide: consider stamp-based accessibility metadata. - Openverse: annotate ingestion flows and empty states. - Themes: require reflow labels in submissions. - Plugins: add accessibility intent to submission forms. - Accessibility: crosswalk stamps to WCAG criteria. - Polyglots: annotate localizable strings in designs. - TV: caption tutorials introducing stamps. - Photos: label alt-text expectations in components. #### The WPOCC - Fund microgrants for annotation playbooks. - Sponsor maintainer stipends for accessibility labeling. - Run governance clinics on design-to-code intent. ### FAIR - Specify provenance for design assets and stamps. - Add signature checks for shared annotation files. - Publish operator agreements for funded pilots. ## 🧪 Hypotheses - Annotation use reduces accessibility audit issues by 30%+. - Reflow labels cut front-end rework time by 20%+. - Numbered stamps reduce handover questions per ticket by half. - Android annotations improve mobile defect closure rates. ### 📊 Methodology - Run A/B handoffs with and without annotations. - Track audit issues, PR comments, and fix times. - Survey satisfaction among designers and engineers. - Analyze WordPress release defects across annotated pilots. ### ❓ Questions - Which labels map best to WordPress components? - How often should teams update stamp legends? - What gaps exist for iOS or Gutenberg blocks? ### 🔮 Future Research - Build a Gutenberg-aware annotation set. - Study annotation impacts across distributed OSS teams. - Explore machine-checkable stamps for CI warnings. ### 💡 Implications - Practice: standardize stamps in handoffs. - Policy: require reflow labels in reviews. - Security: annotate privacy and consent UI states. - Education: add toolkit modules to contributor onboarding. - Funding: tie grants to measurable defect reductions. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch-Kincaid Grade ≈ 9–10. #### 👀 Visual learners - Present: screenshots and stamps. - Improve: add annotated flow diagrams. #### 🔊 Aural learners - Present: narrated video. - Improve: publish a short audio summary. #### 🗣️ Verbal learners - Present: clear definitions and labels. - Improve: add a glossary in docs. #### 🧩 Kinesthetic learners - Present: hands-on stamp exercises. - Improve: create step-by-step labs. #### 🧠 Logical learners - Present: checkpoints and warnings. - Improve: add decision trees for labels. #### 🧑‍🤝‍🧑 Social learners - Present: collaboration prompts. - Improve: cohort pilot guides. #### 🧘‍♀️ Solitary learners - Present: self-paced docs. - Improve: short quizzes and reflections. #### 🌿 Naturalistic learners - Present: system-wide thinking. - Improve: lifecycle and ecosystem ties. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: structured headings in docs. - Improve: add alt text to examples. #### Keyboard navigation - Present: logical sequences. - Improve: publish tab order conventions. #### Contrast and readability - Present: contrast guidance exists. - Improve: confirm 4.5:1 per WCAG 2.2. #### Text resizing and reflow - Present: explicit reflow labels. - Improve: document edge cases. #### Media and captions - Present: YouTube captions available. - Improve: provide downloadable transcripts. #### Forms and interactions - Present: clear stamp fields. - Improve: add inline validation patterns. #### Standards reference - Map gaps to WCAG 2.2 AA criteria. ### 🌍 DEIB Assessment #### Cultural breadth - Present: broad, role-agnostic guidance. - Improve: add non-Western examples. #### Inclusive language - Present: plain terms and definitions. - Improve: expand glossary for newcomers. #### Neurodiversity support - Present: chunked steps and labels. - Improve: consistent icon-and-text pairings. #### Representation - Present: multiple roles acknowledged. - Improve: show diverse teams in examples. #### Psychological safety - Present: invite issues and feedback. - Improve: publish moderation and escalation paths. ### ✅ Logical Validity #### Strong reasoning - Tooling warnings likely reduce common mistakes [H5]. - Numbered stamps improve traceability between design and notes [H4]. - Open source model encourages iterative improvements [H2]. #### Fallacies - “Prevent every possible violation” risks overstatement [H7]. - Safer phrasing: “reduce violations addressable by labels.” - “48% preventable” is internal; treat as provisional [H6]. #### Tone of voice - Practical and invitational. Uses examples and demos. ### 🛡️ DARVO Analysis - Deny: none apparent. - Attack: none apparent. - Reverse victim/offender: none apparent. ## 🎯 Conclusion - The toolkit turns designs into actionable, accessible specs. - Pilot with a small team, measure audit outcomes, and iterate. ## 🔖 Zettel Candidates - **Toolkit broadens collaboration beyond developers.** Inclusive workflows need shared intent. https://www.youtube.com/watch?v=TjBO0bUK4bM - **Toolkit is a Figma library for intent.** Label behaviors near components. https://www.youtube.com/watch?v=TjBO0bUK4bM - **Toolkit ships fully open source.** Contributions and forks accelerate quality. https://www.youtube.com/watch?v=TjBO0bUK4bM - **Stamps mark components with numbered notes.** Improve traceability during handoff. https://www.youtube.com/watch?v=TjBO0bUK4bM - **Toolkit warns on non-responsive table settings.** Encourage accessible defaults. https://www.youtube.com/watch?v=TjBO0bUK4bM - **Clearer intent could prevent many audit issues.** Track this metric in pilots. https://www.youtube.com/watch?v=TjBO0bUK4bM - **Labels aim to prevent WCAG violations.** Align with 2.2 criteria. https://www.w3.org/WAI/standards-guidelines/wcag/ - **Repository includes tutorials and deep dives.** Adoption improves with docs. https://www.youtube.com/watch?v=TjBO0bUK4bM - **Toolkit includes Android-specific annotations.** Test with WordPress apps. https://www.youtube.com/watch?v=TjBO0bUK4bM - **Annotations turn Figma into a spec vehicle.** Reduce ambiguity for engineers. https://www.youtube.com/watch?v=TjBO0bUK4bM ## 🏷️ Tag Coverage #articleseed: 3 • #xref: 3 • #share: 2 • #bmf: 0 • #addendum: 1 ## 🧱 Refactor Appendix (append after 🎯 Conclusion) ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: **H3**. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] 5–10-word present-tense claim > [!quote] [A look at the open source annotation toolkit | GitHub Checkout](https://www.youtube.com/watch?v=TjBO0bUK4bM) by an unnamed author via [[GitHub]]. Published [MISSING]. Accessed . > “Short quote, verbatim, ≤25 words.” Two lines: context and use. Cite data if relevant. [view highlight](https://www.youtube.com/watch?v=TjBO0bUK4bM#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] 5–10-word present-tense claim > [!quote] [A look at the open source annotation toolkit | GitHub Checkout](https://www.youtube.com/watch?v=TjBO0bUK4bM) > “Short quote, verbatim, ≤25 words.” Two lines: context and use. [view highlight](https://www.youtube.com/watch?v=TjBO0bUK4bM#H2) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) - Purpose: Promote reusable claims into Atomic notes. - Split level: **H4**. - Each item: one idea, present tense, specific, testable. #### [Z1] 5–10-word present-tense claim - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[Parent-Concept]] [[Related-Idea]] #### [Z2] 5–10-word present-tense claim - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[Parent-Concept]] [[Related-Idea]] --- ### ✏️ Fleeting Queue (Extract by Selection) - Purpose: Capture quick actions or sparks for Fleeting notes. - Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).” - Keep each line short and self-contained. - [F1] Short action — context/https://www.youtube.com/watch?v=TjBO0bUK4bM #fleeting #inbox - [F2] Short action — context/https://www.youtube.com/watch?v=TjBO0bUK4bM #fleeting #inbox - [F3] Short action — context/https://www.youtube.com/watch?v=TjBO0bUK4bM #fleeting #inbox --- <!-- deep-read:sections end --> ## 📺 Video  --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=TjBO0bUK4bM)* **[00:00]** We really think of GitHub as a collaboration platform or developers mostly. How do we make our designers more included? The annotation toolkit really helps us in achieving that goal. >> Welcome Jane. Thank you for being here. >> Thank you so much for having me and I am so excited that you're here because you're bringing us a gift, the gift of the annotation toolkit. Can you tell us what is the annotation toolkit? The annotation toolkit is a Figma library that can be used by developers, designers, product managers, anyone who **[00:31]** wants to be a little more collaborative and share a little more information about their workflows so that that designer to developer handover is a little more seamless. >> The annotation kit now is fully open source. >> So this is now public on our profile. So that's at GitHub on Figma. It's free to use, completely open source. You can get some information about it here. If you've used GitHub before, this might be familiar to you. This is the skeleton of your profile page on GitHub. And we're going to use this today as an opportunity to show off how the annotation toolkit works. So, if you **[01:01]** just go into the assets tab on Figma, you can see it here. Now, you might wonder what an annotation is to begin with because even if you are a designer, annotations might not be something you use in your day-to-day workflows. These are basically just ways to express design intent and to add information that might not be visible on the design itself. >> So an annotation is like a commit or no, it's like a discussion and an issue. >> Yeah. So an annotation is basically just like this little stamp here. We also call them stamps in the toolkit. So for **[01:32]** instance, >> okay, >> if I want to make it clear that this is going to be an image, I can add this little image annotation. And what you'll see is there's a little number beside it. You can see the number one here. If I want to add any information about it, I can also pull this description into my Figma file and that's got the corresponding number one. And then I can add the description. So this is like GitHub profile picture. So one thing you might notice is that there's a really strong accessibility focus to the annotation toolkit. This was developed by our accessibility **[02:03]** design team. And one thing that sets it apart from other annotation toolkits is that until now, annotation toolkits have typically been a tool mainly used by accessibility specialists. But we wanted to make sure that this toolkit is useful for all sorts of reasons for people doing all sorts of designs with all sorts of levels of expertise in the area. So if you've never worked with an accessibility design feature before, this is not going to be intimidating at all. We've got a lot of descriptions, a lot of ways to find information, and it's pretty self-explanatory in a lot of **[02:33]** cases. We have built in a ton of functionality so that your intent is as clear as possible. So, for instance, I might make this a table. If I'm making it a table, and I'll add that number two there so we know the correct description. If I'm adding this as a table, I might want the engineer I'm handing this over to to know exactly what the reflow behavior is. So, if you don't know, that's the responsive behavior when you make the window smaller or you make the text bigger. So, as you see, by default, it says horizontal overflow, but I can customize **[03:04]** that here. And if I press none, you'll see a warning pop up that points out that the table does not adapt responsively. This means that this toolkit not only helps you express your own intent, but it can also give you really helpful pointers in areas you might know less about. >> And so, before we developed this toolkit, how did you used to do this? I guess how do the designers and developers pass this type of information. >> So it used to be more complicated in the past. We might do this with things like comments on the Figma design or even just Slack messages. >> We actually found in our own internal **[03:36]** research before we developed it that something like 48% of the accessibility audit issues that we encountered could have been prevented to begin with if there had been more clear intent expressed during the design stage. So, as you can imagine, having a toolkit like this that gives us complete clarity over how we express these things aims to bring that percentage down by quite a lot. If you're a developer who works in the front end, or if you're a UI designer, you might be familiar with WAG, the web content accessibility guidelines. This toolkit aims to prevent **[04:07]** pretty much every possible violation of those guidelines that could be expressed using these kinds of labels. You'll see that throughout the annotation toolkit, there is a lot of different guidance. So, for instance, there's this sticker sheet that explains every single label and why you might use it. We also have these design checkpoints that you can either pull directly into your design or have on a separate page. And these let you really understand exactly what it is that you need to be checking off to ensure that you're designing in the most accessible way possible. I will also **[04:39]** show you our open source repo. So you can get this at github/anotation toolkit and this contains a ton of tutorials, guidelines, deep dives, and information about all of the topics covered. When I say that the documentation in this toolkit is extensive, I don't think I can even begin to express just how much there is in here. Our open source repo is a really great way for us to hear from developers and designers who are interested in furthering this or forking their own or adding any other information. You can simply create an **[05:09]** issue and we'll be there to monitor those. Whether it's a bug or a feature request, we're there to help you out and figure out what we can do to support you. >> What's up next for the for the project itself? Anything on the road map that you could share? >> To be honest with you, this is already so extensive that it's hard to know where we'd even go next. There's actually support in this toolkit for some types of annotations that have never been done before, such as Android annotations, and we're really proud of those. Um, so at this point in time, we feel like we've done a lot, but we always want to do more. So if there's **[05:40]** anything at all you can think of that could be in our annotation toolkit, we want to hear from you. >> And Jane, I have to ask, as a developer, why should you care? Why should you start using this annotation toolkit? Why do you think developers and designers are actually use it? Now, >> have you ever, as an engineer, received something from a designer and wondered what on earth is this supposed to actually mean? I see all of these individual components here. I see all of these things and I don't know what this is supposed to actually do. Annotations **[06:10]** are a tool to enable Figma to become more than just a canvas, but also a tool for expressing a much deeper level of information. And if you're a designer who's ever dealt with a clueless developer or a developer who's ever dealt with an unclear designer, you will know just how much of a difference this can make. uh someone who's tried to like and love and live in Figma and it's been completely unsuccessful. I feel that at my core. So, thank you. I'm excited for all of us to receive this gift, this gift from GitHub to open source and to **[06:40]** make us developers less clueless when it comes to design. Thank you so much, Jane. Thank you for coming by and showing us the new open source annotation toolkit. Thank you so much. It's been a pleasure showing it off. And that was your first look at the new open-source annotation toolkit. Try it out. Open an issue. Contribute. The team wants to hear from you. And if you learned something today, please smash that like button and subscribe to this channel so you don't miss any other feature updates. I'll catch you on the next release. **[07:12]** [Music]