From 1d6b30e937ed16883fbfcd9b71b75f0221af161f Mon Sep 17 00:00:00 2001 From: Martin Hochel Date: Thu, 15 Sep 2022 17:41:53 +0200 Subject: [PATCH 1/4] docs(rfcs): add triage automation rfc --- rfcs/shared/build-system/triage-automation.md | 161 ++++++++++++++++++ 1 file changed, 161 insertions(+) create mode 100644 rfcs/shared/build-system/triage-automation.md diff --git a/rfcs/shared/build-system/triage-automation.md b/rfcs/shared/build-system/triage-automation.md new file mode 100644 index 0000000000000..b0d3b2bf5bf17 --- /dev/null +++ b/rfcs/shared/build-system/triage-automation.md @@ -0,0 +1,161 @@ +# RFC: Triage automation (Shield) + + + +_contributors:_ _@hotell_ + +--- + +## Summary + +We wanna make initial triage-ing issues a fully automated process. + +## Problem statement + +At the moment processing newly created issues is mostly manual work done by 2 people on shield duty. While this was a good start it wont scale as the codebase/team/contributors list grows. Thus we need to introduce automation to establish best possible contributors DX while they need our help. + + + +## Detailed Design or Proposal + + + +After we [introduced new github issues beta](https://github.com/microsoft/fluentui/pull/22337) for reporting issues and feature request, the experience for both contributors and shield devs was significantly improved. A followup that was discussed is to implement further automation by leveraging Github Actions, This document will describe the approach in better detail. + +We would like to automate following steps: + +1. project label assignment +2. package label assignment +3. assign issue to project board/team + +**Pre-requirements:** + +- normalization/unification of labels within monorepo for projects + +_Current state:_ + +- 2 labels for v0 + - https://github.com/microsoft/fluentui/labels?q=northstar +- 2 labels for v9 + - https://github.com/microsoft/fluentui/labels/Fluent%20UI%20react-components%20%28v9%29 + - https://github.com/microsoft/fluentui/labels/Fluent%20UI%20vNext +- per component labels + - same labels mixed for various fluent version https://github.com/microsoft/fluentui/labels/Component%3A%20Dialog + +_Expected state:_ + +- 1 label for v0 +- 1 label for v9 +- label per published package +- "component labels" can stay as are but should be used solely for v8 (internal react package "sub-packages" https://github.com/microsoft/fluentui/labels/Component%3A%20Dialog) + +### 1. project label assignment + +> Note: +> +> - by "project" we mean one of libraries that exist within monorepo (v0,v8,v9,web-components) + +**Workflow:** + +Based on selected project within issue template, we should add appropriate label. + +image + +> NOTE: +> +> - this is already implement via [github action](https://github.com/microsoft/fluentui/pull/24788) + +### 2. package label assignment + +> Note: +> +> - by "package" we mean official package name used to publish to npm registry without `@scope` prefix + +**Workflow:** + +Based on selected project within issue template, additional select should be dynamically generated so contributor can pick proper package. + +example of flow + +Unfortunately **dynamic input controls are not possible with github issues beta** which leaves us with following options how to implement this: + +- use only package names in "Library" picker + - cons + - huge list because we have quite a lot packages + - pros + - only 1 issue/feature template that we need to maintain + - removes need of `1. project label assignment` as labeling would be handled in one step +- creating feature/bug templates per library + - cons + - 2 (feature/bug) x N templates (N is number of libraries in monorepo) + - pros + - clear separation that can be tweaked to particular library needs if needed +- creating completely custom issue form solution (example [vuejs](https://github.com/vuejs/vue/issues/new/choose)) + - cons + - big effort in terms of development and maintenance + - pros + - complete control about issue reporting + - another possible dog food for v9 controls + +**How will we maintain list of packages in issue template:** + +On library creation/removal we will tweak our issue/feature template automatically. + +> Note: +> +> - this can also happen only after created package has been published to npm registry ( post release GH action) + +### 3. assign issue to project board/team + +Based on assigned labels, we can automate assignment of issues based on our source of truth of ownership which is `CODEOWNERS` file. + +**Workflow:** + +```mermaid +graph TD; + I("issue template created")-->L("labels added")-->C("parse codeowners"); + subgraph "parse codeowners" + C-->D("find owner based on package") + end + D-->A("add issue to unified board")-->AA("pick team based on ownership definition"); +``` + +## Pros and Cons + +**Cons:** + +- some amount of maintenance + +**Pros:** + +- improved issues reporting experience +- improved post-triaging experience and prioritization +- no need for: + - human interaction for initial triaging + - manual communication that can "get lost" and can take extra time (time-zone constraints) + - extra number of humans needed on Shield + +## Discarded Solutions + + + +NONE + +## Open Issues + + From 22d3982d96ae7ee3972542530fcb6a58be29cb9d Mon Sep 17 00:00:00 2001 From: Martin Hochel Date: Thu, 15 Sep 2022 18:02:38 +0200 Subject: [PATCH 2/4] fixup! docs(rfcs): add triage automation rfc --- rfcs/shared/build-system/triage-automation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/shared/build-system/triage-automation.md b/rfcs/shared/build-system/triage-automation.md index b0d3b2bf5bf17..37d7f2271d704 100644 --- a/rfcs/shared/build-system/triage-automation.md +++ b/rfcs/shared/build-system/triage-automation.md @@ -92,7 +92,7 @@ Based on selected project within issue template, additional select should be dyn example of flow -Unfortunately **dynamic input controls are not possible with github issues beta** which leaves us with following options how to implement this: +Unfortunately **[dynamic input controls are not possible with github issues beta](https://github.com/community/community/discussions/29067)** which leaves us with following options how to implement this: - use only package names in "Library" picker - cons From 9117d9bd3b4582a016615d6e5c600573015161f5 Mon Sep 17 00:00:00 2001 From: Martin Hochel Date: Thu, 6 Oct 2022 15:45:44 +0200 Subject: [PATCH 3/4] fixup! fixup! docs(rfcs): add triage automation rfc --- rfcs/shared/build-system/triage-automation.md | 107 ++++++++++++++---- 1 file changed, 87 insertions(+), 20 deletions(-) diff --git a/rfcs/shared/build-system/triage-automation.md b/rfcs/shared/build-system/triage-automation.md index 37d7f2271d704..471371e1f87d3 100644 --- a/rfcs/shared/build-system/triage-automation.md +++ b/rfcs/shared/build-system/triage-automation.md @@ -78,13 +78,14 @@ Based on selected project within issue template, we should add appropriate label > NOTE: > -> - this is already implement via [github action](https://github.com/microsoft/fluentui/pull/24788) +> - this is already implement via [github action](https://github.com/microsoft/fluentui/pull/24911) ### 2. package label assignment > Note: > > - by "package" we mean official package name used to publish to npm registry without `@scope` prefix +> - by "Component name" we mean official package name transformed via following `toPascalCase(packageName.replace('@fluentui/react-'))` **Workflow:** @@ -94,25 +95,85 @@ Based on selected project within issue template, additional select should be dyn Unfortunately **[dynamic input controls are not possible with github issues beta](https://github.com/community/community/discussions/29067)** which leaves us with following options how to implement this: -- use only package names in "Library" picker - - cons - - huge list because we have quite a lot packages - - pros - - only 1 issue/feature template that we need to maintain - - removes need of `1. project label assignment` as labeling would be handled in one step -- creating feature/bug templates per library - - cons - - 2 (feature/bug) x N templates (N is number of libraries in monorepo) - - pros - - clear separation that can be tweaked to particular library needs if needed -- creating completely custom issue form solution (example [vuejs](https://github.com/vuejs/vue/issues/new/choose)) - - cons - - big effort in terms of development and maintenance - - pros - - complete control about issue reporting - - another possible dog food for v9 controls - -**How will we maintain list of packages in issue template:** +1. use only package names or Component name in "Library" picker + +- cons + - huge list because we have quite a lot packages +- pros + - only 1 issue/feature template that we need to maintain + - removes need of `1. project label assignment` as labeling would be handled in one step + +2. creating feature/bug templates per library + +- cons + - 2 (feature/bug) x N templates (N is number of libraries in monorepo) +- pros + - clear separation that can be tweaked to particular library needs if needed + +3. creating completely custom issue form solution (example [vuejs](https://github.com/vuejs/vue/issues/new/choose)) + +- cons + - big effort in terms of development and maintenance +- pros + - complete control about issue reporting + - another possible dog food for v9 controls + +**Workflow approach - summary:** + +After feedback and additional discussion the majority is in favor of "2. creating feature/bug templates per library", where the select list will contain "Component names". + +Simplified example of select box option for project issue template: + +``` +Component: + - Text + - Menu + - Dialog + - ... +``` + +Based no this labels should adhere to following: + +1. react-components(v9 and beyond) + +``` +Text -> components:Text +Menu -> components:Menu +Dialog -> components:Dialog +``` + +2. react-northstar(v0) + +``` +Text -> northstar:Text +Menu -> northstar:Menu +``` + +3. react(v8) + +> NOTE: +> +> Why "fabric" ? while we wanna be consistent with project name mapping to label prefix, using "react" is very abstract, using v8 might be an option but for sake of consistency and distinction "fabric" feels the best option. + +``` +Text -> fabric:Text +Menu -> fabric:Menu +``` + +4. web-components + +> NOTE: +> +> - web-components label will not be changed as for now only `web-components` general label is sufficient. In future we might introduce more granularity + +``` +Text -> wc:Text +Menu -> wc:Menu +``` + +**Q&A:** + +**1. How will we maintain list of packages in issue template:** On library creation/removal we will tweak our issue/feature template automatically. @@ -124,6 +185,10 @@ On library creation/removal we will tweak our issue/feature template automatical Based on assigned labels, we can automate assignment of issues based on our source of truth of ownership which is `CODEOWNERS` file. +> 💡 NOTE: +> +> - every issue will still contain "Triage needed" flag, so it can be verified by person on shield duty + **Workflow:** ```mermaid @@ -158,4 +223,6 @@ NONE ## Open Issues +Not applicable + From d9b832f66462adf50dbde46efd4011e659932266 Mon Sep 17 00:00:00 2001 From: Martin Hochel Date: Thu, 6 Oct 2022 18:04:59 +0200 Subject: [PATCH 4/4] fixup! fixup! fixup! docs(rfcs): add triage automation rfc --- rfcs/shared/build-system/triage-automation.md | 39 ++++++++----------- 1 file changed, 17 insertions(+), 22 deletions(-) diff --git a/rfcs/shared/build-system/triage-automation.md b/rfcs/shared/build-system/triage-automation.md index 471371e1f87d3..6dd541c957d6f 100644 --- a/rfcs/shared/build-system/triage-automation.md +++ b/rfcs/shared/build-system/triage-automation.md @@ -132,43 +132,38 @@ Component: - ... ``` -Based no this labels should adhere to following: +Based on this, all project labels should adhere to unified pattern based on issue origin(project): -1. react-components(v9 and beyond) +1. issue origin: v9 template: ``` -Text -> components:Text -Menu -> components:Menu -Dialog -> components:Dialog +Text -> package: react-text, Fluent UI react-components (v9) +Menu -> package: react-menu, Fluent UI react-components (v9) +Dialog -> package: react-dialog, Fluent UI react-components (v9) ``` -2. react-northstar(v0) +2. issue origin: v8 template: ``` -Text -> northstar:Text -Menu -> northstar:Menu +Text -> package: react, Fluent UI react (v8) +Menu -> package: react, Fluent UI react (v8) +Dialog -> package: react, Fluent UI react (v8) +Chart -> package: react-charting, Fluent UI react (v8) ``` -3. react(v8) - -> NOTE: -> -> Why "fabric" ? while we wanna be consistent with project name mapping to label prefix, using "react" is very abstract, using v8 might be an option but for sake of consistency and distinction "fabric" feels the best option. +3. issue origin: v0 template: ``` -Text -> fabric:Text -Menu -> fabric:Menu +Text -> package: react-northstar, Fluent UI react-northstar (v0) +Menu -> package: react-northstar, Fluent UI react-northstar (v0) +Dialog -> package: react-northstar, Fluent UI react-northstar (v0) ``` -4. web-components - -> NOTE: -> -> - web-components label will not be changed as for now only `web-components` general label is sufficient. In future we might introduce more granularity +4. issue origin: web-components template: ``` -Text -> wc:Text -Menu -> wc:Menu +Text -> package: web-components +Menu -> package: web-components ``` **Q&A:**