From 9161eb8b4861665d668911af501d4c25252ca1a3 Mon Sep 17 00:00:00 2001 From: Fredric Silberberg Date: Thu, 13 May 2021 11:37:56 -0700 Subject: [PATCH 1/9] Add API Review Process Documentation 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. --- .github/ISSUE_TEMPLATE/api-suggestion.md | 54 ++++++++++++++++++++++++ README.md | 1 + docs/area-owners.md | 14 ++++++ docs/contributing/API Review Process.md | 48 +++++++++++++++++++++ 4 files changed, 117 insertions(+) create mode 100644 .github/ISSUE_TEMPLATE/api-suggestion.md create mode 100644 docs/area-owners.md create mode 100644 docs/contributing/API Review Process.md diff --git a/.github/ISSUE_TEMPLATE/api-suggestion.md b/.github/ISSUE_TEMPLATE/api-suggestion.md new file mode 100644 index 0000000000000..d9690baa45e5a --- /dev/null +++ b/.github/ISSUE_TEMPLATE/api-suggestion.md @@ -0,0 +1,54 @@ +--- +name: API proposal +about: Propose a change to the public API surface +title: '' +labels: [Feature Request, Concept-API] +assignees: '' + +--- + +## Background and Motivation + + + +## Proposed API + + + +## Usage Examples + + + +## Alternative Designs + + + +## Risks + + diff --git a/README.md b/README.md index 4c9cfcf9a8a02..248a13804b4e5 100644 --- a/README.md +++ b/README.md @@ -26,6 +26,7 @@ If you are interested in fixing issues and contributing directly to the code bas - [Submitting pull requests](https://github.com/dotnet/roslyn/blob/main/CONTRIBUTING.md) - Finding a bug to fix in the [IDE](https://aka.ms/roslyn-ide-bugs-help-wanted) or [Compiler](https://aka.ms/roslyn-compiler-bugs-help-wanted) - Finding a feature to implement in the [IDE](https://aka.ms/roslyn-ide-feature-help-wanted) or [Compiler](https://aka.ms/roslyn-compiler-feature-help-wanted) +- Roslyn API suggestions should go through the [API review process]() ### Community diff --git a/docs/area-owners.md b/docs/area-owners.md new file mode 100644 index 0000000000000..b37471c49ea55 --- /dev/null +++ b/docs/area-owners.md @@ -0,0 +1,14 @@ +# Pull Requests Tagging + +If you need to tag folks on an issue or PR, you will generally want to tag the owners (not the lead) for [area](#areas) to which the change or issue is closest to. + +# Areas + +| Area | Lead | Owners | +|--------------------|---------|------------------------| +|api-Syntax |@jaredpar|@CyrusNajmabadi @333fred| +|api-Symbols |@jaredpar|@AlekseyTs | +|api-SemanticModel |@jaredpar|@AlekseyTs @333fred | +|api-IOperation |@jaredpar|@333fred | +|api-SourceGenerators|@jaredpar|@chsienki | +|api-Analyzers |@jaredpar|@mavasani @333fred | diff --git a/docs/contributing/API Review Process.md b/docs/contributing/API Review Process.md new file mode 100644 index 0000000000000..a3611626780ea --- /dev/null +++ b/docs/contributing/API Review Process.md @@ -0,0 +1,48 @@ +# API Review Process + +.NET has a long standing history of taking API usability extremely seriously. Thus, we generally review every single API that is added to the product. This page discusses how we conduct design reviews for the Roslyn components. + +## Which APIs should be reviewed? + +The rule of thumb is that we (**dotnet/roslyn**) review every public API that is being added to this repository in the CodeAnalysis (compiler), Workspaces, Features, and EditorFeatures libraries. APIs in the LanguageServices dlls are not usually reviewed as they are not intended for general consumption; they are for use in Visual Studio, and we don't have a compat bar for these APIs. + +## Steps + +1. **Requester files an issue**. The issue description should contain a speclet that represents a sketch of the new APIs, including samples on how the APIs are being used. The goal isn't to get a complete API list, but a good handle on how the new APIs would roughly look like and in what scenarios they are being used. Please use [this template](https://github.com/dotnet/roslyn/issues/new?template=api-suggestion.md). The issue should have the labels `Feature Request` and `Concept-API`. + +2. **We assign an owner**. We'll assign a dedicated owner from our side that sponsors the issue. This is usually [the area owner](../area-owners.md#areas) for which the API proposal or design change request was filed for. + +3. **Discussion**. The goal of the discussion is to help the assignee to make a decision whether we want to pursue the proposal or not. In this phase, the goal isn't necessarily to perform an in-depth review; rather, we want to make sure that the proposal is actionable, i.e. has a concrete design, a sketch of the APIs and some code samples that show how it should be used. If changes are necessary, the owner will set the label `api-needs-work`. To make the changes, the requester should edit the top-most issue description. This allows folks joining later to understand the most recent proposal. To avoid confusion, the requester can maintain a tiny change log, like a bolded "Updates:" followed by a bullet point list of the updates that were being made. When you the feedback is addressed, the requester should notify the owner to re-review the changes. + +4. **Owner makes decision**. When the owner believes enough information is available to make a decision, they will update the issue accordingly: + + * **Mark for review**. If the owner believes the proposal is actionable, they will label the issue with `api-ready-for-review`. + * **Close as not actionable**. In case the issue didn't get enough traction to be distilled into a concrete proposal, the owner will close the issue. + * **Close as won't fix as proposed**. Sometimes, the issue that is raised is a good one but the owner thinks the concrete proposal is not the right way to tackle the problem. In most cases, the owner will try to steer the discussion in a direction that results in a design that we believe is appropriate. However, for some proposals the problem is at the heart of the design which can't easily be changed without starting a new proposal. In those cases, the owner will close the issue and explain the issue the design has. + * **Close as won't fix**. Similarly, if proposal is taking the product in a direction we simply don't want to go, the issue might also get closed. In that case, the problem isn't the proposed design but in the issue itself. + +5. **API gets reviewed**. The group conducting the review is called *RAR*, which stands for *roslyn api reviewers*. In the review, we'll take notes and provide feedback. After the review, we'll publish the notes in the [API Review repository](https://github.com/dotnet/apireviews) and at the end of the relevant issue. Multiple outcomes are possible: + + * **Approved**. In this case the label `api-ready-for-review` is replaced + with `api-approved`. + * **Needs work**. In case we believe the proposal isn't ready yet, we'll + replace the label `api-ready-for-review` with `api-needs-work`. + * **Rejected**. In case we believe the proposal isn't a direction we want to go after, we simply write a comment and close the issue. + +## Review schedule + + There are three methods to get an API review: + +* **Get into the backlog**. Generally speaking, filing an issue in `dotnet/roslyn` and applying the label `api-ready-for-review` on it will make your issue show up during API reviews. The downside is that we generally walk the backlog oldest-newest, so your issue might not be looked at for a while. Progress of issues can be tracked via https://apireview.net/backlog/roslyn (PROTOTYPE: make this link actually work). +* **Fast track**. If you need to bypass the backlog apply both `api-ready-for-review` and `blocking`. All blocking issues are looked at before we walk the backlog. +* **Dedicated review**. This only applies to area owners. If an issue you are the area owner for needs an hour or longer, send an email to roslynapiowners and we book dedicated time. We also book dedicated time for language feature APIs: any APIs added as part of a new language feature need to have a dedicated review session. Rule of thumb: if the API proposal has more than a dozen APIs, the APIs have complex policy, or the APIs are part of a feature branch, then you need 60 min or more. When in doubt, send mail to roslynapiowners. + +The API review board currently meets biweekly. + +## Pull requests + +Pull requests against **dotnet/roslyn** shouldn't be submitted before getting approval. Also, we don't want to get work in progress (WIP) PR's. The reason being that we want to reduce the number pending PRs so that we can focus on the work the community expects we take action on. + +If you want to collaborate with other people on the design, feel free to perform the work in a branch in your own fork. If you want to track your TODOs in the description of a PR, you can always submit a PR against your own fork. Also, feel free to advertise your PR by linking it from the issue you filed against **dotnet/roslyn** in the first step above. + +For **dotnet/roslyn** team members, PRs are allowed to be submitted and merged before a full API review session, but you should have sign-off from the area owner, and the API is expected to be covered in a formal review session before being shipped. From 50d7bba43b69dcbe25dea4be8e9472b53af7f890 Mon Sep 17 00:00:00 2001 From: Fred Silberberg Date: Tue, 18 May 2021 16:18:10 -0700 Subject: [PATCH 2/9] Apply suggestions from code review Co-authored-by: Youssef Victor Co-authored-by: Joseph Musser --- docs/area-owners.md | 2 +- docs/contributing/API Review Process.md | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/area-owners.md b/docs/area-owners.md index b37471c49ea55..fc460929b0e9c 100644 --- a/docs/area-owners.md +++ b/docs/area-owners.md @@ -2,7 +2,7 @@ If you need to tag folks on an issue or PR, you will generally want to tag the owners (not the lead) for [area](#areas) to which the change or issue is closest to. -# Areas +## Areas | Area | Lead | Owners | |--------------------|---------|------------------------| diff --git a/docs/contributing/API Review Process.md b/docs/contributing/API Review Process.md index a3611626780ea..9c580209b4943 100644 --- a/docs/contributing/API Review Process.md +++ b/docs/contributing/API Review Process.md @@ -1,6 +1,6 @@ # API Review Process -.NET has a long standing history of taking API usability extremely seriously. Thus, we generally review every single API that is added to the product. This page discusses how we conduct design reviews for the Roslyn components. +.NET has a long-standing history of taking API usability extremely seriously. Thus, we generally review every single API that is added to the product. This page discusses how we conduct design reviews for the Roslyn components. ## Which APIs should be reviewed? @@ -10,9 +10,9 @@ The rule of thumb is that we (**dotnet/roslyn**) review every public API that is 1. **Requester files an issue**. The issue description should contain a speclet that represents a sketch of the new APIs, including samples on how the APIs are being used. The goal isn't to get a complete API list, but a good handle on how the new APIs would roughly look like and in what scenarios they are being used. Please use [this template](https://github.com/dotnet/roslyn/issues/new?template=api-suggestion.md). The issue should have the labels `Feature Request` and `Concept-API`. -2. **We assign an owner**. We'll assign a dedicated owner from our side that sponsors the issue. This is usually [the area owner](../area-owners.md#areas) for which the API proposal or design change request was filed for. +2. **We assign an owner**. We'll assign a dedicated owner from our side that sponsors the issue. This is usually [the area owner](../area-owners.md#areas) for which the API proposal or design change request was filed. -3. **Discussion**. The goal of the discussion is to help the assignee to make a decision whether we want to pursue the proposal or not. In this phase, the goal isn't necessarily to perform an in-depth review; rather, we want to make sure that the proposal is actionable, i.e. has a concrete design, a sketch of the APIs and some code samples that show how it should be used. If changes are necessary, the owner will set the label `api-needs-work`. To make the changes, the requester should edit the top-most issue description. This allows folks joining later to understand the most recent proposal. To avoid confusion, the requester can maintain a tiny change log, like a bolded "Updates:" followed by a bullet point list of the updates that were being made. When you the feedback is addressed, the requester should notify the owner to re-review the changes. +3. **Discussion**. The goal of the discussion is to help the assignee to decide whether we want to pursue the proposal or not. In this phase, the goal isn't necessarily to perform an in-depth review; rather, we want to make sure that the proposal is actionable, i.e. has a concrete design, a sketch of the APIs and some code samples that show how it should be used. If changes are necessary, the owner will set the label `api-needs-work`. To make the changes, the requester should edit the top-most issue description. This allows folks joining later to understand the most recent proposal. To avoid confusion, the requester can maintain a tiny change log, like a bolded "Updates:" followed by a bullet point list of the updates that were being made. When you the feedback is addressed, the requester should notify the owner to re-review the changes. 4. **Owner makes decision**. When the owner believes enough information is available to make a decision, they will update the issue accordingly: @@ -41,7 +41,7 @@ The API review board currently meets biweekly. ## Pull requests -Pull requests against **dotnet/roslyn** shouldn't be submitted before getting approval. Also, we don't want to get work in progress (WIP) PR's. The reason being that we want to reduce the number pending PRs so that we can focus on the work the community expects we take action on. +Pull requests against **dotnet/roslyn** that adds new public API shouldn't be submitted before getting approval. Also, we don't want to get work in progress (WIP) PR's. The reason being that we want to reduce the number pending PRs so that we can focus on the work the community expects we take action on. If you want to collaborate with other people on the design, feel free to perform the work in a branch in your own fork. If you want to track your TODOs in the description of a PR, you can always submit a PR against your own fork. Also, feel free to advertise your PR by linking it from the issue you filed against **dotnet/roslyn** in the first step above. From a46bf07a3e888979a309f80bdfd0df7c4e179af6 Mon Sep 17 00:00:00 2001 From: Fredric Silberberg Date: Tue, 18 May 2021 16:44:51 -0700 Subject: [PATCH 3/9] Further updates. --- .github/ISSUE_TEMPLATE/api-suggestion.md | 6 ++++-- docs/contributing/API Review Process.md | 12 ++++++------ 2 files changed, 10 insertions(+), 8 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/api-suggestion.md b/.github/ISSUE_TEMPLATE/api-suggestion.md index d9690baa45e5a..ae2f1f2d5b1d4 100644 --- a/.github/ISSUE_TEMPLATE/api-suggestion.md +++ b/.github/ISSUE_TEMPLATE/api-suggestion.md @@ -10,14 +10,14 @@ assignees: '' ## Background and Motivation ## Proposed API ## Usage Examples diff --git a/docs/contributing/API Review Process.md b/docs/contributing/API Review Process.md index 9c580209b4943..409f63f13987f 100644 --- a/docs/contributing/API Review Process.md +++ b/docs/contributing/API Review Process.md @@ -8,7 +8,7 @@ The rule of thumb is that we (**dotnet/roslyn**) review every public API that is ## Steps -1. **Requester files an issue**. The issue description should contain a speclet that represents a sketch of the new APIs, including samples on how the APIs are being used. The goal isn't to get a complete API list, but a good handle on how the new APIs would roughly look like and in what scenarios they are being used. Please use [this template](https://github.com/dotnet/roslyn/issues/new?template=api-suggestion.md). The issue should have the labels `Feature Request` and `Concept-API`. +1. **Requester files an issue**. The issue description should contain a speclet that represents a sketch of the new APIs, including samples on how the APIs are being used. The goal isn't to get a complete API list, but a good handle on how the new APIs would roughly look like and in what scenarios they are being used. Please use [this template](https://github.com/dotnet/roslyn/issues/new?template=api-suggestion.md). The issue should have the labels `Feature Request` and `Concept-API`. [Here](https://github.com/dotnet/roslyn/issues/53410) is a good example of a strong API proposal. 2. **We assign an owner**. We'll assign a dedicated owner from our side that sponsors the issue. This is usually [the area owner](../area-owners.md#areas) for which the API proposal or design change request was filed. @@ -21,21 +21,21 @@ The rule of thumb is that we (**dotnet/roslyn**) review every public API that is * **Close as won't fix as proposed**. Sometimes, the issue that is raised is a good one but the owner thinks the concrete proposal is not the right way to tackle the problem. In most cases, the owner will try to steer the discussion in a direction that results in a design that we believe is appropriate. However, for some proposals the problem is at the heart of the design which can't easily be changed without starting a new proposal. In those cases, the owner will close the issue and explain the issue the design has. * **Close as won't fix**. Similarly, if proposal is taking the product in a direction we simply don't want to go, the issue might also get closed. In that case, the problem isn't the proposed design but in the issue itself. -5. **API gets reviewed**. The group conducting the review is called *RAR*, which stands for *roslyn api reviewers*. In the review, we'll take notes and provide feedback. After the review, we'll publish the notes in the [API Review repository](https://github.com/dotnet/apireviews) and at the end of the relevant issue. Multiple outcomes are possible: +5. **API gets reviewed**. The group conducting the review is called *RAR*, which stands for *Roslyn API Reviewers*. In the review, we'll take notes and provide feedback. After the review, we'll publish the notes in the [API Review repository](https://github.com/dotnet/apireviews) and at the end of the relevant issue. Multiple outcomes are possible: * **Approved**. In this case the label `api-ready-for-review` is replaced with `api-approved`. * **Needs work**. In case we believe the proposal isn't ready yet, we'll replace the label `api-ready-for-review` with `api-needs-work`. - * **Rejected**. In case we believe the proposal isn't a direction we want to go after, we simply write a comment and close the issue. + * **Rejected**. In case we believe the proposal isn't a direction we want pursue, we simply write a comment and close the issue. ## Review schedule - There are three methods to get an API review: + There are three methods to get an API review (this section applies to API area owners, but is included for transparency into the process): * **Get into the backlog**. Generally speaking, filing an issue in `dotnet/roslyn` and applying the label `api-ready-for-review` on it will make your issue show up during API reviews. The downside is that we generally walk the backlog oldest-newest, so your issue might not be looked at for a while. Progress of issues can be tracked via https://apireview.net/backlog/roslyn (PROTOTYPE: make this link actually work). * **Fast track**. If you need to bypass the backlog apply both `api-ready-for-review` and `blocking`. All blocking issues are looked at before we walk the backlog. -* **Dedicated review**. This only applies to area owners. If an issue you are the area owner for needs an hour or longer, send an email to roslynapiowners and we book dedicated time. We also book dedicated time for language feature APIs: any APIs added as part of a new language feature need to have a dedicated review session. Rule of thumb: if the API proposal has more than a dozen APIs, the APIs have complex policy, or the APIs are part of a feature branch, then you need 60 min or more. When in doubt, send mail to roslynapiowners. +* **Dedicated review**. If an issue you are the area owner for needs an hour or longer, send an email to roslynapiowners and we book dedicated time. We also book dedicated time for language feature APIs: any APIs added as part of a new language feature need to have a dedicated review session. Rule of thumb: if the API proposal has more than a dozen APIs, the APIs have complex policy, or the APIs are part of a feature branch, then you need 60 min or more. When in doubt, send mail to roslynapiowners. The API review board currently meets biweekly. @@ -45,4 +45,4 @@ Pull requests against **dotnet/roslyn** that adds new public API shouldn't be su If you want to collaborate with other people on the design, feel free to perform the work in a branch in your own fork. If you want to track your TODOs in the description of a PR, you can always submit a PR against your own fork. Also, feel free to advertise your PR by linking it from the issue you filed against **dotnet/roslyn** in the first step above. -For **dotnet/roslyn** team members, PRs are allowed to be submitted and merged before a full API review session, but you should have sign-off from the area owner, and the API is expected to be covered in a formal review session before being shipped. +For **dotnet/roslyn** team members, PRs are allowed to be submitted and merged before a full API review session, but you should have sign-off from the area owner, and the API is expected to be covered in a formal review session before being shipped. For such issues, please work with the API area owner to make sure that the issue is marked blocking appropriately so it will be covered in short order. From 4b9e488b8207b129981a2f0fac02a593ba6f9993 Mon Sep 17 00:00:00 2001 From: Fredric Silberberg Date: Tue, 18 May 2021 17:00:59 -0700 Subject: [PATCH 4/9] More updates, add section to the CODEOWNERS file. --- .github/CODEOWNERS | 4 ++++ .github/ISSUE_TEMPLATE/api-suggestion.md | 10 +++++----- docs/contributing/API Review Process.md | 8 +++----- 3 files changed, 12 insertions(+), 10 deletions(-) diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS index 90960c656649f..518dc286e1e3f 100644 --- a/.github/CODEOWNERS +++ b/.github/CODEOWNERS @@ -27,3 +27,7 @@ src/VisualStudio/ @dotnet/roslyn-ide src/VisualStudio/LiveShare @dotnet/roslyn-ide @daytonellwanger @srivatsn @aletsdelarosa src/Workspaces/ @dotnet/roslyn-ide +src/Compilers/**/PublicAPI.Unshipped.txt @dotnet/roslyn-api-owners +src/Workspaces/**/PublicAPI.Unshipped.txt @dotnet/roslyn-api-owners +src/Features/**/PublicAPI.Unshipped.txt @dotnet/roslyn-api-owners +src/EditorFeatures/**/PublicAPI.Unshipped.txt @dotnet/roslyn-api-owners diff --git a/.github/ISSUE_TEMPLATE/api-suggestion.md b/.github/ISSUE_TEMPLATE/api-suggestion.md index ae2f1f2d5b1d4..5f6beb1283322 100644 --- a/.github/ISSUE_TEMPLATE/api-suggestion.md +++ b/.github/ISSUE_TEMPLATE/api-suggestion.md @@ -17,7 +17,11 @@ First, please describe the purpose and value of the new API here. ## Proposed API + ```diff namespace Microsoft.CodeAnalysis.Operations { @@ -26,10 +30,6 @@ namespace Microsoft.CodeAnalysis.Operations + public bool IsExhaustive { get; } } ``` -You may find the [Framework Design Guidelines](https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/framework-design-guidelines-digest.md) helpful. - -https://github.com/dotnet/roslyn/issues/53410 is a good example issue. ---> ## Usage Examples diff --git a/docs/contributing/API Review Process.md b/docs/contributing/API Review Process.md index 409f63f13987f..665116c3d890d 100644 --- a/docs/contributing/API Review Process.md +++ b/docs/contributing/API Review Process.md @@ -23,11 +23,9 @@ The rule of thumb is that we (**dotnet/roslyn**) review every public API that is 5. **API gets reviewed**. The group conducting the review is called *RAR*, which stands for *Roslyn API Reviewers*. In the review, we'll take notes and provide feedback. After the review, we'll publish the notes in the [API Review repository](https://github.com/dotnet/apireviews) and at the end of the relevant issue. Multiple outcomes are possible: - * **Approved**. In this case the label `api-ready-for-review` is replaced - with `api-approved`. - * **Needs work**. In case we believe the proposal isn't ready yet, we'll - replace the label `api-ready-for-review` with `api-needs-work`. - * **Rejected**. In case we believe the proposal isn't a direction we want pursue, we simply write a comment and close the issue. + * **Approved**. In this case the label `api-ready-for-review` is replaced with `api-approved`. + * **Needs work**. If we believe the proposal isn't ready yet, we'll replace the label `api-ready-for-review` with `api-needs-work`. + * **Rejected**. If we believe the proposal isn't a direction we want to pursue, we'll simply write a comment and close the issue. ## Review schedule From 73b7861d1f98bc954b9885a7cb5037df9361611d Mon Sep 17 00:00:00 2001 From: Fred Silberberg Date: Tue, 18 May 2021 17:01:54 -0700 Subject: [PATCH 5/9] Apply suggestions from code review Co-authored-by: Joseph Musser --- docs/contributing/API Review Process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/contributing/API Review Process.md b/docs/contributing/API Review Process.md index 665116c3d890d..545036e11aae1 100644 --- a/docs/contributing/API Review Process.md +++ b/docs/contributing/API Review Process.md @@ -39,7 +39,7 @@ The API review board currently meets biweekly. ## Pull requests -Pull requests against **dotnet/roslyn** that adds new public API shouldn't be submitted before getting approval. Also, we don't want to get work in progress (WIP) PR's. The reason being that we want to reduce the number pending PRs so that we can focus on the work the community expects we take action on. +Pull requests against **dotnet/roslyn** that add new public API shouldn't be submitted before getting approval. Also, we don't want to get work in progress (WIP) PR's. The reason being that we want to reduce the number pending PRs so that we can focus on the work the community expects we take action on. If you want to collaborate with other people on the design, feel free to perform the work in a branch in your own fork. If you want to track your TODOs in the description of a PR, you can always submit a PR against your own fork. Also, feel free to advertise your PR by linking it from the issue you filed against **dotnet/roslyn** in the first step above. From 9e4327cbe6d2497d053aa78d57c62e73801a19df Mon Sep 17 00:00:00 2001 From: Joey Robichaud Date: Wed, 19 May 2021 16:20:11 -0700 Subject: [PATCH 6/9] Add IDE areas and owners to areas list --- docs/area-owners.md | 30 ++++++++++++++++++++++-------- 1 file changed, 22 insertions(+), 8 deletions(-) diff --git a/docs/area-owners.md b/docs/area-owners.md index fc460929b0e9c..76c05e21581a2 100644 --- a/docs/area-owners.md +++ b/docs/area-owners.md @@ -4,11 +4,25 @@ If you need to tag folks on an issue or PR, you will generally want to tag the o ## Areas -| Area | Lead | Owners | -|--------------------|---------|------------------------| -|api-Syntax |@jaredpar|@CyrusNajmabadi @333fred| -|api-Symbols |@jaredpar|@AlekseyTs | -|api-SemanticModel |@jaredpar|@AlekseyTs @333fred | -|api-IOperation |@jaredpar|@333fred | -|api-SourceGenerators|@jaredpar|@chsienki | -|api-Analyzers |@jaredpar|@mavasani @333fred | +| Area | Lead | Owners | +|----------------------------|---------|--------------------------------| +|api-Syntax |@jaredpar|@CyrusNajmabadi @333fred | +|api-Symbols |@jaredpar|@AlekseyTs | +|api-SemanticModel |@jaredpar|@AlekseyTs @333fred | +|api-IOperation |@jaredpar|@333fred | +|api-SourceGenerators |@jaredpar|@chsienki | +|api-Analyzers |@jaredpar|@mavasani @333fred | +|api-CodeFixes (Refactoring) |@jinuj |@mavasani @sharwell | +|api-Completion |@jinuj |@genlu @CyrusNajmabadi | +|api-Debugging |@jinuj |@tmat @davidwengier | +|api-EditAndContinue |@jinuj |@tmat @davidwengier | +|api-EmbeddedLanguages |@jinuj |@CyrusNajmabadi @joerobich | +|api-Formatting |@jinuj |@sharwell @joerobich | +|api-LSP |@jinuj |@dibarbet @jasonmalinowski | +|api-MetadataAsSource |@jinuj |@sharwell @jasonmalinowski | +|api-Navigation |@jinuj |@CyrusNajmabadi @dibarbet | +|api-QuickInfo |@jinuj |@sharwell @jasonmalinowski | +|api-SignatureHelp |@jinuj |@sharwell @jasonmalinowski | +|api-Structure (Outlining) |@jinuj |@CyrusNajmabadi @jasonmalinowski| +|api-Tagging (Classification)|@jinuj |@CyrusNajmabadi @joerobich | +|api-Workspace |@jinuj |@jasonmalinowski @tmat | From 4c8563a23652dd9414fb79f77ec73e78645a66db Mon Sep 17 00:00:00 2001 From: Fredric Silberberg Date: Tue, 25 May 2021 13:23:33 -0700 Subject: [PATCH 7/9] Update link --- docs/contributing/API Review Process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/contributing/API Review Process.md b/docs/contributing/API Review Process.md index 545036e11aae1..3e5f851638665 100644 --- a/docs/contributing/API Review Process.md +++ b/docs/contributing/API Review Process.md @@ -31,7 +31,7 @@ The rule of thumb is that we (**dotnet/roslyn**) review every public API that is There are three methods to get an API review (this section applies to API area owners, but is included for transparency into the process): -* **Get into the backlog**. Generally speaking, filing an issue in `dotnet/roslyn` and applying the label `api-ready-for-review` on it will make your issue show up during API reviews. The downside is that we generally walk the backlog oldest-newest, so your issue might not be looked at for a while. Progress of issues can be tracked via https://apireview.net/backlog/roslyn (PROTOTYPE: make this link actually work). +* **Get into the backlog**. Generally speaking, filing an issue in `dotnet/roslyn` and applying the label `api-ready-for-review` on it will make your issue show up during API reviews. The downside is that we generally walk the backlog oldest-newest, so your issue might not be looked at for a while. Progress of issues can be tracked via https://apireview.net/backlog?g=Roslyn. * **Fast track**. If you need to bypass the backlog apply both `api-ready-for-review` and `blocking`. All blocking issues are looked at before we walk the backlog. * **Dedicated review**. If an issue you are the area owner for needs an hour or longer, send an email to roslynapiowners and we book dedicated time. We also book dedicated time for language feature APIs: any APIs added as part of a new language feature need to have a dedicated review session. Rule of thumb: if the API proposal has more than a dozen APIs, the APIs have complex policy, or the APIs are part of a feature branch, then you need 60 min or more. When in doubt, send mail to roslynapiowners. From 7a97d84b5b63084e5e7d7628a3a036cd5876c166 Mon Sep 17 00:00:00 2001 From: Fred Silberberg Date: Tue, 25 May 2021 13:37:34 -0700 Subject: [PATCH 8/9] Use brackets for link. Co-authored-by: Youssef Victor --- docs/contributing/API Review Process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/contributing/API Review Process.md b/docs/contributing/API Review Process.md index 3e5f851638665..99feaaec5afd2 100644 --- a/docs/contributing/API Review Process.md +++ b/docs/contributing/API Review Process.md @@ -31,7 +31,7 @@ The rule of thumb is that we (**dotnet/roslyn**) review every public API that is There are three methods to get an API review (this section applies to API area owners, but is included for transparency into the process): -* **Get into the backlog**. Generally speaking, filing an issue in `dotnet/roslyn` and applying the label `api-ready-for-review` on it will make your issue show up during API reviews. The downside is that we generally walk the backlog oldest-newest, so your issue might not be looked at for a while. Progress of issues can be tracked via https://apireview.net/backlog?g=Roslyn. +* **Get into the backlog**. Generally speaking, filing an issue in `dotnet/roslyn` and applying the label `api-ready-for-review` on it will make your issue show up during API reviews. The downside is that we generally walk the backlog oldest-newest, so your issue might not be looked at for a while. Progress of issues can be tracked via . * **Fast track**. If you need to bypass the backlog apply both `api-ready-for-review` and `blocking`. All blocking issues are looked at before we walk the backlog. * **Dedicated review**. If an issue you are the area owner for needs an hour or longer, send an email to roslynapiowners and we book dedicated time. We also book dedicated time for language feature APIs: any APIs added as part of a new language feature need to have a dedicated review session. Rule of thumb: if the API proposal has more than a dozen APIs, the APIs have complex policy, or the APIs are part of a feature branch, then you need 60 min or more. When in doubt, send mail to roslynapiowners. From f446eb2e385511f4cf4403ba4cb321b05853e39f Mon Sep 17 00:00:00 2001 From: Fred Silberberg Date: Thu, 27 May 2021 10:10:17 -0700 Subject: [PATCH 9/9] Update wording. --- docs/contributing/API Review Process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/contributing/API Review Process.md b/docs/contributing/API Review Process.md index 99feaaec5afd2..43896603d3607 100644 --- a/docs/contributing/API Review Process.md +++ b/docs/contributing/API Review Process.md @@ -35,7 +35,7 @@ The rule of thumb is that we (**dotnet/roslyn**) review every public API that is * **Fast track**. If you need to bypass the backlog apply both `api-ready-for-review` and `blocking`. All blocking issues are looked at before we walk the backlog. * **Dedicated review**. If an issue you are the area owner for needs an hour or longer, send an email to roslynapiowners and we book dedicated time. We also book dedicated time for language feature APIs: any APIs added as part of a new language feature need to have a dedicated review session. Rule of thumb: if the API proposal has more than a dozen APIs, the APIs have complex policy, or the APIs are part of a feature branch, then you need 60 min or more. When in doubt, send mail to roslynapiowners. -The API review board currently meets biweekly. +The API review board currently meets every 2 weeks. ## Pull requests