Skip to content

Conversation

@PeterJCLaw
Copy link
Member

@PeterJCLaw PeterJCLaw commented Mar 5, 2025

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.

@PeterJCLaw PeterJCLaw requested a review from Adimote March 11, 2025 19:37
@PeterJCLaw PeterJCLaw marked this pull request as ready for review March 11, 2025 19:39

For either of these routes you will need to have configured your SR GMail account to be able to send from `teams@`.

#### Personalised emails
Copy link
Contributor

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.

Copy link
Member

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).

Copy link
Contributor

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

Copy link
Member Author

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.

@PeterJCLaw PeterJCLaw requested a review from raccube March 12, 2025 19:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants