Rust Commercial Network (RCN)

Where Rust users, businesses, and communities work together to make Rust easier to adopt and maintain.

The Rust Commercial Network (RCN) is a Rust Foundation group for people and organizations using Rust in professional settings. Members compare notes on adoption blockers, improve Rust supply chain health, and support the basic tooling, libraries, and maintenance work that make Rust dependable in production.

Join: fill out the membership application.

Discuss: use the RCN channel in the Rust Project Zulip.

Support Rust ecosystem work: see the Funding Directory.

Overview

The RCN is open to Rust users of all sizes: individual commercial users, consultants, startups, small businesses, larger companies, academic users, organizations, Rust Foundation Members, Rust Advocates, and members of the Rust Project. The RCN supports industry consortiums, interest groups, working groups, and other initiatives, with review from the RCN Steering Committee.

The RCN is separate from the Rust Project's developing Rust Society, although there may be some overlap over time.

Membership in the RCN is free.

The RCN works to:

Identify Rust adoption and maintenance problems shared by production users
Form consortiums, working groups, and interest groups around industry-specific or ecosystem-wide needs
Help members contribute time, funding, testing, documentation, and maintainer support
Share findings with the Rust Project, ecosystem maintainers, and the Rust Foundation

What Members Do

Meet regularly
Discuss topics that matter to production Rust users
Promote industry-specific adoption of Rust
Meet in person when possible, including at Rust Foundation events such as the Member Summit
Work with the Rust Project and ecosystem maintainers to identify and resolve issues that affect commercial and organizational use, including tooling gaps, crate reliability, maintenance bottlenecks, and adoption papercuts
- Members may contribute engineering time, funding, testing, maintainer support, documentation work, contributions to the Rust Foundation Maintainer's Fund, or other help

RCN may produce:

Best practice guides and reference architectures
Adoption playbooks
Feedback summaries for the Rust Project
Gap analyses for tooling, libraries, documentation, and maintenance capacity
Prioritized lists of papercuts and reliability issues affecting production users
Recommendations to improve core tooling, widely used libraries, crate reliability, long-term maintenance, and Rust supply chain health

*Individual issues can be brought up to the Project independent of the RCN. The RCN aims to identify recurring or broadly shared issues, including smaller papercuts that add up to adoption, reliability, or maintenance problems across organizations.

RCN Initiatives: Interest Groups, Working Groups, and Consortiums

RCN members can propose initiatives focused on shared adoption blockers, ecosystem maintenance, or industry-specific needs. These initiatives may be formally organized as interest groups, working groups, or consortiums which can produce guides, reports, recommendations, or other outputs for the Rust community.

To propose an initiative, file an application using the GitHub Issue template. See RCN Initiatives: Interest Groups, Working Groups, and Consortiums for operations, Steering Committee scope, voting rights, and withdrawal details.

Meetings and Communication

The RCN hosts public monthly meeting(s)* to discuss topics related to production Rust users. The meetings take place on Google Meet. The RCN may use Chatham House Rule when meetings cover sensitive topics.

Public discussion happens in the RCN channel in the Rust Project Zulip. See Meetings for meeting policy, note-taking, and communication details.

*The RCN will determine the cadence and number of meetings per year.

Member Definitions and Governance

RCN membership is free. See Membership for member definitions, including Rust Foundation Members, Commercial/Organizational Members, Rust Advocates, Rust Project Members, and RCN Initiative Members.

The Rust Foundation maintains the RCN with support from the RCN Steering Committee. See Governance for Steering Committee duties, composition, selection, terms, vacancies, and eligibility.

Code of Conduct

The Rust Foundation has adopted a Code of Conduct that we expect RCN participants to adhere to. Please read the full text so that you can understand what actions will and will not be tolerated.

Community Events

The Rust Foundation Member Summit, attached to RustConf, may provide one place for RCN members, Rust Foundation members, Rust Foundation Board Members, and Rust Project members to meet in person.

Next Steps

Apply to join the RCN
Propose an initiative
Support Rust ecosystem work
Join the RCN channel in the Rust Project Zulip

Contributing

See CONTRIBUTING.md.

Licenses

Rust is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0), with documentation portions covered by the Creative Commons Attribution 4.0 International license.

See LICENSE-APACHE, LICENSE-MIT, LICENSE-documentation, and COPYRIGHT for details.

You can also read more under the Foundation's intellectual property policy.

Other Policies

Members of the RCN must adhere to the Rust Foundation's anti-trust policy https://rustfoundation.org/policy/anti-trust-policy/ as you are a participant in the Foundation. Additional policies can be found on the Rust Foundation website.

Members

The Rust Commercial Network includes organizations and individuals working together to make Rust easier to adopt and maintain.

This page is generated from the RCN Membership GitHub Project during the website deployment.

Organizations

Member Names

RCN Membership

Membership in the RCN is free.

You do not need to work for a Rust Foundation member company to join discussions or propose work.

Member Definitions

Rust Foundation Member

Individual representing a company that is a member of the Rust Foundation in good standing.

Commercial/Organizational Member

A Commercial/Organizational Member is an individual who uses or evaluates Rust for work, including commercial, organizational, consulting, education, startup, small business, or independent professional work. These members may use Rust in production, contribute to Rust projects, or build Rust-based products or services.

Rust Advocate

Rust Advocates are experienced Rust practitioners who work in areas such as Robotics, Automotive, Public Sector, and cloud native. These advocates have been sourced from participation in RustConf and other Rust Foundation initiatives. They may or may not be Rust Project members.

Rust Project Member

Rust Project Members are individuals on a Rust Team who make significant contributions to the development and maintenance of the Rust programming language and its associated tools.

RCN Initiative Member

An RCN Initiative Member is an individual who is an active member of an RCN-affiliated consortium, working group, interest group, or other RCN initiative as determined by that initiative's own membership criteria and processes. RCN Initiative Members are recognized as RCN participants and may attend RCN meetings, contribute to discussions, and access RCN communication channels.

RCN Initiative Members may vote on RCN matters that directly affect the RCN initiative in which they hold membership, including but not limited to: policies governing RCN initiative operations, changes to the relationship between the RCN and its consortiums, working groups, or interest groups, and amendments to this charter that alter the rights or obligations of RCN initiatives.

RCN Initiative Members do not vote in RCN-wide elections such as Steering Committee seats unless they independently qualify under another RCN member definition.

For the purposes of determining good standing, RCN Initiative Members must meet the membership requirements of their respective RCN initiative. Attendance at RCN-level meetings is not required for RCN Initiative Members to maintain good standing.

RCN Governance

The RCN is a volunteer-driven community maintained by the Rust Foundation. It consists of the membership, a Steering Committee, and the initiatives (consortiums, working groups, interest groups, etc.) that the Steering Committee approves and reviews. You can be a member of the RCN without joining an initiative.

RCN Steering Committee

Purpose and Duties

The RCN Steering Committee:

Represents the RCN to the Rust Foundation Board, conferences, and media
Shares user needs with the Rust Project and works with Project members on possible solutions. The SC does not speak on behalf of any initiative to the Rust Project or external bodies without that initiative's explicit consent.
Reviews and votes on proposed RCN initiatives
Helps RCN initiatives establish an appropriate organizational structure (a consortium, a working group, an interest group, etc.) and develop respective governance documents
Develops policies and procedures consistent with this charter
Keeps RCN work documented and public

Composition and Selection

RCN members in good standing vote on RCN Steering Committee members. A member in good standing has attended at least 2 RCN meetings and is officially listed on the RCN GitHub Repo as a RCN member. For a listing of Rust Foundation Members visit https://rustfoundation.org/members/.

The RCN Steering Committee Consists Of

No more than seven and no less than five representatives from Platinum (1), Gold (1), Silver (2), and Associate (1) Rust Foundation members. There cannot be two Steering Committee Members from one company.
The Rust Foundation will have a seat on the Steering Committee in an advisory capacity.
The Rust Project will have a seat on the Steering Committee in an advisory capacity.

Terms and Termination

RCN SC Members serve approximately two-year terms, with staggered terms initially.
RCN SC Membership ceases if a member resigns, is removed, or changes employment away from a Rust Foundation member. A super-majority vote can remove members not fulfilling their duties or complying with RCN policies.

Vacancies and Alternates

Vacancies that would put steering committee membership below five (5) are filled by election or invitation.

Eligibility and Criteria

Members must be employees of Rust Foundation Membership companies in good standing.
Only one representative from the same organization may serve at a time.

Conflict of Interest Policy

The aim of this policy is to ensure that decisions made by Members of the Rust Commercial Network ("RCN") created and hosted by the Rust Foundation ("Foundation"), are in the best interests of the RCN, the wider language ecosystem, and the public, rather than influenced by personal or organisational interests. This policy serves to define the term "conflict of interest," to assist members of the RCN, and to disclose such conflicts, and to minimize the impact of such conflicts on the actions of the Foundation whenever possible. Collectively, this policy will refer to members of the RCN as "Covered Members."

Conflict of Interest Defined

A "conflict of interest" is any transaction or relationship that presents, or may present, a conflict between a Covered Member's obligations to Foundation and their personal, business, or other interests.

Disclosure

Foundation and RCN Members recognize that conflicts of interest are not uncommon, and that not all conflicts of interest are necessarily harmful to the Foundation. However, RCN membership requires full disclosure of all actual and potential conflicts of interest. Each Covered Member shall disclose any and all facts that may be construed as a conflict of interest upon joining the RCN, at the start of any meeting where relevant matters are discussed, and as soon as circumstances change.

Process and Remedy

The Foundation and RCN Steering Committee will determine whether or not a conflict of interest exists, and whether or not such conflict materially and adversely affects the interests of the Foundation. A Covered Member whose potential conflict is under review may not debate, vote, or otherwise participate in such determination. If the Foundation and RCN Steering Committee determine that an actual or potential conflict of interest exists, the Board shall also determine an appropriate remedy. Such a remedy may include, for example, the recusal of the conflicted Covered Member from participating in certain matters pending before the RCN Steering Committee or other Foundation body.

Delegation

The Foundation and RCN Steering Committee may delegate its authority to review and remedy potential conflicts of interest to a committee. Only disinterested members of the committee may participate in any such review. The committee shall inform the Foundation and RCN Steering Committee of its determination and recommended action. The Foundation and RCN Steering Committee shall retain the right to modify or reverse such determination and action, and shall retain the ultimate enforcement authority with respect to the interpretation and application of this policy.

Acceptance

Participation in the Network constitutes acceptance of this policy and agreement to comply with its requirements.

RCN Meetings

RCN meetings may cover sensitive adoption, production, or ecosystem concerns. To support candid discussion, the RCN may use Chatham House Rule. The RCN will host public monthly meeting(s)* on Google Meet to discuss topics related to production Rust users.

*The RCN will determine the cadence and number of meetings per year.

Chatham House Rule

Chatham House Rule means participants may share what was said, but may not identify who said it.

When Chatham House Rule applies, participants may not record, transcribe, or use AI bots to capture the meeting.

Meeting Option

If Chatham House Rule is not needed for a meeting, the RCN may allow recording or transcription with the group's agreement.

Notetaker Role

Each meeting will have a notetaker from the Rust Foundation or the attendee group. See the notetaker role doc for more information.

Communication

The RCN uses a channel in the Rust Project Zulip for async discussion and meeting topics. Participants are encouraged to create public discussion threads when possible. Zulip is a public forum with members of the Rust Project, guests of the Project, end users, and Rust Foundation staff; threads are publicly accessible. Private channels may be necessary to discuss sensitive topics, but the preference is to keep conversations open, matching how the Project operates.

RCN Initiatives: Interest Groups, Working Groups, and Consortiums

RCN members can propose initiatives to the Steering Committee. These initiatives have a clear focus, report findings back to the Steering Committee, and follow the guidelines below. The initiatives can be formally organized as interest groups, working groups, consortiums, or other collaborative forms.

To propose an initiative, file an application using the GitHub Issue template.

Areas of Work

RCN members may propose an initiative for a specific Rust adoption or ecosystem maintenance topic. Proposed areas include:

Identifying shared challenges in Rust adoption, crate maintenance, supply chain reliability, and ecosystem maintenance
Creating high-level frameworks or templates to help others adopt Rust
Identifying basic tooling and library needs that affect production users
Highlighting projects that are not in the Rust Innovation Lab (RIL) but need more visibility, funding, or engineering time

Operations

Each initiative defines and administers its own organizational form, membership criteria, tiers, and processes. Membership in an RCN initiative does not necessarily require RCN membership.

Membership in the RCN and membership in an RCN initiative are independent. RCN membership does not confer membership, standing, or participation rights in any initiative.

Steering Committee Scope

The RCN Steering Committee reviews initiatives to make sure their work fits the RCN mission. The SC helps initiatives establish the appropriate organizational form (interest group, working group, consortium, etc.) and draft the charters and other governance documents that define how they operate. The SC does not have authority over an initiative's internal processes, membership decisions, leadership selection, technical direction, or public communications.

To be clear, "fits the RCN mission" means that the initiative operates within the scope of Rust adoption by commercial, industrial, or organizational users. It does not authorize the SC to require changes to an initiative's scope, priorities, deliverables, publication schedule, or processes in order to remain affiliated with the RCN.

Voting Rights

Only RCN members in good standing may vote in RCN-level elections. Only initiative members may vote in initiative-level decisions, as defined by that initiative's own governance.

Existing Initiatives

Initiatives (consortiums, interest groups, or working groups) that predate the RCN or that maintain their own governance structures retain full authority over their technical outputs, publication decisions, and operational processes. The SC may not condition continued RCN affiliation on changes to an initiative's existing governance, scope, processes, or external relationships, including direct relationships with the Rust Project, standards bodies, or other organizations.

Withdrawal

An RCN-affiliated initiative may withdraw from the RCN at any time by written notice from that initiative's leadership to the RCN Steering Committee. Upon withdrawal, the initiative retains its existing governance structures, membership, repositories, branding, and intellectual property. Withdrawal does not require SC approval. Former RCN-affiliated initiatives are welcome to seek re-affiliation in the future.

Rust Ecosystem Work Seeking Support

This directory lists Rust compiler, Cargo, tooling, and library work where maintainers are looking for funding, production data, or feedback from companies using Rust at scale.

The initiatives below represent active funding opportunities. Most already have at least one supporting organization and are looking for additional partners.

To discuss funding, procurement, or sharing private production feedback, contact rust-commercial-network@rustfoundation.org. For public discussion, use the RCN channel in the Rust Project Zulip.

RFEF sponsors may receive recognition, fund reporting, sponsorship coordination, and advance security disclosures when coordinated private notice is needed.

How to Help

Most listed work can be supported through the Rust Foundation Ecosystem Fund (RFEF), which directs funding to the maintainers or projects doing the work. For Rust Project goals seeking support, see the Rust Project Goals funding page. If an organization wants to support Rust maintainers more generally, please check out the Rust Project Funding page where you can support the Rust Foundation Maintainers Fund or individual Rust project members.

Funding does not buy control over Rust technical decisions, RFC outcomes, stabilization, release timing, maintainer review, priority, or project roadmaps.

Depending on the item, support may go to an individual maintainer, a project, a fiscal host, an employer, or a foundation. Rust Project work still goes through the normal team review process, including RFCs, ACPs, implementation review, and stabilization where applicable. Project goals provide public context and coordination; they are not approval of a specific design or priority.

Use public project venues for technical feedback when possible. If confidential build data, deployment details, or production traces would be useful, contact the RCN mailbox, the relevant maintainer, or the Foundation before sharing them. Non-confidential conclusions should be summarized publicly when practical.

Named contributors and related projects are included to identify likely contacts and work owners. Inclusion does not mean the RCN, Rust Foundation, or Rust Project has endorsed a specific technical decision.

Build Performance

Wild

Useful when: link time is a visible cost in CI or local development.

Wild is a Rust Innovation Lab project building a faster linker for Rust workloads. Current work is aimed at large binaries, more platforms, and the missing linker features that prevent projects from trying Wild today.

The most useful sponsor input is real build data: linker timing profiles, crate graph shape, binary size, platform constraints, and failure cases. Maintainers will prioritize work that fits Wild's goals and available time.

Led by David Lattimore (@davidlattimore). Related project: Wild.

Faster Builds Roadmap

Useful when: build time affects developer wait time, CI spend, or release latency.

The Faster Builds Roadmap would fund bjorn3 (@bjorn3) for an additional day per week of Rust build performance work, complementing time already contributed through Tweede Golf.

bjorn3 would spend the funded time on the roadmap items most likely to shorten real build times.

Cargo Cross-Workspace Cache

Useful when: duplicate Cargo build artifacts are costing CI time, disk space, or local setup time.

Cargo Cross-Workspace Cache would reduce duplicate build artifacts across Cargo workspaces. A shared cache could cut repeated CI minutes and disk use, provided it holds up against production build patterns.

Ross Sullivan (@ranger-ross) is seeking support to design and implement a first version that the Cargo team can evaluate. If accepted, support would carry the work through normal Cargo review and nightly testing. Useful data includes build times, cache hit rates, cache storage costs, workspace structure, and failure cases.

Reusable Build Artifacts

Useful when: teams run cargo check before cargo build in local development or CI.

Today, cargo check and cargo build largely duplicate work. This project aims to make build artifacts reusable across both workflows, so work done for cargo check can carry into cargo build.

Funding would give Alejandra Gonzalez (@blyxyas) time to pursue a new incremental compilation design. This work may also support Cargo Cross-Workspace Cache and other build reuse work.

Cranelift

Useful when: teams rebuild large Rust services many times per day and care most about local debug-build time.

Cranelift is an alternative Rust code generation backend. The current goal is a 2x speedup in Cranelift code generation for debug builds, reducing local compile time for developers.

Sponsor support would cover time for bjorn3 (@bjorn3) and Folkert de Vries (@folkertdev), through Tweede Golf, to work through the performance improvements in the project goal.

Developer Experience and Tooling

cargo-nextest

Useful when: Rust test suites are a release gate and slow or flaky test runs delay shipping.

cargo-nextest is a Rust test runner used in local development and CI. Maintenance funding pays for the work users rely on but do not always see: releases, issue triage, contributor review, platform support, and CI-scale fixes.

Funding would buy down unpaid maintenance work for Rain (@sunshowers): releases, issue triage, contributor review, and fixes requested by users running nextest in CI. RCN members can provide feedback, test cases, or contributions through the same public channels as other users.

Related: cargo-nextest.

Cargo Maintenance

Useful when: Cargo review or implementation work blocks supply-chain policy, build reproducibility, C++ interoperability, signed crates, or sandboxed build scripts.

Many Rust roadmap items need Cargo review or implementation work. This item funds general Cargo review and implementation time, not reserved reviewer time for funder-requested changes.

Arlo Siemsen (@arlosi) would use additional funded time for Cargo review, mentoring, implementation, and moving accepted changes through Cargo review. Cargo maintainers and Rust Project teams retain authority over review, acceptance, prioritization, and release timing.

Related: Cargo, crates.io.

Crate Namespaces

Useful when: organizations publish related crate families, internal platform crates, SDKs, or official packages.

Crate namespaces would let organizations publish related crates under one namespace, making ownership clearer and reducing collisions with similarly named crates.

Implementation work is underway across rustc, Cargo, and crates.io while the next project goal is still being drafted. Funding would help contributors such as Takayuki Maeda (@TaKO8Ki) continue implementing RFC 3243 and related changes. Cargo, crates.io, and rust-lang teams still decide design and policy questions through their normal processes.

Related: RFC 3243, previous project goal, Cargo, crates.io, rust-lang/rust. A new project goal has not been published yet.

Native async fn dynamic dispatch in traits

Rust supports async fn in traits, but using async methods through dyn trait objects still requires workarounds such as #[async_trait], which add allocation overhead, obscure signatures, and split the ecosystem between native async traits and boxed trait-object patterns.

Funding would support work by Santiago Pastorino (@spastorino) and Jack Huey (@jackh726) to make async trait methods usable through dynamic dispatch. The work has two parts: first, making Rust more precise about which trait methods are dyn-compatible, and second, adding native support for async dispatch through trait objects.

The goal is to reduce reliance on #[async_trait], give library authors a cleaner path for async trait APIs, and make the feature available for real-world testing on nightly before final syntax is designed.

Language and Compiler

Async State Machine Improvements

Useful when: state-machine code generation affects CPU use, memory pressure, binary size, or compiler limits in async services.

Rust's async implementation generates state machines behind the scenes. Better state-machine generation can shrink binaries, improve runtime performance, and avoid compiler limits such as maximum query recursion depth.

Dion Dokter (@diondokter) at Tweede Golf is seeking support to continue async state machine code generation work.

F16 Stabilization

Useful when: Rust code needs to pass f16 data between ML inference, graphics, simulation, scientific computing, or hardware APIs.

Many machine learning, graphics, and scientific computing workloads use 16-bit floating point formats. Native f16 support would make it easier to pass data between Rust, hardware APIs, and libraries that already use those values.

Sponsor support would help Folkert de Vries (@folkertdev), through Trifecta Tech Foundation, continue the implementation, testing, documentation, and review work needed before f16 can be considered for stabilization. Stabilization would still be decided through the Rust Project process.

Stable MIR and rustc_public

Useful when: static analysis, verification, GPU, compliance, or internal platform tools need Rust compiler data.

Stable MIR is intended to give external tools a supported way to read compiler data without depending on unstable rustc internals.

The next project goal is still pending. Funding would help Makai41 (@Makai41) and the Stable MIR project publish rustc_public to crates.io, expand API coverage, and improve documentation. API additions should be evaluated for general Rust tooling value, not for any one downstream project.

Related: previous project goal, rust-lang/rust. The next project goal has not been published yet.

Binary Size Reduction

Useful when: Rust binary size affects cold-start time, memory footprint, storage pressure, firmware size, or rollout cost.

A roadmap is being prepared for binary size reduction work led by Nia Espera (@nia-e) and Hexcat (@hexcat). Once the roadmap is published, support should focus on reductions that translate into lower cold-start time, smaller firmware or container images, and lower rollout cost for size-sensitive Rust users.

This is a funding interest area, not an approved Rust Project goal or committed outcome.

Related: rust-lang/rust. Binary-size roadmap link to be added once published.

Declarative Macro Improvements

Useful when: dependency review, supply-chain controls, or build-time code execution policies make proc macros expensive to adopt.

Better declarative macros could replace some proc macros, cutting build time, dependency surface area, and supply-chain review burden.

Funding would help Josh Triplett (@joshtriplett) work on declarative attributes and derive macros. It may also support related work by Oli Scherer (@oli-obk) on compile-time Rust evaluation, or "comptime". Design questions remain subject to the relevant RFC, lang/compiler team, and stabilization processes.

Production Systems

Tokio Runtime Optimizations

Useful when: Tokio scheduler behavior affects production latency, fairness, CPU use, or incident risk.

Tokio is the foundation for many Rust network services and async applications. Runtime and scheduler work matters when production workloads combine network IO, timers, and compute-heavy tasks.

Folkert de Vries (@folkertdev) at Tweede Golf is seeking support for runtime and scheduler improvements in Tokio. Production feedback from large Tokio users would be useful, especially where scheduler behavior affects latency or incidents. Maintainers still make changes through Tokio's public design and review process.

rustls

Useful when: production services terminate or initiate TLS and depend on timely security response, compatibility, and connection-heavy performance.

rustls is a Rust Innovation Lab project that provides TLS functionality for many Rust applications and services. Maintenance support helps pay for security response, releases, dependent-crate compatibility, and production feedback work that otherwise competes with limited maintainer time.

Dirkjan Ochtman (@djc) is seeking maintenance time for rustls security coordination, releases, contribution review, 1.0 work, async handshake performance, and production-user feedback.

Related: rustls.

Hyperium

Useful when: Rust HTTP services depend on Hyper, Tower, h2, or related crates for availability, protocol correctness, observability, or performance.

Hyperium maintains Hyper, Tower, h2, and related networking crates used by Rust services.

Sean McArthur (@seanmonstar) is seeking time for the work that keeps Hyperium crates healthy: releases, issue triage, modularization, h2 performance, buffer pooling, observability, and production-user feedback.

Related: Hyperium Roadmap.

Contact

To discuss funding, procurement, or private production feedback, contact rust-commercial-network@rustfoundation.org. For public discussion, use the RCN channel in the Rust Project Zulip.

Meeting Notetaker Role

Thank you for taking notes for a session! The following are the steps you will follow.

Reminder that we follow the RCN-wide agreed meeting policies. Please refer to the Meetings doc.

Take meeting notes live in a Google Docs document

Start with the right meeting notes template:

During the meeting you'll take meeting minutes of participants' discussion in a Google Docs document that will be shared as the meeting begins.

You'll add yourself as Notetaker for the meeting in the Google Doc.

Try to annotate live sections that are [info], [decision], and [todo]

We use an annotation system to note those sections which are [info], [decision], or [todo] so that the meeting minutes can be easily searched.

So in the meeting notes try to annotate live those points which come up that could fall into one of those categories.

Feel free to speak up during the meeting to clarify if something has risen to the level of a [decision] or [todo] if unclear.

Submit the meeting minutes to the repo

Following the meeting you will select all the contents of the Google Doc, right click, and then click Copy as Markdown on the menu that pops up. You have to make sure Markdown is enabled for the document. Enable it from Tools > Preferences by checking Enable Markdown.

Fork this repository if not done yet.

Create a new branch on your fork, open the minutes.md for the meeting you've taken minutes for, and paste the contents.

Inserting annotation key

Below the title of the meeting, date and time insert the following annotation key:

| Search Key  | Description          |
|-------------|----------------------|
| [todo]      | Action Item          |
| [decision]  | Something decided on |
| [important] | Key information      |

(Do not place in a code block in minutes.md, but placed in one here to make copying easier)

Open up a pull request from your feature branch into the main repo.

Monitor till merged

Monitor for any reviews that come through for suggestions on changes and respond back and/or update as necessary.

You're done!

Thanks again for taking on the notetaker role for the meeting.

RCN Meeting on <date> @ <time>

Search Key	Description
[todo]	Action Item
[decision]	Something decided on
[important]	Key information

Agenda

Check-in area

Please add your name, and an emoji that describes your day.

Notetaker:

For tips on how we take notes in the RCN, please see the Meeting Notetaker Role doc.

<Foo> RCN Initiative Meeting on <date> @ <time>

Search Key	Description
[todo]	Action Item
[decision]	Something decided on
[important]	Key information

Agenda

Check-in area

Please add your name, and an emoji that describes your day.

Notetaker:

For tips on how we take notes in the RCN, please see the Meeting Notetaker Role doc.