Add API Review Process Documentation#53396
Conversation
We're currently working on making a more formal API review process for Roslyn. This PR adds documentation to the repo on how that process works, and the general expectations for how the process should work. Much of this documentation is copied from dotnet/runtime, and modified to fit the repo. Still to be done: * [ ] Get a board on apireviews.net/backlog (cc @terrajobst). * [ ] List areas and owners for the IDE layers (cc @jasonmalinowski and @JoeRobich). * [ ] Set up the email aliases and meeting schedules. * [ ] Add examples of a good API request (this may come later). * [ ] Broad messaging to the roslyn team.
|
@jaredpar @jinujoseph @vatsalyaagrawal, please take a look at the process documentation and let me know if you think it's comprehensive enough, or any questions you have after. My intent is that anyone should be able to read this and have a good idea of what the process is. |
|
Also our community ambassadors, @jnm2 @svick @alrz @YairHalberstadt @Youssef1313, please take a look at this process and let me know your thoughts/things you're confused by. What we'd generally be asking from you as part of this process is tagging the appropriate owner when issues are filed, and potentially pinging us on older issues that need attention. |
|
What should the process be for someone who wants an API to be added but isn't yet clear on the exact shape it would take? |
I think it's almost always easy for issue writer to at least have a basic suggested API shape, which later can be changed during review. |
Co-authored-by: Youssef Victor <youssefvictor00@gmail.com> Co-authored-by: Joseph Musser <me@jnm2.com>
Co-authored-by: Joseph Musser <me@jnm2.com>
I talked a bit about my thoughts here, but ultimately I think we do need at least a sketch. |
Add IDE areas and owners to areas list
Co-authored-by: Youssef Victor <youssefvictor00@gmail.com>
|
@dotnet/roslyn-api-owners for review. |
We're currently working on making a more formal API review process for Roslyn. This PR adds documentation to the repo on how that process works, and the general expectations for how the process should work. Much of this documentation is copied from dotnet/runtime, and modified to fit the repo. Still to be done: