We recently discovered a major issue with the library's emails (T347512). This was causing users to not receive emails from us, and we had very little visibility into the issue. Cloud VPS is not particularly well set up to handle sending emails reliably, and maintaining email infrastructure would be a major source of technical overhead for us. We have fixed the issue for now, but would like to move away from relying on emails as our notification and information sharing strategy.
This Epic will house all the steps that need to be taken for this to become a reality. We plan to spend maintenance time on this project, or prioritise it where we have gaps in our other work.
Our intended solution for each email is to make changes to the Library to integrate any information that was being shared in the email, and use TheWikipediaLibrary extension to send a notification about this information instead of an email. These steps don't need to happen concurrently, as we can adjust emails to contain placeholder messages similar to how the notification will ultimately read until we're ready to work on the on-wiki components.
Emails currently being sent by TWL
Full details can be found in this spreadsheet.
Tickets to be created.
| Purpose | Feature ticket | Echo ticket | |
|---|---|---|---|
| Application: Approval | Notify user that their application has been approved. | ||
| Application: Rejection | Notify user that their application has been declined. | N/A | |
| Application: Waitlisted | Notify user that their application has been added to a waitlist for when we have access available again. | N/A | |
| Access code | Provide user with their access code or login details for an approved application. | ||
| Renewal needed | Notify user that their access to a collection will expire soon, but they can request an extension. | ||
| Application comment - user | Notify user that their application has received a comment requiring their attention. | N/A | |
| Application comment - coordinator | Notify a coordinator that an application they reviewed or are responsible for has been commented on. | N/A | |
| Application comment - other | Notify someone who isn't the filing user or coordinator that an application they commented on has received another comment. | N/A | |
| Coordinator reminder | Notify a coordinator that there are applications which require their review. | ||
| Contact Us form | Enable users to easily email wikipedialibrary@wikimedia.org from the library. | Already removed. | N/A |
| Block hash change | Notify Wikipedia Library staff that a user's block status has changed and requires review. | N/A | |
Tasks which would require modification
Mostly just changing 'email' to 'notification', but some require a bit more of a rethink.
- T314491: Enable staff to email authorized users of a resource when it moves to Library Bundle
- T211141: Allow staff to send a notice to suggestion submitter and all upvoters
- T304512: Don't send multiple waitlist emails to users who already received one for a given application
- T226369: Don't send coordinator comment notification email if user isn't currently the coordinator
- T170663: Give users the option of opting-in to emails when new partners are made available
Tasks which would be made redundant or fixed by this one
- T299511: Investigate feasibility of only getting user's email address via OAuth when needed for a non-proxy application
- T275150: line breaks in Wikipedia Library card text emails are probably wrong in translation
- T270066: Prevent coordinator email server error on some applications
- T264422: Review and expand code documentation for emails
- T309856: Access Code emails should include user instructions
- T334860: Add a user preference to enable users to turn off suggestion notification emails
- T264416: Evaluate and document email tests
- T147469: Automate process of sending email to publishers
- T147467: Add a welcome email