Encode community representative information with hub metadata

choldgraf commented 2 years ago

Description

Currently we define the community representative as the primary point-person for a community. However, we do not have a canonical place to encode who the community representative is in our team practices.

We should define a "source of truth" for who is the community representatives for a hub, and how to contact them.

Value / benefit

This will make it easier for us to know who we should be responding to via support@2i2c.org since these people are encouraged to use that channel, and it will also make it explicit to the hub's community who is their point-of-contact with 2i2c.

Implementation details

I can think of two options for this:

Option 1: Encode in AirTable

We could add a column for "Community Representative" in our active hubs airtable. This would be slightly outside of typical engineering team processes (which tend to default to GitHub), but would potentially be a good place for this kind of semi-structured information.

Option 2: Include this information with each hub's configuration

Each hub already has some hub-specific configuration that displays the logo etc on its home page. We could include information about the community representative in this location as well. For example, we could include a field like the following

community_representatives:
  - name: Some name
    github: handle
    email: blahblah@example.com

Around the homepage template section for a hub:

https://github.com/2i2c-org/infrastructure/blob/6cf0a3ff3c9edf2154791e26c269dbbf681d5234/config/hubs/2i2c.cluster.yaml#L33-L46

then we could use this metadata to populate our "list of hubs table" for a quick reference, similar to how I propose adding a field for the grafana URL in this PR: https://github.com/2i2c-org/infrastructure/pull/817

Finally, this could be included in the homepage of the hub itself, so that the hub's users can have a call-to-action to connect with their community representative if something is going wrong. Similar to how the U.Toronto Hub handles this:

Tasks to complete

[ ] Decide on one of the options above (or a new option not proposed here)
[ ] ...add next steps depending on the above decision

Updates

No response

damianavila commented 2 years ago

Can we have both options somehow? I see value in both propositions (just different audiences).

choldgraf commented 2 years ago

@damianavila the thing that I worry about is that there is then no single source of truth for that information - say a community representative changed, you'd need to remember to update both of them :-/ . If we had to pick one, what would you pick? (or, can you think of a clever way to synchronize them?)

damianavila commented 2 years ago

Let's use our repo as the single SSOT and then a link in the AirTable? I know it is not elegant but when we split the cluster config file to hubs config files, then the link should be pretty stable, right? (we can even just link the hub config file and let the user quickly find the info... instead of linking one specific line).

damianavila commented 2 years ago

One alternative is some GH action collecting the data from our repo and dropping it into a spreadsheet and then using the AirTable automation tools to read from that sheet. More convoluted but probably a better experience...

yuvipanda commented 6 months ago

Closed as dupe of https://github.com/2i2c-org/infrastructure/issues/3698, which is now complete

2i2c-org / infrastructure