Determine communication channels for the education hubs

[choldgraf]

Background

As more courses use 2i2c Hubs for their teaching, they will need a place to speak with one another, with the CDSS teams, and with 2i2c people. There are roughly three kinds of communication that we should think about:

• Informal and quick communication
• Unstructured but searchable / archivable information
• Formal To-Do conversation items

We should have a place for each type of communication, and ideally non-overlapping spaces.

Proposed Workflow

If people want quick and informal chatter they use Slack. This is the "messiest" of all communication spaces. We'll invite them to talk on the dsep-pilot-hubs Slack room in 2i2c (perhaps this room should be shared with the DSEP slack?)

In general we recommend people ask questions and give feedback via GitHub Discussions. This is a Q&A-style forum that is attached to this repository.

If people have specific requests they'd like to make for the hub infrastructure, we use GitHub Issues for this. In addition, specific items that arise out of GitHub Discussions will become Issues as well.

ToDo

• [ ] Agree on the proposed workflow above
• [ ] Do whatever setup is needed to make this happen
  • [ ] Informal/quick
  • [ ] Unstructured but searchable
  • [ ] Formal To-Do

[sandeepsainath]

Here are my suggestions based on our last meeting (12/18):

Informal/quick: Slack works well as a quick instant messaging tool, and informal/quick communication doesn't require search-ability and long-term memory.

Unstructured but searchable: I like email threads with relevant people CC'd. It's also useful since both pilot organizers (DSUS, 2i2c) and institutions are familiar with emailing, and is a clear way of communication.

Formal To-Do conversation items: The two best options are likely GitHub issues on the 2i2c repo and Discourse. On average, both would probably be newer for institutions to navigate and somewhat challenging to get accustomed to (compared to Slack/email) so maybe the priority should be functionality and clarity. I think GitHub issues is a proven vanilla-like method and would probably just fine, whereas Discourse seems better as a long-term option since grouping things into Categories seems efficient and clear. There's also additional functionality like pinning posts and more channels of communication in terms of what's publicly available and what's not. I'm happy to experiment with Discourse for the pilot if people are willing!

[choldgraf]

Thanks for this feedback @sandeepsainath - a couple thoughts:

unstructured but searchable

The challenge with email is that it's only searchable for people included on the email messages, and it's often hard to know who are the relevant people ahead of time. E.g., on the DataHub we have a ton of emails to support asking the same question. If those emails were instead in some kind of public forum, then it would theoretically be less work to field multiples of the same question, since you'd just point to the public place where it was asked once.

Formal To-Do

I think there are two kinds of formal items: user support questions, and infrastructure team to-do follow-ups. Perhaps we should use a Discourse/GitHub one-two punch, where users are expected to use Discourse, and then the infrastructure team can create GitHub issues to follow-up as needed.

[choldgraf]

After our last conversation, it sounded like we had converged on a communication channel approach. I've updated the top level comment to reflect this. @ericvd-ucb and @sandeepsainath can you confirm that this works for you? and can you loop in Ksenya's github handle? I can't seem to find it.

[sandeepsainath]

This works for me! Kseniya's GitHub handle is @kseniyausovich.