Inside Rust Blog

A note on the Trademark Policy Draft

2023-04-12T00:00:00+00:00

A note on the Trademark Policy Draft

For the past eight months, the Rust Foundation Project Directors have been working with the informal Trademark Working Group and the Foundation staff to draft an updated policy and FAQ for the Rust trademark. We'd like to provide some context around this work and address the community response to the feedback form for the recently circulated draft.

Background

Back when the Rust Foundation was created, one of the first things to happen was Mozilla transferring its ownership of the Rust trademark to the newly created foundation. An update to the existing policy was needed, and project leadership planned for this to be done together with the Foundation.

Since we wanted to incorporate community input to this policy and make it accessible as possible, the board waited until the Foundation was well-staffed to coordinate the effort. That included things like running a community-wide survey and discussing the result with a number of stakeholders, including the board, community members, project leadership, as well as legal counsel. The latest state of this process is the draft that was published late last week.

Our approach

Since the draft was announced, we've noticed a widespread impression that this policy was created solely by the Foundation and is being imposed on the Rust Project and community. That is not true. The policy draft was created with the input and consent of each of the co-authors of this post, with the intent to clarify existing policies, incorporate community feedback, and preserve the Rust brand for years to come. The Foundation also cannot – and has no interest in – unilaterally adopting such a policy without the agreement and involvement of its Project Directors.

There can be wildly differing opinions on how to achieve a particular intent.¹ Fundamentally however, the question at hand is whether we want Rust to be a trademark or not. If we want to be able to defend Rust as the brand it is today, trademark law fundamentally constrains how permissible we can be, especially in public guidelines.

Our answer to the question of whether Rust should be a trademark has been "yes", just as it has been since before Rust 1.0. Furthermore, our goal is to make a policy that is as permissive as it can be without substantially giving up our right to define what Rust is and is not in the future. Not all open source projects have retained that right.

We aren't lawyers and we leave the question of how to do that to them – and believe us when we say we have gone through many rounds of questions with ours, who have extensive experience in open source projects.

Feedback

The current proposal is a draft that the Foundation staff, Project Directors, and Trademark Working Group are actively seeking feedback on. We will not ship a trademark policy that Project representatives and the Foundation aren't happy with and proud of after reviewing community feedback.

We genuinely appreciate all the thoughtful input the community has already left, both in public and via the feedback form.² Please continue to utilize this form as the official way of getting feedback back into this process. We know the draft is not perfect, and we're committed to fixing any mistakes identified and considering the feedback we get.

Unfortunately, in addition to the large volume of thoughtful and respectful feedback, we're ashamed to say we've seen firsthand examples of significant harassment and abuse directed at the Foundation staff. We condemn this in the strongest possible terms. These folks have been doing their best to navigate an extremely diverse set of interests and viewpoints throughout this process. It's unacceptable for anyone in the Rust community to demean, harass or insult anyone, let alone the people we've asked to do this work.

Please remember that any and all communication with Foundation staff is subject to the Rust project Code of Conduct and will be enforced accordingly. We don't expect this to be an issue for most people participating, but when emotions run high it's always a good idea to check your assumptions and remember the person on the other end of the keyboard.

Next steps

We want to thank the community for participating in this process, and for your patience as we learn the best way to navigate it. We recognize that the process and communication around it could have been better. Notably, the wider project was insufficiently included in the process. We were responsible for that and apologize.

We're committed to learning everything we can from this process and your feedback, and to talking as openly as we can about what we've learned. To that end, we will soon conduct and publish a retrospective around how the process unfolded.

Thank you again to those who have shared their thoughts on the Rust Trademark Policy draft respectfully. A summary of the feedback received will be shared after the consultation period closes. If you have not yet reviewed the draft, we invite you to fill out the feedback form by April 16 at 5 PM PDT. We only ask that you treat everyone in this community, including the Rust Foundation team, respectfully when doing so.

Sincerely,

Ryan Levick, Project Director and trademark working group member
Jane Losare-Lusby, Project Director
Tyler Mandry, Project Director
Mark Rousskov, Project Director
Josh Stone, Project Director and trademark working group member
Josh Triplett, Lang team lead and trademark working group member

This was none more apparent than when the community survey got over 1,000 responses, representing a number of popular but fundamentally incompatible views. ↩
We know this feedback-via-form exercise is not familiar, and we're still getting used to it, too. But it's really the best we can do when we're asking a heroic staff to read and respond to the feedback, and when it's a legal matter where what we say can have substantial consequences down the line. ↩

Welcome Arlo and Scott to the Cargo Team

2023-04-06T00:00:00+00:00

We are excited to welcome Arlo Siemsen and Scott Schafer as new members to the Cargo Team!

Arlo has been instrumental in bringing Cargo's new sparse registry support to fruition, which significantly improves registry performance. He has been involved with registry design and authentication discussions, and has been closely working with the team over the past year.

Scott has been very active in the past year, working on various parts of Cargo, namely implementing workspace inheritance. Since then, he has been helping with maintenance and designing new features.

With their help we now have capacity to start thinking about how feature development should be done moving forward. We are still in early discussions of processes for matching feature development with reviewer capacity, and will share more in the future. Thanks to Arlo and Scott for their help, and we are very much looking forward to having them as a part of the team!

1.68.2 pre-release testing

2023-03-27T00:00:00+00:00

The 1.68.2 pre-release is ready for testing. The release is scheduled for March 28. Release notes can be found here.

You can try it out locally by running:

RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup update stable

The index is https://dev-static.rust-lang.org/dist/2023-03-27/index.html.

You can leave feedback on the internals thread.

The release team is also thinking about changes to our pre-release process: we'd love your feedback on this GitHub issue.

1.68.1 pre-release testing

2023-03-20T00:00:00+00:00

The 1.68.1 pre-release is ready for testing. The release is scheduled for March 23. Release notes can be found here.

You can try it out locally by running:

RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup update stable

The index is https://dev-static.rust-lang.org/dist/2023-03-20/index.html.

You can leave feedback on the internals thread.

The release team is also thinking about changes to our pre-release process: we'd love your feedback on this GitHub issue.

1.68.0 pre-release testing

2023-03-06T00:00:00+00:00

The 1.68.0 pre-release is ready for testing. The release is scheduled for March 09. Release notes can be found here.

You can try it out locally by running:

RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup update stable

The index is https://dev-static.rust-lang.org/dist/2023-03-06/index.html.

You can leave feedback on the internals thread.

The release team is also thinking about changes to our pre-release process: we'd love your feedback on this GitHub issue.

Keyword Generics Progress Report: February 2023

2023-02-23T00:00:00+00:00

Introduction

About 9 months ago we announced the creation of the Keyword Generics Initiative; a group working under the lang team with the intent to solve the function coloring problem ¹ through the type system not just for async, but for const and all current and future function modifier keywords as well.

We're happy to share that we've made a lot of progress over these last several months, and we're finally ready to start putting some of our designs forward through RFCs. Because it's been a while since our last update, and because we're excited to share what we've been working on, in this post we'll be going over some of the things we're planning to propose.

An async example

In our previous post we introduced the placeholder async<A> syntax to describe the concept of a "function which is generic over its asyncness". We always knew we wanted something that felt lighter weight than that, so in for our current design we've chosen to drop the notion of a generic parameter for the end-user syntax, and instead picked the ?async notation. We've borrowed this from the trait system, where for example + ?Sized indicates that something may or may not implement the Sized trait. Similarly ?async means a function may or may not be async. We also refer to these as "maybe-async" functions.

Time for an example. Say we took the Read trait and the read_to_string_methods. In the stdlib their implementations look somewhat like this today:

trait Read {
    fn read(&mut self, buf: &mut [u8]) -> Result<usize>;
    fn read_to_string(&mut self, buf: &mut String) -> Result<usize> { ... }
}

/// Read from a reader into a string.
fn read_to_string(reader: &mut impl Read) -> std::io::Result<String> {
    let mut string = String::new();
    reader.read_to_string(&mut string)?;
    Ok(string)
}

Now, what if we wanted to make these async in the future? Using ?async notation we could change them to look like this:

trait ?async Read {
    ?async fn read(&mut self, buf: &mut [u8]) -> Result<usize>;
    ?async fn read_to_string(&mut self, buf: &mut String) -> Result<usize> { ... }
}

/// Read from a reader into a string.
?async fn read_to_string(reader: &mut impl ?async Read) -> std::io::Result<String> {
    let mut string = String::new();
    reader.read_to_string(&mut string).await?;
    Ok(string)
}

The way this would work is that Read and read_to_string would become generic over their "asyncness". When compiled for an async context, they will behave asynchronously. When compiled in a non-async context, they will behave synchronously. The .await in the read_to_string function body is necessary to mark the cancellation point in case the function is compiled as async; but when not async would essentially become a no-op ²:

// `read_to_string` is inferred to be `!async` because
// we didn't `.await` it, nor expected a future of any kind.
#[test]
fn sync_call() {
    let _string = read_to_string("file.txt")?;
}

// `read_to_string` is inferred to be `async` because
// we `.await`ed it.
#[async_std::test]
async fn async_call() {
    let _string = read_to_string("file.txt").await?;
}

We expect ?async notation would be most useful for library code which doesn't do anything particularly specific to async Rust. Think: most of the stdlib, and ecosystem libraries such as parsers, encoders, and drivers. We expect most applications to choose to be compiled either as async or non-async, making them mostly a consumer of ?async APIs.

A const example

A main driver of the keywords generics initiative has been our desire to make the different modifier keywords in Rust feel consistent with one another. Both the const WG and the async WG were thinking about introducing keyword-traits at the same time, and we figured we should probably start talking with each other to make sure that what we were going to introduce felt like it was part of the same language - and could be extended to support more keywords in the future.

So with that in mind, it may be unsurprising that for the maybe-const trait bounds and declarations we're going to propose using the ?const notation. A common source of confusion with const fn is that it actually doesn't guarantee compile-time execution; it only means that it's possible to evaluate in a const compile-time context. So in a way const fn has always been a way of declaring a "maybe-const" function, and there isn't a way to declare an "always-const" function. More on that later in this post.

Taking the Read example we used earlier, we could imagine a "maybe-const" version of the Read trait to look very similar:

trait ?const Read {
    ?const fn read(&mut self, buf: &mut [u8]) -> Result<usize>;
    ?const fn read_to_string(&mut self, buf: &mut String) -> Result<usize> { ... }
}

Which we could then use use as a bound in the const read_to_string function, like this:

const fn read_to_string(reader: &mut impl ?const Read) -> std::io::Result<String> {
    let mut string = String::new();
    reader.read_to_string(&mut string)?;
    Ok(string)
}

Just like with ?async traits, ?const traits would also need to be labeled as ?const when used as a bound. This is important to surface at the trait level, because it's allowed to pass non-const bounds to maybe-const functions, as long as no trait methods are called in the function body. This means we need to distinguish between "never-const" and "maybe-const".

You may have noticed the ?const on the trait declaration and the extra ?const on the trait methods. This is on purpose: it keeps the path open to potentially add support for "always-const" or "never-const" methods on traits as well. In ?async we know that even if the entire trait is ?async, some methods (such as Iterator::size_hint) will never be async. And this would make ?const and ?async traits behave similarly using the same rules.

Combining const and async

We've covered ?async, and we've covered ?const. Now what happens if we were to use them together? Let's take a look at what the Read trait would look like when if we extended it using our designs for ?const and ?async:

trait ?const ?async Read {
    ?const ?async fn read(&mut self, buf: &mut [u8]) -> Result<usize>;
    ?const ?async fn read_to_string(&mut self, buf: &mut String) -> Result<usize> { .. }
}

/// Read from a reader into a string.
const ?async fn read_to_string(reader: &mut impl ?const ?async Read) -> io::Result<String> {
    let mut string = String::new();
    reader.read_to_string(&mut string).await?;
    Ok(string)
}

That's sure starting to feel like a lot of keywords, right? We've accurately described exactly what's going on, but there's a lot of repetition. We know that if we're dealing with a const ?async fn, most arguments probably will want to be ?const ?async. But under the syntax rules we've proposed so far, you'd end up repeating that everywhere. And it probably gets worse once we start adding in more keywords. Not ideal!

So we're very eager to make sure that we find a solution to this. And we've been thinking about a way we could get out of this, which we've been calling effect/.do-notation. This would allow you to mark a function as "generic over all modifier keywords" by annotating it as effect fn, and it would allow the compiler to insert all the right .await, ?, and yield keywords in the function body by suffixing function calls with .do.

Just to set some expectations: this is the least developed part of our proposal, and we don't intend to formally propose this until after we're done with some of the other proposals. But we think it's an important part of the entire vision, so we wanted to make sure we shared it here. And with that out of the way, here's the same example we had above, but this time using the effect/.do-notation:

trait ?effect Read {
    ?effect fn read(&mut self, buf: &mut [u8]) -> Result<usize>;
    ?effect fn read_to_string(&mut self, buf: &mut String) -> Result<usize> { .. }
}

/// Read from a reader into a string.
?effect fn read_to_string(reader: &mut impl ?effect Read) -> std::io::Result<String> {
    let mut string = String::new();
    reader.read_to_string(&mut string).do;  // note the singular `.do` here
    string
}

One of the things we would like to figure out as part of effect/.do is a way to enable writing conditional effect-bounds. For example: there may be a function which is always async, may never panic, and is generic over the remainder of the effects. Or like we're seeing with APIs such as Vec::reserve and Vec::try_reserve: the ability to panic xor return an error. This will take more time and research to figure out, but we believe it is something which can be solved.

Adding support for types

Something we're keen on doing is not just adding support for ?async and to apply to functions, traits, and trait bounds. We would like ?async to be possible to use with types as well. This would enable the ecosystem to stop having to provide both sync and async versions of crates. It would also enable the stdlib to gradually "asyncify" just like we have been with const.

The challenge with async types, especially in the stdlib, is that their behavior will often have to be different when used in async and non-async contexts. At the very lowest level async system calls work a bit differently from non-async system calls. But we think we may have a solution for that too in the form of the is_async compiler built-in method.

Say we wanted to implement ?async File with a single ?async open method. The way we expect this to look will be something like this:

/// A file which may or may not be async
struct ?async File {
    file_descriptor: std::os::RawFd,  // shared field in all contexts
    async waker: Waker,               // field only available in async contexts
    !async meta: Metadata,            // field only available in non-async contexts
}

impl ?async File {
    /// Attempts to open a file in read-only mode.
    ?async fn open(path: Path) -> io::Result<Self> {
        if is_async() {   // compiler built-in function
            // create an async `File` here; can use `.await`
        } else {
            // create a non-async `File` here
        }
    }
}

This would enable authors to use different fields depending on whether they're compiling for async or not, while still sharing a common core. And within function bodies it would be possible to provide different behaviors depending on the context as well. The function body notation would work as a generalization of the currently unstable const_eval_select intrinsic, and at least for the function bodies we expect a similar is_const() compiler built-in to be made available as well.

Consistent syntax

As we alluded to earlier in the post: one of the biggest challenges we see in language design is adding features in a way that makes them feel like they're in harmony with the rest of the language - and not something which stands out as noticably different. And because we're touching on something core to Rust, the way we do keywords, we have to pay extra close attention here to make sure Rust keeps feeling like a single language.

Luckily Rust has the ability to make surface-level changes to the language through the edition system. There are many things this doesn't let us do, but it does allow us to require syntax changes. A possibility we're exploring is leveraging the edition system to make some minor changes to const and async so they feel more consistent with one another, and with ?const and ?async.

For const this means there should be a syntactic distinction between const declarations and const uses. Like we mentioned earlier in the post, when you write const fn you get a function which can be evaluated both at runtime and during compilation. But when you write const FOO: () = ..; the meaning of const there guarantees compile-time evaluation. One keyword, different meanings. So for that reason we're wondering whether perhaps it would make more sense if we changed const fn to ?const fn. This would make it clear that it's a function which may be const-evaluated, but doesn't necessarily have to - and can also be called from non-const contexts.

//! Define a function which may be evaluated both at runtime and during
//! compilation.

// Current
const fn meow() -> String { .. }

// Proposed
?const fn meow() -> String { .. }

For async we're considering some similar surface-level changes. The Async WG is in the process of expanding the "async functions in traits" design into an design covering "async traits" entirely, largely motivated by the desire to be able to add + Send bound to anonymous futures. There are more details about this in "Lightweight, Predictable Async Send Bounds" by Eric Holk. But it would roughly become the following notation:

struct File { .. }
impl async Read for File {                                                // async trait declaration
    async fn read(&mut self, buf: &mut [u8]) -> io::Result<usize> { .. }  // async method
}

async fn read_to_string(reader: &mut impl async Read) -> io::Result<String> { // async trait bound
    let mut string = String::new();
    reader.read_to_string(&mut string).await?;
    Ok(string)
}

This would make impl ?async Read and impl async Read consistent with each other. And it would open the door for trait ?async traits to be passed to impl async Read and be guaranteed to be always interpreted as trait async. Which is another nice consistency gain.

The final thing we're looking at is async-notation for types. To implement inherent ?async methods on types, our current design requires the type to also be marked as ?async. In order to bring ?async and async closer together, we're exploring whether it might also make sense to require types to be marked as async as well:

//! Proposed: define a method on a maybe-async type
struct ?async File { .. }
impl ?async File {
    ?async fn open(path: PathBuf) -> io::Result<Self> { .. }
}

//! Current: define a method on an always-async type
struct File { .. }
impl File {
    async fn open(path: PathBuf) -> io::Result<Self> { .. }
}

//! Proposed: define a method on an always-async type
struct async File { .. }
impl async File {
    async fn open(path: PathBuf) -> io::Result<Self> { .. }
}

We already have something similar going on for "always-const" arguments via the const-generics system. These look something like this:

fn foo<const N: usize>() {}

Every "always-const" argument to the function must always be marked by const, so it wouldn't be entirely without precedent for every "always-async" type to always require to be marked using async. So we're exploring some of what might be possible here.

The tentative plan

We plan to initially focus our efforts on the async and const keywords only. We're feeling ready to start converting some of our designs into RFCs, and start putting them out for review. In the coming months we expect to start writing the following proposals (in no particular order):

?async fn notation without trait bounds, including an is_async mechanism.
trait async declarations and bounds.
trait ?async declarations and bounds, trait ?const declarations and bounds.
?const fn notation without trait bounds.
struct async notation and struct ?const notation.

We'll be working closely with the Lang Team, Const WG, and Async WG on these proposals, and in some cases (such as trait async) we may even take an advising role with a WG directly driving the RFC. As usual, these will be going through the RFC-nightly-stabilization cycle. And only once we're fully confident in them will they become available on stable Rust.

We're intentionally not yet including effect/.do notation on this roadmap. We expect to only be able to start this work once we have ?async on nightly, which we don't yet have. So for now we'll continue work on designing it within the initiative, and hold off on making plans to introduce it quiet yet.

Conclusion

And that concludes the 9-month progress report of the Keyword Generics Initiative. We hope to be able to provide more exact details about things such as desugarings, semantics, and alternatives in the RFCs. We're pretty stoked with the progress we've made in these past few months! Something which I don't think we've mentioned yet, but is probably good to share: we've actually prototyped much of the work in this post already; so we're feeling fairly confident all of this may actually actually work. And that is something we're incredibly excited for!

To briefly recap this problem: you can't call an async fn from a non-async fn. This makes the "async" notation go viral, as every function that calls it also needs to be async. But we believe possibly more importantly: it requires a duplication of most stdlib types and ecosystem libraries. Instead we suspected we might be able to overcome this issue by introducing a new kind of generic which would enable functions and types to be "generic" over whether they're async or not, const or not, etc. ↩
One restriction ?async contexts have is that they can only call other ?async and non-async functions. Because if we could call an always-async function, there would be no clear right thing to do when compiled in non-async mode. So things like async concurrency operations won't directly work in always-async contexts. But we have a way out of this we talk about later in the post: if is_async() .. else ... This allows you to branch the body of a ?async fn based on which mode it's being compiled in, and will allow you to write different logic for async and non-async modes. This means you can choose to use async concurrency in the async version, but keep things sequential in the non-async version. ↩

Governance Reform RFC Announcement

2023-02-22T00:00:00+00:00

As part of ongoing work on governance, the "leadership chat" established a smaller "governance reform" working group to create an RFC to establish new project wide governance. This RFC is now live and can found on the RFCs repo: https://github.com/rust-lang/rfcs/pull/3392

We have set up a Zulip stream to provide an additional dedicated place for feedback on the RFC. In addition, team leads will be asking their respective teams for feedback directly. However, anyone is welcome to participate and provide feedback directly in the Zulip stream or the RFC PR if they prefer.

Again, if you have any questions or concerns, please don't hesitate to reach out.

Welcome Tyler Mandry to the Rust language team!

2023-02-14T00:00:00+00:00

We are happy to announce that Tyler Mandry is joining the Rust language design team as a full member!

Tyler has been driving the design of async functions in traits over the last year. In that process Tyler has authored two RFCs, #3185 (static async functions in traits) and #3245 (refined trait impls), both of which were accepted. He has good instincts for language design and orthogonality, devising general solutions to address a range of use cases with a small set of language changes, such as contexts/capabilities and dyn*.

Tyler is also a strong implementor. He was a past contributor to the chalk project and understands the intricacies of the trait and type system quite well. He also implemented a number of improvements to async Rust, such as work to reduce the size of futures.

Throughout his work on Rust, Tyler has demonstrated his ability to drive discussions towards consensus on a number of occasions. For example, he helped to navigate questions around boxing and auto-traits. He always makes an effort to understand people's points, even when he disagrees with their conclusions.

Welcome to the team, Tyler!

Language team advisors

2023-02-14T00:00:00+00:00

RFC #3327 created a new lang-team subteam, the lang team advisors. The advisors team recognizes people who regularly aid the Rust community and the lang team in particular in language design decisions. We already value their input highly and treat their concerns as blocking on features or proposals. The advisors team gives us a way to acknowledge them officially.

The initial advisors team consists of the following people:

Ralf Jung is a leader in designing Rust's rules for unsafe code as well as, through his work on miri, the semantics of compile-time evaluation. His work on stacked borrows and minirust has moved the state of that conversation forward in major ways, and he has also driven a number of language changes related to that area.

Jakob Degen is one of the authorities around the semantics of unsafe code. He has consistently shown the ability to aggregate opinion, identify the key constraints to respect and those to disregard, and find consensus solutions.

Mark Rousskov has been a huge part of the Rust community for many years now, and participates regularly in lang-team meetings. He has a wide knowledge of Rust and its nooks and crannies, and often brings key insights to our discussions.

Jack Huey co-leads the types team, and provides expertise in the workings of Rust's trait and type system, as well as the chalk system.

Amanieu d'Antras leads the design of inline assembly and has been involved as an expert in a number of other areas, such as the "FFI unwind" working group.

Wesley Wiser is the co-lead of the compiler team. He's been involved in the project for many years and is an expert on the overall compiler architecture as well as several areas within.

Alex Crichton is a well-known figure to many Rustaceans. Among other things, he is a former lead of the libs team, a key cargo contributor, and drove extensive work for Rust in WebAssembly. Indeed, it's hard to find a part of Rust that Alex hasn't had an impact on.

Finally, as part of this change, Taylor Cramer will be stepping back as a full-time lang team member and becoming an advisor. In his time on the lang team, Taylor was a core driver for async/await, impl Trait, and a number of other highly impactful language features. We look forward to continuing to have his guidance as an advisor going forward.

Rust Compiler February 2023 Steering Cycle

2023-02-10T00:00:00+00:00

On Friday, February 10th, the Rust Compiler team had a planning meeting for the February 2023 steering cycle.

T-compiler June Steering Schedule

Date	Meeting Id	Meeting Topic
2023-02-17	compiler-team#589	Dealing with PR review latency
2023-02-24	compiler-team#583	Scope and goals of rust-lang/rust optimizations
2023-03-03	compiler-team#590	P-high review for 2023 Q1
2023-03-10	none	(planning for March cycle)

Details

Every fourth Friday, the Rust compiler team decides how it is going to use its scheduled steering and design meeting time over the next three Fridays.

On Friday, 17 February, we will discuss ways to improve our Pull Request review latency. Jack Huey, apiraino, and oli-obk will work on a document to drive the meeting, collecting ideas on how to attack the problem.

On Friday, 24 February, we will discuss our philosophy about code optimizations that are implemented in the rust-lang/rust repository (as opposed to optimizations that are implemented in LLVM itself, which is where the bulk of our optimization logic currently resides). Jak{e,ob} Degen will author the document driving this meeting.

On Friday, 3 March, we will do a quarterly review of the open P-high issues. pnkfelix will do some ahead of time work in zulip triaging some of the issues, and potentially prepare a meeting document summarizing the remainder, to maximize the quality of our synchronous in-meeting time.

On Friday, 10 March, we will hold our planning meeting for the next steering cycle in March and April.

Each meeting will run from 2pm to 3pm GMT, and will take place on the T-compiler/meetings zulip stream.