Update READMEs for discussion in GitHub issues

README.md

@@ -1,40 +1,50 @@
 # C# Language Design
 
-Welcome to the official repo for C# language design.
+Welcome to the official repo for C# language design. This is where new C# language features are developed, adopted and specified.
 
-* Full Language Specification: [Markdown](spec)
-* List of [Active](proposals), [Adopted](proposals/adopted), and [Rejected](proposals/rejected) proposals can be found in the [proposals folder](proposals).
-* Archives of mailing lists discussions can be found [here](https://lists.dot.net/pipermail/csharplang/).
-* Archives of notes from design meetings, etc., can be found in the [meetings folder](meetings).
+C# is designed by the C# Language Design Team (LDT) in close coordination with the [Roslyn](https://github.com/dotnet/roslyn) project, which implements the language.
+
+You can find:
+
+- Active C# language feature proposals in the [proposals folder](proposals)
+- Notes from C# language design meetings in the [meetings folder](meetings)
+- Full language specification (draft) in the [spec folder](spec)
+
+If you discover bugs or deficiencies in the above, please leave an issue to raise them, or even better: a pull request to fix them.
+
+For *new feature proposals*, however, please raise them for [discussion](https://github.com/dotnet/csharplang/labels/Discussion), and *only* submit a proposal as a pull request if invited to do so by a member of the Language Design Team (a "champion").
+
+## Discussion
+
+Discussion pertaining to language features takes place in the form of issues in this repo, under the [Discussion label](https://github.com/dotnet/csharplang/labels/Discussion).
+
+If you want to suggest a feature, discuss current design notes or proposals, etc., please [open a new issue](https://github.com/dotnet/csharplang/issues/new), and it will be tagged Discussion.
+
+GitHub is not ideal for discussions, but it is beneficial to have language features discussed nearby to where the design artifacts are. Comment threads that are short and stay on topic are much more likely to be read. If you leave comment number fifty, chances are that only a few people will read it. To make discussions easier to navigate and benefit from, please observe a few rules of thumb:
+
+- Discussion should be relevant to C# language design. Issues that are not will be summarily closed.
+- Choose a descriptive title for the issue, that clearly communicates the scope of discussion.
+- Stick to the topic of the issue title. If a comment is tangential, start a new issue and link back.
+- If a comment goes into detail on a subtopic, also consider starting a new issue and linking back.
+- Is your comment useful for others to read, or can it be adequately expressed with an emoji reaction to an existing comment?
 
 ## Design Process
 
-C# is designed by the C# Language Design Team (LDT).
+[Proposals](proposals) are raised by, or on invitation from, "champions" on the LDT. They evolve as a result of decisions in [Language Design Meetings](meetings), which are informed by [discussion](https://github.com/dotnet/csharplang/labels/Discussion), experiments, and offline design work.
 
-1. To submit, support, and discuss ideas please subscribe to the [language design mailing list](https://lists.dot.net/mailman/listinfo/csharplang).
+In many cases it will be necessary to implement and share a prototype of a feature in order to land on the right design, and ultimately decide whether to adopt the feature. Prototypes help discover both implementation and usability issues of a feature. A prototype should be implemented in a fork of the [Roslyn repo](https://github.com/dotnet/roslyn) and meet the following bar:
 
-2. Ideas that the LDT feel could potentially make it into the language should be turned into [proposals](proposals), based on this [template](proposals/proposal-template.md), either by members of the LDT or by community members by invitation from the LDT. The lifetime of a proposal is described in [proposals/README.md](proposals/README.md). A good proposal should:
-    * Fit with the general theme and aesthetic of the language.
-    * Not introduce subtly alternate syntax for existing features.
-    * Add a lot of value for a clear set of users.
-    * Not add significantly to the complexity of the language, especially for new users.  
+- Parsing (if applicable) should be resilient to experimentation: typing should not cause crashes.
+- Include minimal tests demonstrating the feature at work end-to-end.
+- Include minimal IDE support (keyword coloring, formatting, completion).
 
-3. A prototype owner (who may or may not be proposal owner) should implement a prototype in their own fork of the [Roslyn repo](https://github.com/dotnet/roslyn) and share it with the design team and community for feedback. A prototype must meet the following bar:
-	* Parsing (if applicable) should be resilient to experimentation--typing should not cause crashes.
-	* Include minimal tests demonstrating the feature at work end-to-end.
-	* Include minimal IDE support (keyword coloring, formatting, completion).
+Once approved, a feature should be fully implemented in [Roslyn](https://github.com/dotnet/roslyn), and fully specified in the [language specification](spec), whereupon the proposal is moved into the appropriate folder for a completed feature, e.g. [C# 7.1 proposals](proposals/csharp-7.1).
 
-4. Once a prototype has proven out the proposal and the proposal has been _approved-in-principle_ by the design team, a feature owner (who may or may not be proposal or prototype owner(s)) implemented in a feature branch of the [Roslyn repo](https://github.com/dotnet/roslyn). The bar for implementation quality can be found [here](https://github.com/dotnet/roslyn).
-
-5. Design changes during the proposal or feature implementation phase should be fed back into the original proposal as a PR describing the nature of the change and the rationale.
-
-6. A PR should be submitted amending the formal language specification with the new feature or behavior.
-
-7. Once a feature is implemented and merged into shipping branch of Roslyn and the appropriate changes merged into the language specification, the proposal should be archived under a folder corresponding to the version of the language in which it was included, e.g. [C# 7.1 proposals](proposals/csharp-7.1)). Rejected proposals are archived under the [rejected folder](proposals/rejected).
+**DISCLAIMER**: An active proposal is under active consideration for inclusion into a future version of the C# programming language but is not in any way guaranteed to ultimately be included in the next or any version of the language. A proposal may be postponed or rejected at any time during any phase of the above process based on feedback from the design team, community, code reviewers, or testing.
 
 ## Language Design Meetings
 
-Language Design Meetings (LDMs) are held by the LDT and occasional invited guests, and are documented in Design Meeting Notes in the [meetings](meetings) folder, organized in folders by year. The lifetime of a design meeting note is described in [meetings/README.md](meetings/README.md). LDMs are where decisions about future C# versions are made, including which proposals do work on, how to evolve the proposals, and whether and when to adopt them.
+Language Design Meetings (LDMs) are held by the LDT and occasional invited guests, and are documented in Design Meeting Notes in the [meetings](meetings) folder, organized in folders by year. The lifetime of a design meeting note is described in [meetings/README.md](meetings/README.md). LDMs are where decisions about future C# versions are made, including which proposals to work on, how to evolve the proposals, and whether and when to adopt them.
 
 ## Language Specification
 
@@ -43,5 +53,3 @@ It is our plan to move the C# Language Specification into Markdown, and draft it
 ## Implementation
 
 The reference implementation of the C# language can be found in the [Roslyn repository](https://github.com/dotnet/roslyn). Until recently, that was also where language design artifacts were tracked. Please allow a little time as we move over active proposals.
-
-**DISCLAIMER**: An active proposal is under active consideration for inclusion into a future version of the C# programming language but is not in any way guaranteed to ultimately be included in the next or any version of the language. A proposal may be postponed or rejected at any time during any phase of the above process based on feedback from the design team, community, code reviewers, or testing.

meetings/README.md

@@ -2,7 +2,7 @@
 
 C# Language Design Meetings (LDM for short) are meetings by the C# Language Design Team and invited guests to investigate, design and ultimately decide on features to enter the C# language. It is a creative meeting, where active design work happens, not just a decision body. 
 
-Every C# language design meeting is represented by a meeting notes file in this folder.
+Each C# language design meeting is represented by a meeting notes file in this folder.
 
 ## Purpose of the meetings notes
 
@@ -16,18 +16,19 @@ All have proven extremely useful over time.
 
 ## Life cycle of meeting notes
 
-- If upcoming design meetings have a specific agenda, there may be a meeting notes file with that agenda even before the meeting happens
-- After the meeting notes will be saved directly here. 
-- Usually they will be raw notes in need of subsequent cleaning up. If that's the case, they will be clearly marked as such, and a work item will track the task of cleaning up the notes.
-- When the notes are finalized, a notification is sent to the mailing list. Discussion can happen there.
-- If the notes impact current proposals, work items will track updating those proposals.
-- When updated, the proposals link back to the meeting where the proposal was discussed.
+- If upcoming design meetings have a specific agenda, for instance to suit the schedule of visitors, there may be a meeting notes file with that agenda even before the meeting happens.
+- Otherwise the meeting agendas are determined just-in-time based on urgency, arrival of new information or ideas, challenges found in design and implementation, and so on.
+- After the meeting, notes will be saved directly here. 
+- Usually they will be raw notes in need of subsequent cleaning up. If that's the case, they will be clearly marked as such, and a [Meeting notes](https://github.com/dotnet/csharplang/labels/Meeting%20notes) work item will track the task of cleaning up the notes.
+- When the notes are finalized, a notification is posted as a [discussion issue](https://github.com/dotnet/csharplang/labels/Discussion) to encourage discussion of the decisions made. While quick comments are welcome directly on that issue, it is recommended to open a separate issue for deeper or more topic-specific discussions.
+- If the notes impact current proposals, [proposal](https://github.com/dotnet/csharplang/labels/Proposal) work items will track updating those proposals, assigned to their [champions](https://github.com/dotnet/csharplang/labels/Proposal%20champion).
+- When updated, the proposals link back to the meetings where the proposal was discussed.
 
 ## Style of design notes
 
 The notes serve as the collective voice of the LDM. They cover not just the decisions but the discussion, options and rationale, so that others can follow along in the discussion and provide input to it, and so that we don't forget them for later.
 
-However, *the notes are not minutes*! They *never* state who said what in the meeting. They will occasionally mention people by name if they are visiting, provided input, should be collaborated with, etc. But the notes aim to represent the shared thinking of the room. If there's disagreement, they will report that, but they won't say who wants what.
+However, *the notes are not minutes*! They *never* state who said what in the meeting. They will occasionally mention people by name if they are visiting, provided input, should be collaborated with, etc. But the notes aim to represent the shared thinking of the room. If there's disagreement, they will report that, but they won't focus on who wants what.
 
 This approach is intended to reinforce that the LDMs are a safe space, and a collaborative, creative effort. It is not a negotiation between representatives of different interests. It is not a voting body, and it is not a venue for posturing. Everybody cooperates towards the same end: creating the best language for today's and tomorrow's C# developers.
 

proposals/README.md

@@ -1,6 +1,6 @@
 # C# Language Proposals
 
-Language proposals are living documents describing the current thinking about a give language feature.
+Language proposals are living documents describing the current thinking about a given language feature.
 
 Proposals can be either *active*, *inactive*, *rejected* or *done*. *Active* proposals are stored directly in the proposals folder, *inactive* and *rejected* proposals are stored in the [inactive](proposals/inactive) and [rejected](proposals/rejected) subfolders, and *done* proposals are archived in a folder corresponding to the language version they are part of.
 
@@ -8,14 +8,23 @@ Proposals can be either *active*, *inactive*, *rejected* or *done*. *Active* pro
 
 A proposal starts its life when the language design team decides that it might make a good addition to the language some day. Typically it will start out being *active*, but if we want to capture an idea without wanting to work on it right now, a proposal can also start out in the *inactive* subfolder. Proposals may even start out directly in the *rejected* state, if we want to make a record of something we don't intend to do. For instance, if a popular and recurring request is not possible to implement, we can capture that as a rejected proposal.
 
-The proposal may start out as an idea on the mailing list, or it may come from discussions in the LDM, or arrive from many other fronts. The main thing is that the design team feels that it should be done, and that there's someone who is willing to write it up.
+The proposal may start out as an idea in a [discussion issue](https://github.com/dotnet/csharplang/labels/Discussion), or it may come from discussions in the Language Design Meeting, or arrive from many other fronts. The main thing is that the design team feels that it should be done, and that there's someone who is willing to write it up. Typically a member of the Language Design Team will assign themselves as a champion for the feature, tracked by a [Champion issue](https://github.com/dotnet/csharplang/labels/Proposal%20champion). The champion is responsible for moving the proposal through the design process.
 
-A proposal is *active* if it is moving forward through design and implementation towards an upcoming release. Once it is completely *done*, i.e. an implementation has been merged into a release and the feature has been specified, it is moved into a subdirectory corresponding to its release.
+A proposal is *active* if it is moving forward through design and implementation toward an upcoming release. Once it is completely *done*, i.e. an implementation has been merged into a release and the feature has been specified, it is moved into a subdirectory corresponding to its release.
 
-If a feature turns out not to be likely to make it into the language at all, e.g. because it proves unfeasible, does not seem to add enough value or just isn't right for the language, it will be *rejected*, and moved to the corresponding subfolder. If a feature has reasonable promise but is not currently being prioritized to work on, it is *inactive* and will be moved to the corresponding subfolder. It is perfectly fine for work to happen on inactive or rejected proposals, and for them to be resurrected later. The categories are there to reflect current design intent.
+If a feature turns out not to be likely to make it into the language at all, e.g. because it proves unfeasible, does not seem to add enough value or just isn't right for the language, it will be [rejected](proposals/rejected). If a feature has reasonable promise but is not currently being prioritized to work on, it may be declared [inactive](proposals/inactive) to avoid cluttering the main folder. It is perfectly fine for work to happen on inactive or rejected proposals, and for them to be resurrected later. The categories are there to reflect current design intent.
+
+## Nature of a proposal
+
+A proposal should follow the [proposal template](proposal-template.md). A good proposal should:
+
+- Fit with the general spirit and aesthetic of the language.
+- Not introduce subtly alternate syntax for existing features.
+- Add a lot of value for a clear set of users.
+- Not add significantly to the complexity of the language, especially for new users.  
 
 ## Discussion of proposals
 
-Feedback and discussion happens on the C# design mailing list. When a new proposal is added, it should be announced on the mailing list.
+Feedback and discussion happens in [discussion issues](https://github.com/dotnet/csharplang/labels/Discussion). When a new proposal is added to the proposals folder, it should be announced in a discussion issue by the champion or proposal author. 
 
  

spec/README.md

@@ -1,5 +1,6 @@
 C# Language Specification
 ===========================
+
 __Version 6__
 
 This is an unofficial draft, posted here for convenience. When we submit a C# 6.0 spec proposal to ECMA (who is currently finalizing the C# 5.0 Standard), it will be shared here.