-
-
Notifications
You must be signed in to change notification settings - Fork 4
Document the process for sending emails #211
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
base: main
Are you sure you want to change the base?
Conversation
78ae749 to
fe937d6
Compare
|
|
||
| For either of these routes you will need to have configured your SR GMail account to be able to send from `teams@`. | ||
|
|
||
| #### Personalised emails |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could also do this with an extra spreadsheet that includes all the primary contacts and the secondary contacts. This list should be largely static.
Then we can remain within email clients.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Requiring a script to send emails feels overkill to me, and is definitely a barrier for some people (yes, GitHub may also be a barrier, but a very different kind).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first step being having to set up a Python virtual environment would make it a massive barrier for a lot of people and I don't think is a reasonable expectation for our volunteers to have to know/be able to do this. GitHub can be a barrier too, but much easier to overcome imo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for these comments. I appreciate the desire to ensure our processes are accessible and consider various alternatives. However the purpose of this PR is not to propose a new process, but rather to document one which has been in place for the substantial majority of this competition year.
While alternatives may be possible (though the requirements are more complicated than might be expected and the alternatives here aren't easily workable), a number of options were considered and this route chosen as the simplest given the volunteers currently responsible & involved. Documenting the process as it stands does not prevent it being changed in future, though it does immediately make it more accessible than the status quo (namely: no documentation).
Even if the process here isn't optimal, it strikes me as far better that it is documented than that it remain undocumented.
It turns out that our current process wasn't actually what the docs said. This fixes that and adds the other scripts which make up the personalised sending portion of it.
This isn't completely exhaustive in its explanation, however I believe captures most of the salient details. I'm hesitant to have this fully detail every step (it'd likely get quite long and end up documenting a lot of just how to use a particular UI), though if there's any which are unclear let's aim to clarify them.