Do we need a better way of tracking ongoing hubs?

[choldgraf]

Summary

I'm a bit worried that we do not have a good place to keep track of ongoing hubs and information surrounding them. We have a few places for technical information, but what about things like meetings with members of the hub, details around the deployments, etc? I wonder if we should define a different way of storing this information.

Where is information about hubs currently stored?

Currently we have three places to track information about the hubs that are currently running:

• The list of running hubs: https://pilot-hubs.2i2c.org/en/latest/reference/hubs.html
• The "New Hub" issue used to deploy the hub: one example: New Hub: OceanHackWeek 2021 infrastructure#549
• The "leads" repository where we often track details leading up to the deployment of a new hub: https://github.com/2i2c-org/leads/issues/39

What we are missing

I think we are missing a place to store "meta information" about a hub, that can exist as the "main location" about a hub and its community. For example, this place would have links to the "new hub" issue, the "leads" issue tracking the creation of the hub, and have links to any important meetings and documents.

Where is this kind of information currently stored?

I think right now the closest thing to a place where we store this information is in a combination of:

• Google Drive folder documents
• Links to those documents from the "leads" issue

Some possible solutions

• Standardize a single Google Doc that can be periodically updated as we have meetings etc
• Use a system like Asana, Monday.com, or Notion to keep a database of current hubs that we can update
• Adopt a more rigorous system of updating the leads issues to make sure we have the right metadata for each community
• Wait for the new GitHub Issues projects to release, and try to adopt this as a system
• Use a dedicated "Customer Relationship Management" tool like SalesForce

Questions for others

• Do others on the @2i2c-org/tech-team agree that this is an issue we should improve?
• Any suggestions on a platform or process for tracking this information?

[choldgraf]

At a high level, we can imagine a data entry for each community that has columns for the following things:

• Link to "leads" issue where we track the ongoing conversation with them
• Link to the "new hub" issue where the hub was deployed
• Link to the Google Drive folder where all meeting notes etc exist for that community
• A subset of metadata from the "new hub" issue, so that we can quickly find it (e.g., the cluster and ID of the hub, which could then be used to find the config of the hub)
• Contact information for the hub's Community Representative(s)
• A link to an issue with ongoing notes and conversation about the hub's community

Separately from this, there's the question of platform to track this information. I think my preference would be to do something like:

1. See if the new GitHub Projects can fit into this workflow. If so, convert the leads/ repository into a communities/ repository. Use it to both track new leads (via dedicated issues with the lead tag) as well as ongoing communities that we serve (via a dedicated issue for ongoing notes about the community after the lead issue is closed).
2. Use a platform like Notion to keep a database of these leads, with notes that we update in that platform and a table with the fields listed above for each community.

There are still plenty of details to work out there, but wanted to get some of my thoughts down in case others have ideas or want to iterate!

[sgibson91]

I have a preference for GitHub Projects over Notion. 1) I think adding another tool into the mix could be confusing, and 2) I'm not totally convinced that Notion could fulfil our commitment to transparent, collaborative, open working like GitHub would.

[choldgraf]

Yeah that makes sense to me - I think we should see how it feels with GitHub. Though these "leads/communities" issues would likely be private, since they will often be discussing semi-sensitive things like prices, applying for funding, collaborations that fall through, etc.

[damianavila]

Though these "leads/communities" issues would likely be private, since they will often be discussing semi-sensitive things like prices, applying for funding, collaborations that fall through, etc.

So... we again have the issue that some communities can see other communities' stuff...
Maybe a communities org with communities repos? Or that is too much???

[choldgraf]

My thinking is that the repository would be private. That way we can keep track of sensitive information or conversations about the communities. It would be available to any 2i2c team member with the right permissions, but not available to the whole public.

[damianavila]

Thanks for the clarification, I was mixing things from another ticket, it seems 🤦