Using GitHub teams to help communicate with contributor groups

[tylerbutler]

Update 2021-12-07: Sadly this plan won't work for cross-organization communication. See #8267 (reply in thread) for more info.

---

More of our development is being distributed across different teams, both in and outside Microsoft. I think it would be helpful to have GitHub teams for groups of folks that are working in a particular area, so we can @mention them easily in discussions and issues. As the contributor base grows, we'll want to shift to more group-based communication where possible. We have already created some teams for code review, like @microsoft/fluid-cr-api and @microsoft/fluid-cr-docs.

I don't want to create a bunch of groups for "fun." :) So if we're not going to put a team to use immediately, lets not create it. So my proposal is modest:

1. A group for public API owners -- we could use fluid-cr-api for this purpose but I am inclined to keep them separate -- one is for code review, and the other is all 'owners' of public API packages. What do you think, @skylerjokiel?
2. A group (or multiple?) for PropertyDDS -- again we could re-use groups if AutoDesk already has groups they want to use. @DLehenbauer, can you loop in the relevant folks to this thread to get their input?

Are there other groups that you would like to have? @vladsud @anthony-murphy I know you two get pinged directly for a lot of stuff -- is there any of that you'd like to shift to a team (even if it's a team of 1 to start :))?

[tylerbutler]

@danielroney @nmsimons FYI.

[DLehenbauer]

I think one group for the tree DDS should be enough. (Autodesk = @ruiterr @karlbom @nedalhy @evaliyev )

[tylerbutler]

Thanks! Sadly, GitHub Teams are a feature of "organizations" and don't support adding members outside the organization. So my dream of a group with members across organizations isn't feasible. Also, we can't add teams from other organizations to our repos -- only individuals. So even if there are appropriate teams in other orgs like Audodesk, they can't be @mentioned or assigned repo permissions.

Maybe the best we can do for now is add a "contacts/owners" page to the wiki and configure CODEOWNERS/PR review assignments appropriately. I'll give this some more thought.

[tylerbutler]

I have created several code reviewer teams as part of addressing #8701. See PR #8848 for the in-progress code/config changes.

The table below lists the teams I created and their intended maintainers/members. I tried to roughly follow the existing code review groups that we use today, but I made some simplifications and updates. Please let me know if you want changes to any of these teams. They're easy to update, so if you get spammed we can adjust as needed.

Team	Maintainers	Members
fluid-cr-api	@skylerjokiel	@heliocliu
fluid-cr-core	tylerbutler @vladsud @anthony-murphy @curtisman
fluid-cr-dds	@ChumpChief @anthony-murphy
fluid-cr-docs	tylerbutler
fluid-cr-drivers	@vladsud @tanviraumi	@jatgarg @znewton
fluid-cr-framework	@skylerjokiel @ChumpChief
fluid-cr-infra	tylerbutler @heliocliu
fluid-cr-internal-api	tylerbutler
fluid-cr-loader	@vladsud @anthony-murphy
fluid-cr-odsp	@vladsud @jatgarg
fluid-cr-runtime	@vladsud @curtisman
fluid-cr-server	@tanviraumi @anthony-murphy	@GaryWilber @hedasilv @pradeepvairamani
fluid-cr-telemetry	@markfields @vladsud	@wes-carlson
fluid-cr-test	@agarwal-navin @markfields
fluid-cr-tools	@anthony-murphy @jatgarg @agarwal-navin
fluid-cr-tree	@taylorsw04 @DLehenbauer	@CraigMacomber
PropertyDDS (no team since not everyone in the Microsoft organization)	@evaliyev @karlbom @nedalhy @ruiterr

[tylerbutler]

I have updated all the teams with members as defined in the table. My PR #8848 is ready for review. I'd like to merge it tomorrow if possible.

[vladsud]

I'm afraid to touch that monster html :) Could you please

• add me & Jatin to fluid-cr-odsp
• add me to telemetry
• You can put Navin and/or Jatin to fluid-cr-tools, I feel like you can remove me from there.

My biggest worry here is API. And how we make sure right things happen across layers. I'll give you some examples of where I'd love to be involved, maybe it should happen outside of this table / discussion:

• DDS API. There are certain patterns that just do not work well with offline, and it would be great to have a forum to discuss these. (that's just one angle).
• Composability: this impacts multiple layers (mostly runtime), but our structure does not facilitate building reusable code (globals in the form of container runtime, etc.)

[tylerbutler]

Haha, yeah the table was a copy/paste from excel... I'll make the changes you mentioned. And maybe clean up the table. :)

[tylerbutler]

I updated the table with these updates and reformatted it to a standard markdown table. RE: your API worries, I share them. :) I will share some ideas in a separate reply.