Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Core Email Efficiency - Suggesting Improvements #13926

Open
shar1z opened this issue Apr 10, 2024 · 0 comments
Open

Core Email Efficiency - Suggesting Improvements #13926

shar1z opened this issue Apr 10, 2024 · 0 comments

Comments

@shar1z
Copy link
Contributor

shar1z commented Apr 10, 2024

Hi Core Team!

As we all struggle with finding task-oriented emails in our inboxes, due to the fact that the [email protected] email address that has all cities' ongoing activities fed into our inboxes as a governance mechanism, I'd like to suggest a better way to be able to flag task-related incoming messages with a couple of options that we can vote on as the core team.

We recently worked on a document that aggregates the large majority of ongoing tasks core members are committed to helping with. In order to decrease response time, I would like to propose alternate methods. Note these may currently be a patch/workaround until a longer-term email plan is agreed upon, but it might reduce the clutter.

For the specific tasks such as:

  • Updating mailing lists
  • Adding folks to Slack
  • Questions about website / requests to expedite website edits
  • Inquiries about specific cities sent to "info" only (that need to be redirected)
  • Other ongoing updates / requests that may come in related to cities (that don't come to mind right now)

That often get lost in our inboxes due to other city-related email, I'd like to propose other options for ongoing management.

I propose two options that we can vote on with either a 🎉 (Option 1) OR 🚀 (Option 2) or 👎 if you are opposed to either (but then please follow up in the discussion with your thoughts on why these won't work).

OPTION 1️⃣ - Vote 🎉
Change the email address of all task-oriented updates to something like [email protected], where we can then apply automation through Zapier or other programs to send an alert based on the specific email address to a dedicated slack channel called "#core-tasks". In this way core members can have just these tasks specifically flagged with an ongoing feed of tasks, and respond with a ✅ when completed.

OPTION 2️⃣ - Vote 🚀
Change the method entirely of how these tasks are requested. Make Github the single source of truth for requesting such tasks (as Github is anyway required for managing the city website), where we have a dedicated template per request type (which is usually pretty standard in any case).

E.g. Add New Member would require opening an issue and selecting a template from a drop down menu that would include: Name, Email Address, Reason being removed/added etc. Just for ongoing monitoring/governance.

We can then assign these templates automatic labels with the name of the task "Add/Remove Member", "Update Slack". These too can be automated and sent to the "core-tasks" Slack channel through third-party programs (or GH Actions), and the ✅ employed when tasks are completed.

An added bonus is if we use such an email address or Github method - the Global Co-Chairs (or anyone else from core) could leverage this to delegate tasks more easily to the team by sending a quick email with a relevant Subject or creating an issue with a specific task label (Core Team Task) - so it gets fed into our Slack task channel. (E.g. If there's a particularly gnarly web edit that you want to delegate - or if there are easy web edits that others that are less technical can pick up).

Happy to hear your thoughts / feedback, or alternate suggestions.

CC:
@phrawzty @jyee @adrianmoisey @FloorD @glasnt @gomex @camilla-m @serhatcan @somatorio (Sorry Michelle - couldn't find your user to tag you 😮‍💨)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant