This repo serves as a discussion board for additions and improvements to Immersive Web standards.

While much of our work to date has been on the WebXR Device API, this repo also holds proposals for features that could end up in other standards.

If your proposal isn't in some way related to Immersive Web technologies like Virtual/Augmented/Mixed Reality then head over to the W3C Community and Business Groups to find an appropriate group. The Web Incubator Community Group (WICG) is also a good general-purpose venue.

TL;DR: Treat other participants with respect or get banned.

This repository is for open discussion of ideas for making the Immersive Web better and we foster an environment where all discussion is respectful. Every person participating in the community group is expected to follow the Code of Conduct.

The Immersive Web groups discussions take place in Proposals Issues and in feature incubation repos.

You can find feature incubation repos by going to the Immersive Web GitHub org and looking for repos tagged with "incubation".

An immersive web feature goes through several steps to move from idea to standard:

• File a Proposals Issue
• Find Consensus for the Idea
• Recruit Feature Advocates
• Create a Feature Repo
• Write an Explainer
• Find Consensus for Feature Details
• Recruit Implementers
• Pitch to a Working Group (may or may not be the Immersive Web WG)
• Working Group incorporates the idea into a standard

Most of the work of landing a feature is social, not technical.

If you're reading this, you probably have ideas about what "should" be in the Immersive Web. Welcome, there are a lot of dreamers in our community!

That said, landing a feature in a standard consists mostly of writing documents, having conversations, and eventually finding consensus for an idea. You'll need to rally support from people who can make prototypes, write documentation, and then as a group you'll work to convince a working group that the feature is important enough to take through the W3C standard.

Great! If the paragraphs above haven't scared you off, you're up for the social work of standardization, and you haven't found related Issues through a search, then file a GitHub Issue in the proposals repo using the Proposals Issue Template.

That Issue will be the place where you host discussion about the feature until one of two things happen:

Best case: You find other people (ideally implementers) who have the time and interest to engage with the feature idea and as a group you find a general agreement about what it is, how it should work, and the rough shape of the API design or other technical artifact.

Common case: People agree that the feature is interesting but you don't gain much momentum and nobody steps up to work on the feature. The issue discussion goes stagnant and a chair may close it. It will be in the archive in case interest is re-animated and someone steps up to be the feature.

A community group chair can help if you get stuck in this step. A big part of their responsibilities is to help people in the CG connect with like-minded members to work through proposals. If you feel that your proposal isn't getting the attention it deserves then reach out! A chair can't do the work for you, but they can help you understand what needs to be done and who else might be interested.

Terrific! You did the hard work of getting enough momentum in the group to figure out what you're making and how it would work. The next step is to recruit one or two people from other organizations who want to join you as feature advocates. This isn't a formal W3C community group role; it simply means that each of you agrees to do the work of nailing down a feature's details and working with the rest of the group to find consensus on its details.

Once two or three people from separate organizations have volunteered to work on the feature then you should reach out to a CG chair and ask that a feature repo be created.

To summarize, here are the criteria we use for feature incubation repos:

• Are there clear goals for the feature, like a specific API or document?
• Have people from more than one organization participated in defining the goals?
• Is the feature narrow enough that work on it has a definite end point?
• Is there at least one (ideally two) feature advocate(s) signed up to do the work?

discussion will continue in the Issues until these criteria are met

One goal of the repo is to work through the specific details of a feature with enough detail that it's clearly possible to implement and it's attractive to the relevant Working Group.

The other (perhaps more important) goal of the repo is to attract the attention of implementers and topic experts and then find consensus for the feature details.

Feature advocates (mentioned in the paragraphs above) are on the hook to do both technical and social work. It can take a lot of effort to gather enough feedback from a wide enough range of people that your feature will work for the entire immersive web.

You start by writing an explainer document that lays out the context for the feature, captures the main discussion points from the proposals Issue, and runs through a few possible shapes that the feature's API or other technical artifacts could take. The goal of this document is to give readers the information they need to decide whether they want to work on the feature.

Again, if you get stuck on this step (either in the writing or in the social aspects) then reach out to a CG chair.

Excellent! You've talked to enough of the community and worked together as feature advocates to nail down pretty much everything that one would need to know in order to implement a feature.

If you've been prototyping the feature during the process of nailing down the design, you're probably in good shape. If not, you'll need to find someone to write code to prove out the design so that you can make the case that the feature is definitely ready to use in production.

Ideally, you'll have prototypes that work on different platforms so it's clear that the feature is not a solution for just one vendor.

During this process you should reach out to a CG chair and start the work of finding or creating a W3C working group that is a good fit for the feature.

At this point, you've reached the end of what the community group can do. Now you have to convince a working group to take on your feature and turn it into a standard. All of the community rallying, document writing, and prototyping comes together to convince the W3C that this feature is important and good to go.

In the previous step (see the question above) you'll have reached out to a CG chair to find or create a working group. The working group will have its own process for taking on new features, so you and a CG chair will work with a WG chair to start that process.