Determine how we want to track issues and PRs in auxiliary repositories

dotnet / fabricbot-config

Scripts for managing fabricbot configurations in the dotnet repos

MIT License

4 stars 7 forks source link

Determine how we want to track issues and PRs in auxiliary repositories #8

Open jeffhandley opened 2 years ago

jeffhandley commented 2 years ago

We have issues and PRs that our team members are responsible for across several other repositories where the responsibility doesn't align with area ownership and our area pods. We don't currently have a good approach for if or how to integrate those items into the area pod boards.

Example repositories:

roslyn-analyzers
sdk, arcade
iot

Should we create issue/pr boards for those ownerships? Should we include those issues/PRs into the team members' area pod boards? We're leaning toward having separate issue/PR boards for those auxiliary responsibilities that can be aligned to the team members/crews involved.

jeffhandley commented 2 years ago

@buyaa-n and @carlossanlop can weigh in here. Do you think you'd prefer to have another set of issue/pr boards for roslyn-analyzer championship? Or would you prefer for your roslyn-analyzer items to show up on your area pod boards?

carlossanlop commented 2 years ago

Buyaa and I talked about this. We agreed that it would be beneficial for us to have a couple of "Area Pod" projects for Roslyn Analyzers, one for PRs and another for issues. We could then close the project we currently use, which has its limitations.

The benefits of having Area Pod projects like the others, would be:

We could track proposals from dotnet/runtime and issues in dotnet/roslyn-analyzers.
We could track PRs in dotnet/roslyn-analyzers, and the occasional/rare PR in dotnet/runtime related to enabling/disabling analyzers in the repo.
The bot could automatically add stuff to the projects. Currently, we have to add stuff manually.
Right now our project only tracks stuff in runtime, so we often miss things from roslyn-analyzers.
Whenever we add an issue to our current project board, it does not get added to any column. Instead, it stays in limbo, in an "Awaiting triage" state, so if we forget to move that state to a known one, we won't see it in our board.

carlossanlop commented 2 years ago

Oh, one thing to keep in mind is that we need to determine a good way of differentiating between analyzers for Runtime Libraries and analyzers for CoreCLR. The latter ones are owned @dotnet/interop-contrib .

Alternatively, we could split the code-analyzer and code-fixer labels into two, one set for libraries, and another for clr.

jeffhandley commented 2 years ago

I will create area pod boards for analyzers and get this configured. For sdk and arcade, we'll get those items to flow into the infrastructure pod board, and we can then consider if we also need a pod board for iot.

carlossanlop commented 2 years ago

Also, a semi-related question. System.Diagnostics.Metric has an area label in the runtime repo, but no dotnet org group.

Here's an example of a dotnet-api-docs question I had in which I couldn't tag the namespace group because it doesn't yet exist: https://github.com/dotnet/dotnet-api-docs/pull/7889/files#r837878155

Should there be a group for such assembly/namespace too? @tarekgh

tarekgh commented 2 years ago

@[arlossanlop

Also, a semi-related question. System.Diagnostics.Metric has an area label in the runtime repo, but no dotnet org group.

What you mean by dotnet org group?

carlossanlop commented 2 years ago

@tarekgh A group like this one: @dotnet/area-system-text-encoding

tarekgh commented 2 years ago

Please group System.Diagnostics.Metric to @dotnet/area-system-diagnostics-activity the.