XAML Standard proposals are filed as issues serving as living documents describing the current thinking about a XAML feature/API.
Proposals start their life as an issue:proposal. Through its lifetime proposals can be either accepted, rejected or inactive. Accepted proposals will be tagged with a specific milestone to indicate which version of the Standard will surface the feature/API.
If we want to capture an idea without wanting to work on it right now, a proposal can start out as inactive. 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.
A proposal is considered active if it is moving forward through design. Once it is completely done, i.e. the feature has been completely specified, it will be moved into a subdirectory corresponding to its version.
If a proposal turns out not to be likely to make it into the Standard at all, e.g. because it proves unfeasible, does not seem to add enough value or just isn't right for the Standard, it will be rejected. If a proposal has reasonable promise but is not currently being prioritized to specify, it may be declared inactive. It is perfectly fine for conversation to happen on inactive or rejected proposals, and for them to be resurrected later. The categories are there to reflect current design intent.
A proposal should follow the principles of XAML Standard. A good proposal should:
- Fit with the general spirit and aesthetic of the XAML Standard.
- 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 XAML Standard, especially for new users.
Feedback and discussion happens in issues.