dotnet/csharplang: Inside the C# Language Design Repository

What the csharplang Repository Is and Is Not

Dotnet/csharplang is not a compiler repository. It does not contain the C# compiler or its runtime. The C# compiler lives in the Roslyn repository at github.com/dotnet/roslyn, which is a separate codebase maintained alongside csharplang. What csharplang contains is the design governance infrastructure: proposals describing new features, notes from language design meetings, and the formal language specification.

This distinction matters for developers who want to understand where C# features come from. A feature does not exist because a team member wrote it and merged a pull request. It exists because it was proposed, debated in discussions, adopted as a champion proposal by a member of the C# Language Design Team (LDT), evaluated across one or more design meetings, prototyped in a Roslyn fork, and then fully implemented in Roslyn and specified in the spec folder. The csharplang repository is the paper trail for that entire process.

The repository is also not an issue tracker for the C# compiler or the .NET runtime. Bugs in the compiler belong in the Roslyn repository. Questions about .NET behavior belong in the dotnet/runtime repository. csharplang is specifically for the design of the language itself.

From Discussion to Champion: How Proposals Enter the Process

The process for getting a new feature into C# starts with a Discussion, not a pull request. The README is explicit: new feature proposals should be raised as Discussions first, and a proposal should only be submitted as an issue or pull request if a member of the Language Design Team explicitly invites the author to do so by becoming its champion.

A champion is an LDT member who agrees that a proposal merits consideration by the full team. Championing means the LDT member will bring the proposal to a language design meeting. The champion issue on the repository tracks the proposal's status; discussions happen in linked Discussion threads rather than on the champion issue itself, and issues are locked to prevent further discussion on them.

This two-stage entry point (discussion before champion issue) filters the volume of proposals that the LDT must formally evaluate. The README notes that discussions should stay on topic and that short, focused discussions are more likely to be read. The reasoning is practical: the LDT has limited time for language design work, and diffuse or unfocused discussions impose a cost on the team without proportionate benefit.

Language Design Meetings and the Record They Leave

Language Design Meetings (LDMs) are held by the LDT with occasional invited guests. Notes from each meeting are published in the meetings folder, organized by year. These notes document what was decided, what was deferred, and what was rejected, with the reasoning for each decision.

The meetings folder is one of the most useful parts of the repository for developers who want to understand why the language works the way it does. For any feature that went through the design process, the meeting notes show the alternative designs that were considered and discarded, the edge cases that drove the final choice of syntax or semantics, and the implementation concerns raised by the Roslyn team.

The README explains that the lifetime of a design meeting note is described in meetings/README.md within the repository. Notes are not intended to be living documents: once written, they record the state of the discussion at the time of the meeting, and later decisions appear in later meeting notes rather than as edits to earlier ones.

Milestones: How Features Get Prioritized

The repository uses GitHub milestones to communicate the status of championed proposals. The README describes five categories.

The Working Set milestone is the active queue: proposals in it are receiving design time during the current release cycle. Not everything in the Working Set will make the next C# version, but it will be discussed.

The Backlog milestone holds championed proposals that have been triaged but are not receiving active design time. Community discussion is welcome, but the LDT is not working on these proposals currently.

The Any Time milestone holds proposals that are open to community implementation. Issues here are either waiting for an approved specification or waiting for implementation in Roslyn. For those that need a specification, the LDT will review and approve at its earliest convenience.

The Likely Never milestone is for proposals the LDT has rejected. The README states that without strong new need or community feedback, these will not be reconsidered.

Numbered milestones correspond to specific C# versions. For shipped versions, they list what was included. For the open milestone representing the next version, they show what is targeted, with the caveat that features may be pulled before release.

This milestone system is a practical transparency mechanism. A developer who wants to know whether a particular feature is under active consideration can check whether a champion issue exists and which milestone it is assigned to.

Prototyping in Roslyn Before Committing to a Feature

The design process described in the README requires a prototype for most features before the language team commits to a final design. A prototype is implemented as a fork of the Roslyn repository and must meet a specific bar described in the README: parsing should be resilient to in-progress typing without crashes, minimal tests must demonstrate the feature end-to-end, and minimal IDE support (keyword coloring, formatting, and completion) must be included.

This prototype requirement serves two purposes. First, it forces the feature to be specified precisely enough that it can be implemented, which catches ambiguities in the proposal that prose discussion alone might not reveal. Second, it tests usability: a feature that looks clean on paper may have surprising interaction effects with other language features that only appear when code is actually written and compiled.

Prototypes are sometimes published on the Roslyn GitHub repository as forks, and the resulting implementation experience feeds back into the design meeting notes. For features that ultimately ship, the prototype is refined into a full implementation, the proposal is moved to the appropriate versioned folder in csharplang, and the specification text is added to the spec directory.

Browsing What Shipped and What Was Rejected

The proposals folder is organized by C# version. Completed proposals for a given version are in a subfolder named for that version, for example proposals/csharp-7.1 for features that shipped in C# 7.1. The README mentions this organizational pattern explicitly.

The Language-Version-History.md file at the root provides a summary of language version history, which serves as an index for finding which release introduced a given feature. For developers who encounter a C# construct and want to understand when it was added and what design decisions shaped it, the path is: find the feature in Language-Version-History.md, navigate to the corresponding proposals subfolder, read the final proposal and then the meeting notes that reference it.

The Likely Never milestone and the locked champion issues that carry a rejection note provide a record of what was considered and declined. This is useful context when evaluating proposals: if a similar idea was rejected before, the meeting notes for the rejection document the reasoning, which may still apply to a new variation of the same idea.

The spec folder contains the normative language specification. The README does not document the licence covering this specification text, which is a gap for organizations that want to formally cite or redistribute it.

Maintenance, Licence, and How to Participate

The repository accepted its last push on 2026-09-18, indicating active work at the time of writing. New features discussed and designed here will be implemented in the Roslyn compiler under a separate release schedule.

The repository does not have a declared licence in the GitHub metadata. The README does not document licence terms for the proposal text or the specification. Developers who want to reproduce, adapt, or incorporate specification text into external documents should contact the project maintainers directly to clarify the terms.

Participation in the language design process is open to the community at the discussion stage. Opening a Discussion is the documented first step. Pull requests that arrive without a champion invitation will be outside the process and are unlikely to be accepted. The CODE-OF-CONDUCT.md at the repository root governs participation in discussions.

For developers who want to follow the process without contributing, watching the repository and filtering for new design meeting notes in the meetings folder provides a running record of what the C# language team is working on and what they decided.

Editorial conclusion

The csharplang repository is valuable to two audiences: developers who want to understand why C# behaves the way it does and follow decisions being made about future versions, and developers who want to participate in the language design process. For the first group, the meetings folder and the versioned proposals folder are the relevant sections. For the second group, the correct first step is to open a Discussion, not a pull request: the README is explicit that proposals submitted without an invitation from a Language Design Team member will not be accepted. The absence of an assigned licence is a practical concern for anyone who wants to reproduce specification text outside the repository.

Frequently asked questions

Official sources

1. dotnet/csharplang on GitHub
2. Issues
3. README