Propose an RFCs Process

[rylev]

As the windows-rs project has grown, we have moved from a model of shipping code as fast as possible to a community centered collaborative approach. With this transition it becomes useful to add a little bit of process for handling large and complex changes to the project. This PR proposes adding an RFC process that is deliberating modeled very closely on the Rust RFC process. For large and complex changes, this process will hopefully lead to better designs, less churn, and more community buy-in. I look forward to all of your feedback!

[riverar]

Thanks for pinging me on this PR. I had a few nits inline and some more general comments/questions below.

windows and windows-sys crates inherit instability from upstream metadata. There's still a bunch of work to do there, in terms of ensuring the correct shape for various Windows APIs. And when metadata changes are made, those changes trickle down to the crate and incur sometimes significant architectural and/or signature changes.

Some questions:

• How do you envision solidifying the crate designs with the unstable upstream metadata relationship in mind?
• Are you proposing that all those changes would now go through the RFC process? Who's going to review them?
• What does stability look like for windows and windows-sys (and metadata)?
• Are there core features that must be in windows and windows-sys prior to 1.0?
• Does Microsoft have other dedicated people to put on this crate to support stabilization, servicing, and other overhead?

[kennykerr]

How do you envision solidifying the crate designs with the unstable upstream metadata relationship in mind?

This presupposes we can stabilize the upstream metadata, for some definition of stability. We're still trying to figure out how to do that. Suggestions welcome. 😉

Are you proposing that all those changes would now go through the RFC process? Who's going to review them?

This should be for new feature research and development beyond the scope of what I’m working on right now (metadata processing and component authoring), providing a process by which more people can get involved with the project. For example, someone might want to propose a more comprehensive solution for string handling or metadata partitioning.

Naturally, we'll have to see how this plays out and adjust accordingly.

What does stability look like for windows and windows-sys (and metadata)?

The windows and windows-sys crates are about consuming (windows and windows-sys) and producing (only windows) current and future Windows APIs. The windows-sys crate is thus far closer to being stable simply because its less ambitious in its scope. Beyond that, we still need to put some more thought into what exactly we would consider stable for 1.0.

Are there core features that must be in windows and windows-sys prior to 1.0?

The windows crate needs complete authoring support. I don’t have anything significant in mind for the windows-sys crate. Most of the existing issues also need to be resolved for a 1.0 release, so there's still plenty to do.

Does Microsoft have other dedicated people to put on this crate to support stabilization, servicing, and other overhead?

Other than me, no. But hopefully that will change over time. 😊

[rylev]

I think @kennykerr does a good job of answering the specific questions, but I will add one more general point that I tried to make clear in the RFC itself: while the RFC process can help achieve stabilization it is not meant as a stabilization mechanism itself. The RFC process ultimately reduces churn where churn is the introduction of changes that are then reverted, modified, or reintroduced quickly and often thereafter. Reducing churn means reducing the amount of change that comes simply from not taking the time to thoroughly discuss proposed changes, not considering alternatives, and not getting buy-in from stakeholders. How features are then stabilized is a separate question, albeit one that can (and should IMO) be answered through an RFC proposal.

In other words, a lot of the questions brought up here about stability are really good questions that we need to find answers to, but they're orthogonal to an RFC process.

[riverar]

In other words, a lot of the questions brought up here about stability are really good questions that we need to find answers to, but they're orthogonal to an RFC process.

I think the value in reducing churn is diminished if the crate remains unstable (0.x) and cannot be relied upon due to breakage concerns. But I generally agree.