Today we are introducing a wicg/proposals repo, a place for well-formed ideas to start their incubation journey. Plan to use the proposals repo issue tracker for submitting and discussing new proposals much like already happens here on Discourse. WICG Discourse will remain a good home for less well-formed ideas to germinate, for early explorations, and for other discussions. But if you have a well-formed idea, you may skip this forum and start an issue in the proposals repo. Think of this forum and the proposals repo as two potential destinations for new WICG ideas: here we continue to talk about fresh new ideas that are less-well-formed; the proposals repo is for more crystalized proposals. We’re learning as we go, so please pardon any rough edges as we continue to streamline our process. More details below. 
-The WICG co-chairs
A look back
Until now, the WICG used Discourse discussions on this forum for anything that wasn’t an official incubation (i.e., an incubation with its own repo). This forum was host to all discussions, early explorations, suggestions, and proposals for the web platform. The goal was to help establish our community where those who participated in developing web standards and those who didn’t have the time but still wanted to influence/advance the web could mingle and share ideas. In short, bringing together the broadest possible community of interested developers to give and receive feedback. Our goal was largely successful.
As time passed, the developer ecosystem shifted. We now see that GitHub has a larger community of web developer interest than ever before, is the primary host of specification development for major web standards organizations and has great tools and integration for project and issue management. We also see an opportunity to provide more direct guidance on how to start an incubation, by creating a dedicated home for such future incubations to be proposed that is distinct from other ideas, explorations, and discussions about the web platform.
We’re now introducing a proposals repo to meet these changing needs. The proposals repo is hosted in GitHub allowing you to easily extend your existing repo and issue monitoring techniques to keep track of what’s being proposed. Additionally, this gives us a chance to clarify the WICG process for starting new incubations: rather than ask that proposals for new incubations be started here on Discourse (intermingled with all other Discourse conversations), instead well-formed ideas should be filed as issues in the proposals repo, making it clear that these proposal issues intend to begin life as an incubation. Our expectations for evaluation of new proposals remains the same: as soon as sufficient interest is shown in the proposal’s issue thread (notably from potential implementers), the WICG chairs will enable a team of editors to manage the proposal, and those team members can begin work in a new repo or move ownership of an existing GitHub repo to WICG. For more information about the evaluation and incubation process, see the admin repo’s README file.
We continue to recommend that our community participate here in Discourse for less well-formed ideas to germinate, for early explorations, and for other discussions. As these ideas, explorations, and discussions mature, they may form into a proposal which should then be filed as an issue in the proposals repo.
What does a proposal look like?
A proposal outlines a particular problem or challenge on the web and offers a potential concrete solution. Without being too prescriptive, you know you’ve got a proposal when you can articulate a specific way (procedurally, algorithmically, declaratively) that a new or current web technology solves an existing problem or challenge. If the problem is unclear, or the potential solution is too abstract you’re not quite there yet.
For example, this is not a proposal:
“Websites have lots of bugs because they don’t get updated or because browsers change their behavior over time. There should be a universal way for users to report bugs to websites so that they get fixed.”
A proposal might be:
"Websites have lots of bugs because they don’t get updated or because browsers change their behavior over time. One way to solve this is to create an experience in the browser that allows users to record a set of steps that reproduce the problem, and then standardize the format for these replay instructions, and provide an API to allow sites to capture this feedback or an HTTP header to post this feedback back to their site. Below I describe the proposed format and API… "