search

2i2c-org / infrastructure

Infrastructure for configuring and deploying our community JupyterHubs.
https://infrastructure.2i2c.org
BSD 3-Clause "New" or "Revised" License
103 stars 63 forks source link

Procedure for emailing all community representatives #3048

Open consideRatio opened 1 year ago

consideRatio commented 1 year ago

There are situations where we may want to email all community representatives to inform them of an upcoming change or something else. But how do we do this practically? Let's assume there is agreement that we want to communicate something to all community representatives via email for now, then how do we go about it?

Draft idea on procedure to email all community reps

  1. An email text is drafted via a google document
  2. The email text is reviewed by partnership, and engineering if relevant
  3. The email is sent - but how?
    • FROM: support@2i2c.freshdesk.com
    • TO: support@2i2c.freshdesk.com
    • BCC: all the individual community representatives emails from a list somewhere

The outcomes of this idea is:

Missing information

If this procedure is agreed on, it still is missing details about:

Related

damianavila commented 1 year ago

cc @2i2c-org/partnerships-and-community-guidance, can you please provide feedback on the proposed idea?

yuvipanda commented 1 year ago

@consideRatio would you consider https://github.com/2i2c-org/infrastructure/pull/3042 blocked on this issue? I'm not sure who is responsible for currently pushing this forward. I don't think it should be you, as I think you're already pretty overloaded.

damianavila commented 1 year ago

@jmunroe and @colliand, can you please provide feedback on the proposed idea? Additionally, we will need your intervention/participation as well to unblock this one.

colliand commented 1 year ago

Yes. I agree with this idea. 2i2c should manage a list of hub champions. The Google/bcc approach will likely work but requires 2i2c personnel to manually manage the list. With GDPR and no-spam rules, there will be risks with the manual management of the list. I suggest we use a list serve or another system (MailChimp, Campaign Monitor) for managing transactional emails. This kind of resource can also be used for other kinds of messages (quarterly updates, marketing).

What is the priority on this? Echoing Yuvi's message above, is the absence of a system to announce breaking changes blocking something?

damianavila commented 1 year ago

What is the priority on this? Echoing Yuvi's message above, is the absence of a system to announce breaking changes blocking something?

Yep, we currently have this one blocked: https://github.com/2i2c-org/infrastructure/pull/3042#issuecomment-1696633530

consideRatio commented 1 year ago

I'd like this to be blocking #3042 as at least the QCL community ought to be be informed about this being done before its done to avoid possibly interrupting a long running simulation now or in the future. I'm okaish with only communicate to QCL specifically about this, but I see the communication part as very important as well to resolve no matter what.

damianavila commented 1 year ago

I think we need to find a "sweet" equilibrium point here. In this case, that sweet equilibrium spot would be to identify a way to communicate the change to the "affected" communities (even if it is just a simple email), send that email to those communities, and merge the PR during this sprint.

This is in agreement with:

I'm okaish with only communicate to QCL specifically about this, but I see the communication part as very important as well to resolve no matter what.

@jmunroe and/or @colliand, can we make sure we communicate with the potentially "affected" communities (those running long computations) via email/support in the next few days, so we can move #3042 forward and merge it sooner rather than later (target: during the current sprint). Thanks!

jmunroe commented 1 year ago

I am working on are broader community success strategy that needs will include a communication strategy with community reps. I a have product call coming up with the Freshworks folks to see what their platform offers in this area. However, I do not think that a manual email / Google doc procedure works.

However, we shouldn't be blocking #3042 waiting on this communication plan. Other that QCL, I am not aware of any communities who are intentionally running jobs longer than 7 days. I will email QCL (via Freshdesk so that there is a tracking of this conversation) and let them know we are changing the base configuration to have a limit. From a discussion with @damianavila , my understanding is we can make this longer for QCL (or any other community) if they truly do want longer than 7 days.

consideRatio commented 1 year ago

Thank you @jmunroe!!!

jmunroe commented 1 year ago

I sent the email within Freshdesk using the 'New email' feature: https://2i2c.freshdesk.com/a/tickets/972

jmunroe commented 11 months ago

With PR https://github.com/2i2c-org/infrastructure/pull/3144 there is an opportunity to iterate on our communication strategy to hub champions.

I've created a "mailing list" of those who I think are the appropriate technical contacts for our communities in a new AirTable table. I sent out an email using FreshDesk support email with each technical contact entered sent as bcc.

See https://2i2c.freshdesk.com/a/tickets/1014 for the details.

consideRatio commented 11 months ago

When I created this issue, I didn't know how to reach to a community champion if I didn't already know about who that was.

Now I've managed to do it for Smithsonian that had a failure in the production hub resolved by https://github.com/2i2c-org/infrastructure/pull/3234. This was detected by us before being reported to us by the community.

I did like this:

yuvipanda commented 7 months ago

As me and @sgibson91 work on https://github.com/2i2c-org/team-compass/pull/797, I had to take a stab at this. I realized that if I simply try to say 'it should come from community representative' without a way for support folks to know who that is makes it a not very useful change. So creating an authoritative source of truth for support purposes was necessary.

Thanks to @consideRatio documenting his process above, I was able to find the 'Contracts and accounting' airtable (https://airtable.com/appS0TyrRnEs3QWG1/tbl3ycLuefGJ9jaoi/viwCUvjuGb2GHTy1b?blocks=show). However, I think this is probably more helpful for... contracts and accounting, as I recognize that many of the folks whose names were in the Champions column were the internal champions for the hub service in their orgs, but don't necessarily use the hub themselves. They're not the folks who have already been sending us support tickets, and blocking on approval from them would not be helpful, as they're often too high level.

So I have created https://airtable.com/appxk7c9WUsDjSi0Q/tbl3CWOgyoEtuGuIw/viwtpo7RxkYv63hiD?blocks=hide, which I believe is the closest we have to a source of truth for our community representatives from a support & maintenance perspective. If you can't access the airtable, the 2i2c airtable account credentials should be in our bitwarden. It's fairly complete, missing only 4 hubs. Here's the process I used to determine this:

  1. I went through literally every support ticket that was created since we started using freshdesk! Yes that was quite a few, but it was the only way to extract the lived experience of knowing who contacts us for what. This took a while, but was worth it. This was the primary source of this airtable data. I only looked at tickets in the 'Support' group, not community guidance or partnerships.
  2. I also looked at https://2i2c.freshdesk.com/a/tickets/1014 from @jmunroe (sent for https://github.com/2i2c-org/infrastructure/issues/3048#issuecomment-1745738483) to make sure I caught everyone. I picked up a straggler here (MEOM-IGE).

So I now believe that the airtable I linked to is useful for two purposes:

  1. Validating who can send us support requests
  2. Being able to announce any breaking maintenance (@consideRatio's first request here).

There's ongoing (and extremely important!) question of how to make sure this is ongoing and complete. I'll work on tackling that tomorrow, as I recognize that a 'one time' drop that goes out of date quickly is not helpful. But I've exceeded my daily work hour limit today, so I'll be back tomorrow :)

jmunroe commented 7 months ago

Wow, @yuvipanda -- that's a ton of labor to go through all of the historical data on FreshDesk.

There is primary Airtable database that Partnerships is using be the source of truth on our contracts, communities, and hubs is the "Partnerships" database https://airtable.com/appbjBTRIbgRiElkr/tblYGygEo5PQBSUYt/viwGZLBERreDcvUMO?blocks=hide

The "Contracts and Accounting" database is deprecated (I think that what the Sept 15, 2023 is supposed to represent).

To make this work ongoing and complete, I think it is best that we integrate this on going work of Partnerships.

If I was to create a new view on a table with in the Partnerships that exposed this 'list of people from whom support request should be received" would that be acceptable?

yuvipanda commented 7 months ago

Ah, thanks @jmunroe. The link you posted has the same issue as the other airtable I found - basically:

However, I think this is probably more helpful for... contracts and accounting, as I recognize that many of the folks whose names were in the Champions column were the internal champions for the hub service in their orgs, but don't necessarily use the hub themselves. They're not the folks who have already been sending us support tickets, and blocking on approval from them would not be helpful, as they're often too high level.

It's also missing names for many hubs, and doesn't contain email addresses. There are many people who are defacto community champions (as people who run the hub, and email support) that are missing there. And a lot of the folks there I know are pretty 'high level', and it would not be appropriate to email them to ask for approval if someone else emails us a support ticket. Sometimes folks also authorize additional people to email us on their behalf (this happened for UBC for example).

One thought is to not use the word 'community champion', which may be a bit overloaded here. And perhaps this airtable I made can simply be called 'people authorized to open support tickets for a particular hub', and is managed by whichever group is managing support at any given time. In particular, this would help make sure that it's fully accurate, as delegations do happen often (has happened a few times in UofT). That was the reason I used freshdesk as the source here.

jmunroe commented 7 months ago

While not as comprehensive as your list, that's what I was attempting to do in creating the 'Technical Contacts' table in the Partnerships base but that was only a WIP. I will add the names/email addresses you have identified.

Regarding nomenclature, I was reminded today on some work from the Catalyst Project where a similar issue was discussed:

Common Terms from the Catalyst Project:

  • Community leaders: Community leadership members. Members of the community that approves the community engagement with the Catalyst Project
  • Hub champion: A technical member of the community that may or may not be part of the community leadership that will be responsible for technically supporting community members on using the cloud infrastructure.
  • Community champion: A member of the community that may or may not be part of the community leadership that will be responsible for supporting the community inclusion, participating in governance working sessions, and in open science training. The hub and community champion can be the same or a different person
yuvipanda commented 7 months ago

@jmunroe aha, that makes sense. I agree that 'technical contact' is the right place for that - sorry I had only seen the 'community champion' part of that. Let me know when you've moved the information over, and I'll update https://github.com/2i2c-org/team-compass/pull/797.

Grateful to integrate into your prior work! Thanks for doing that.

I want two additional parts to be added:

  1. As part of the 'new hub' issue, the person bringing the hub must access the airtable and verify there are technical contacts present.
  2. A procedure for folks handling support to handle delegations, where someone who is a technical contact nominates someone else to be one. While we should probably charge extra for this, i want to start by just encoding what we are currently doing and go from there.

Excited as we get all this more systematized.

jmunroe commented 7 months ago

After a conversation with @yuvipanda , I'm in the processing of creating an 'Authorized Support Ticket Initiators' Airtable view that that is built off data that is within the Partnerships base.

yuvipanda commented 7 months ago

I've added a checklist item to new hub turn up to make sure that technical contact exists: https://github.com/2i2c-org/infrastructure/pull/3634

yuvipanda commented 7 months ago

@damianavila I've set assignee to @jmunroe for now, I can pick it back up to move the airtable links over when the migration from the airtable i created to the partnerships one is complete.

yuvipanda commented 7 months ago

I've split the specifics of what @jmunroe signed up for into https://github.com/2i2c-org/infrastructure/issues/3698. I'm going to remove his assignment here, and assign him to that issue instead.