"jrbs" are my initials. I don't really use a personal Phabricator account; I'll try to flag stuff I'm doing in my volunteer capacity as such.
User Details
- User Since
- Jun 30 2015, 10:08 PM (553 w, 5 d)
- Availability
- Available
- IRC Nick
- foks / tzatziki
- LDAP User
- Foks
- MediaWiki User
- JSutherland (WMF) [ Global Accounts ]
Sat, Jan 31
Yes - the results are:
Tue, Jan 27
Just in case there are still concerns with the above I have set it to start at 06:00 UTC on *Thursday*. We can move it again if necessary before the poll begins, but it is harder to move it after it has already started.
I can set this up (it will be quite tight for Nahid I think if you want to start it this soon).
Mon, Jan 26
Sun, Jan 18
Dec 28 2025
Could I please ask that this conversation move to a more appropriate venue? This task has been declined for a while now.
Dec 11 2025
Dec 10 2025
Dec 8 2025
Yes, but we are getting 15-20 duplicate emails per day, and this is quite a burden on our small support desk.
Nov 21 2025
Nov 18 2025
Nov 17 2025
This is actually handled entirely by triggers apparently :) I have set those up and I believe all is well.
Oct 24 2025
I believe this is resolved with Tran's work above. Thank you so much.
To clarify, this is referring to the Echo notifications and not the emails sent with sendMail.php, which open with Dear $USERNAME, I think. It may require upstream changes to how Echo distributes email since if I remember correctly it is not possible to include variables in these messages.
Yes, that sounds fair. A good thing to clarify for the 2027 cycle as well.
Oct 23 2025
Oct 16 2025
I filed T407526 for this. The issue is that I forgot to remove those who added their names to the list since the first mail. I apologise for that oversight.
I saw this was reopened and I think I know why. The script uses the nomail list when it is compiling the list for the first time. Reminder emails use that same list.
Oct 14 2025
We plan to run a "reminder" notification as well. I'll file a patch just replacing these messages but I'm not sure what the actual best path is for that.
Oct 10 2025
I added this to the voter info blurb:
Indeed I apparently triggered the first log and get a similar error now:
Is there a button / link to a noJS view? I'm really hesitant to just disable the drag-and-drop for everyone since it is much more intuitive as a voting solution and works for the majority of people.
I only ran into this once, doing it again seems to be fine.
I guess the quickest solution might be to force noJS view on mobile (even on the desktop view) but I have no idea how easy that is.
These are sending now. Thank you!
Oct 9 2025
Woops, I was querying the wrong table.
This might just be me being stupid since JSutherland (WMF) is in there (that's me!) but I definitely have not voted with that account. So possibly my SQL query is incorrect.
Board vote has indeed started! But I think generally we shouldn't push anything while that is open either, in case it causes a regression that impacts the results.
Oct 6 2025
After, on the poll creation / edit screen.
Oct 3 2025
I'm not sure if this would impact the election (the config appears to be saved correctly so it is probably fine?) but would really appreciate PSI have a quick look at this just in case.
Oct 1 2025
Now that it is October my edit count seems to be fixed. Seems that's not true for everyone?
Sep 29 2025
I have basically resolved this with an Apps Script function. We can focus on T399742
This is done!
Sep 26 2025
Hi @Dzahn, sorry for the vagueness of the request.
Sep 19 2025
This is merged now and requests are coming through, so I'm calling this particular task Resolved. There remains some confusion on T390657.
Sorry for the confusion here as a result of T399749. I'm not sure merging the pages makes sense, since the audiences are probably slightly different: The Meta page is for immediate help getting back into an account (and is Wikimedia-specific) while the MW page is more about the extension itself.
Sep 17 2025
Sep 16 2025
Yes, I think that would work!
Sep 15 2025
I think this just needs a decision on how to handle this part of the code:
Sep 11 2025
Got to the bottom of it. All jobs should have been terminated now. There was an issue with the script that was compiling lists with waaaay too many users due to a missed step in the procedure. My apologies for that.
I have deleted all the ml-* files, some of which were incredibly big. So hopefully that resolves the issue.
I'll shut them down. Working with Tim on what happened here
Sep 10 2025
Thinking out loud a bit here, is it possible to convert XML to BLT?
Sep 8 2025
I think we probably should split this into two tasks, one for the design of such a form and one for grabbing requests sent through it and passing them to Zendesk.
The Connector seems to work for this, but it's quite slow. It should suffice for what we want here unless we can leverage the API at the same time (i.e. while solving T404009: Use Zendesk API to get requester emails into the spreadsheet.
Sep 6 2025
The new message will have two targets:
- https://meta.wikimedia.org/wiki/Help:Account_recovery -> Zendesk form.
- MediaWiki native form (T399742)
Sep 4 2025
Hi, sorry for my delayed response here.
Aug 29 2025
Just to quickly update here, I have added the voter list to my local deploy1003 space so can run this after voting opens next month.
Aug 28 2025
There are two paths forward for this in my eyes:
- Someone with PHP skills should help rewrite the script to no longer create a bunch of files and instead do both of these stages in memory somehow, if that's even possible.
- Kubernetes needs to allow us to create and refer to files (writing them to home dir rather than data perhaps?). This is probably much harder and longer-term project.
Aug 27 2025
Aug 26 2025
Yes, sorry for the delay in updating here. I am anticipating it will move up to match, so will re-begin on 1 September.
Aug 21 2025
My apologies for the delay. This slipped through the cracks of my inbox.
Aug 20 2025
Aug 14 2025
This was actually basically resolved: https://dmca.toolforge.org/