Merge pull request #2 from scottdorman/master

Consitency updates between C# and VB repos.

README.md

@@ -1,13 +1,19 @@
+# Visual Basic .NET Language Design
+
+Welcome to the official repo for Visual Basic .NET language design.
+
 * 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](http://lists.dot.net/pipermail/vblang/).
 * Archives of notes from design meetings, etc., can be found in the [notes folder](notes).
 
-# Design Process
+## Design Process
+
+Visual Basic .NET is designed by the Visual Basic .NET Language Design Team (LDT).
 
 1. To submit, support, and discuss ideas please subscribe to the [language design mailing list](https://lists.dot.net/mailman/listinfo/vblang).
 
-2. Ideas deemed cool by the language design team should be turned into a more fleshed out proposal based on the [proposal template](proposals/proposal-template.md). A good idea should:
+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.
@@ -26,4 +32,12 @@
 
 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. [VB 15.1 proposals](proposals/adopted/vb15.1)). Rejected proposals are archived under the [rejected folder](proposals/rejected).
 
+## 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 Visual Basic .NET versions are made, including which proposals do work on, how to evolve the proposals, and whether and when to adopt them.
+
+## Implementation
+
+The reference implementation of the Visual Basic .NET 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 Visual Basic .NET 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.

proposals/README.md

@@ -1,3 +1,21 @@
-_Active proposals go in this folder_.
+# VB Language Proposals
 
-**PLEASE USE THE [PROPOSAL TEMPLATE](proposal-template.md).**
+Language proposals are living documents describing the current thinking about a give 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.
+
+## Lifetime of a proposal
+
+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.
+
+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.
+
+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.
+
+## Discussion of proposals
+
+Feedback and discussion happens on the VB design mailing list. When a new proposal is added, it should be announced on the mailing list.
+
+