Page MenuHomePhabricator

Vermont (Vermont)
User

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Tuesday

  • Clear sailing ahead.

User Details

User Since
Dec 1 2017, 8:14 PM (333 w, 1 d)
Availability
Available
IRC Nick
Vermont
LDAP User
Unknown
MediaWiki User
Vermont [ Global Accounts ]

Recent Activity

Feb 15 2024

Vermont added a comment to T17294: Allow blocking of global accounts.

My proposed simple guide...

Feb 15 2024, 5:30 PM · Temporary accounts, MediaWiki-Platform-Team, MediaWiki-Blocks, Goal, Epic, Stewards-and-global-tools, GlobalBlocking
Vermont added a comment to T17294: Allow blocking of global accounts.
In T17294#9527056, @Sj wrote:

@Dreamy_Jazz thank you for working through this. Do you need feedback on some of those comments from one of the stewards requesting this?

It would be useful to know how much of a use-case there is for allowing local wikis to disable a global block on an account.

This is the point :P

Feb 15 2024, 5:26 PM · Temporary accounts, MediaWiki-Platform-Team, MediaWiki-Blocks, Goal, Epic, Stewards-and-global-tools, GlobalBlocking

Feb 13 2024

Vermont added a member for Stewards-and-global-tools: Vermont.
Feb 13 2024, 1:53 AM
Vermont added a comment to T357118: Block message in MobileFrontend does not show original block reasons for composite blocks.

This doesn't appear to be a bug; "appeals" of blocks are not a technical function and the blocking admin appears to be able to add any information, such as project specific appeal information, to the "Reason" field if they wish. Other than having the default message say something like "Contact your project administration" - where would this even go?

Feb 13 2024, 1:47 AM · Trust and Safety Product Team, MobileFrontend

Jan 25 2024

FriedrickMILBarbarossa awarded T355844: CentralAuth shows incorrect user groups a Pterodactyl token.
Jan 25 2024, 1:36 AM · MediaWiki-Platform-Team, MediaWiki-extensions-CentralAuth
Vermont created T355844: CentralAuth shows incorrect user groups.
Jan 25 2024, 1:27 AM · MediaWiki-Platform-Team, MediaWiki-extensions-CentralAuth

Jan 19 2024

Vermont added a comment to T355286: [Epic] Globally blocking a temporary account should prevent further account creations.

People clearly want global locking to work like global blocking (e.g. T333244: Warn and confirm for self global locks, T19929: CentralAuth account locks should trigger global autoblocks). It doesn't make sense to maintain two parallel blocking infrastructures, especially when one of them doesn't integrate with MediaWiki's blocking system at all. Especially for something highly sensitive such as preventing account access (which the block system can also do, it's just not used on public Wikimedia wikis). The potential for conflict between local and global blocks was a problem, but the multiblocks migration resolves that, so we can just axe global locks and have GlobalBlocking (and normal blocking for non-SUL wikis, if there is any interest in that) take over the functionality.

Jan 19 2024, 4:11 AM · Stewards-and-global-tools, MediaWiki-Platform-Team, MediaWiki-extensions-CentralAuth, Temporary accounts
Vermont added a comment to T355286: [Epic] Globally blocking a temporary account should prevent further account creations.

I think we should generally get rid of global locking and extend GlobalBlocking to non-anonymous users instead (T17294: Allow blocking of global accounts). It's on my todo list to see if the WIP patch on that task can be fixed up with limited effort.

In standard practices perhaps, though locking is still relevant for scenarios such as account compromises, deceased users, etc.

In this case Tgr propose to replace it with a variant of T222281: Add a way to prevent user from log in and disable a users session when blocking. Note if block-disable-login is available, in SUL wikis we need to prevent it be used locally, i.e. such option may only be enablable with a global block, not a local one, since it does not make sense if we lock out a user in wiki A but not wiki B.

Jan 19 2024, 1:33 AM · Stewards-and-global-tools, MediaWiki-Platform-Team, MediaWiki-extensions-CentralAuth, Temporary accounts
Vermont added a comment to T355286: [Epic] Globally blocking a temporary account should prevent further account creations.

+1 to Xaosflux. Global locks are a necessary tool, though global blocks should also be an option.

Jan 19 2024, 1:23 AM · Stewards-and-global-tools, MediaWiki-Platform-Team, MediaWiki-extensions-CentralAuth, Temporary accounts

Nov 18 2023

Vermont updated subscribers of T351579: Wikimania banner wm2023scholarcfp_2 says "see main page".

@sgrabarczuk: Would you be okay if I remove that line from the banner text? It won't affect translations of the other line, as they're two separate units.

Nov 18 2023, 3:50 AM · Wikimedia-CentralNotice-Administration
Vermont added a member for Wikimedia-CentralNotice-Administration: Vermont.
Nov 18 2023, 3:44 AM

Sep 5 2023

Vermont added a comment to T340275: Allow GlobalBlocking to block temporary accounts.

I think T17294: Allow blocking of global accounts should be fixed instead.

Quick update - we are discussing this actively and there is a good chance we will end up working on T17294: Allow blocking of global accounts instead of this task. I will have another update within a couple of weeks. Thanks all for the helpful comments.

Sep 5 2023, 11:12 PM · Temporary accounts, GlobalBlocking

Aug 30 2023

Vermont added a comment to T340275: Allow GlobalBlocking to block temporary accounts.
In T340275#9129585, @Sj wrote:

I would certainly be able to work with a semi-soft block. As it's possible to assign confirmed flags to new accounts, a variation could also allow running editing workshops through such blocked ranges. [schools often being subject to such blocks]

Aug 30 2023, 1:32 PM · Temporary accounts, GlobalBlocking

Aug 25 2023

Vermont added a comment to T341414: Allow community without extended rights to help with CN banner translations going 'live'.

Step 1-7 is needed to navigate to the translations starting from the Admin panel, I think to remember this specific section of the interface is visible for all, just not every user has access to change anything (read-only, as to say). Vermont is referring to step 8 in the process in their comment.

Yes, but you don't need to do all 7 steps every time you want to check on a banner you're supporting. When you setup a message group, you'll have a link to translate the message group, often to be included in the banner. From that link, click message group statistics, change which boxes are checked, and then there's the list of translations which you can then review and approve. Yes it's technically 8 steps in from just the search bar, but I'm not sure if there's any better way to navigate to message group stats for a specific message group besides through that chain of related pages. I'm certainly interested to know if there are thoughts on a better layout for these pages, though. My opposition to changing this is largely because, if we do get any development time (volunteer or staff) put towards this problem, there are more pressing things to work on. It's not great, but it's usable.

Aug 25 2023, 4:24 PM · MediaWiki-extensions-Translate, MediaWiki-extensions-CentralNotice, Wikimedia-Fundraising

Aug 23 2023

Vermont added a comment to T341414: Allow community without extended rights to help with CN banner translations going 'live'.

I think that there are four distinct and actionable tasks here:

  • Encourage the use of plain wikitext instead of HTML by default in banners

I'm a bit confused here; I don't think I've seen anyone including html markup in a banner translation unit. Generally, if there's a line of text, we'll just put a localizable message there, and then add the translations through the Translate extension. Because there's rarely differing formatting within a line, it's just one plain text line inside a <p> tag. Additionally, CN banners are not parsed as wikitext, it's just HTML.

  • Make the interface for approving banner translations simpler and more intuitive

I'm also confused on this point. Approving translations are as simple as opening the drop-down (on the review page) and then clicking "publish" for each translation.

  • Allow translation administrators to approve banner translations
  • Provide banner requesters with temporary, limited translation adminship (similar to limited adminship)

These two should be relatively easy to implement, depending on how the CN and Translate extensions bundle actions into their relevant userrights. Once the former is done, the latter is just a matter of a Meta-Wiki RfC, if we think that's even necessary.

Aug 23 2023, 4:04 PM · MediaWiki-extensions-Translate, MediaWiki-extensions-CentralNotice, Wikimedia-Fundraising

Aug 22 2023

Vermont added a comment to T341414: Allow community without extended rights to help with CN banner translations going 'live'.

The idea of allowing any two users to approve translations for CN banners is not a workable idea. This would make global CN banners incredibly susceptible to vandalism on a global scale, and far less protected than any random translatable page.

Aug 22 2023, 5:52 PM · MediaWiki-extensions-Translate, MediaWiki-extensions-CentralNotice, Wikimedia-Fundraising

Aug 18 2023

Vermont added a comment to T340275: Allow GlobalBlocking to block temporary accounts.

To maintain current capabilities, we would need to be able to set global blocks that only apply to temporary accounts (curently soft blocks), and global blocks which also apply to logged-in users (hard blocks).

Aug 18 2023, 6:49 PM · Temporary accounts, GlobalBlocking

Aug 11 2023

Restricted Application added a project to T17294: Allow blocking of global accounts: MediaWiki-Platform-Team.
Aug 11 2023, 6:27 PM · Temporary accounts, MediaWiki-Platform-Team, MediaWiki-Blocks, Goal, Epic, Stewards-and-global-tools, GlobalBlocking
Restricted Application added a project to T19929: CentralAuth account locks should trigger global autoblocks: MediaWiki-Platform-Team.
Aug 11 2023, 6:22 PM · MediaWiki-Platform-Team (Radar), GlobalBlocking, Stewards-and-global-tools, MediaWiki-extensions-CentralAuth

Aug 1 2023

Vermont added a comment to T309328: IP range-blocks should not block trusted logged-in users (autopatrolled, bot, bureaucrat, checkuser, interface-admin, steward).

I gave this ticket a more thorough read, and there are some points I would like to clarify.

Aug 1 2023, 8:25 PM · User-Frostly, Community-consensus-needed, MediaWiki-Blocks
Vermont added a comment to T309328: IP range-blocks should not block trusted logged-in users (autopatrolled, bot, bureaucrat, checkuser, interface-admin, steward).

Premising that, as far as I understand, the community of CheckUsers very much like the current "bug" that "blocks everyone in the damn planet including registered users, including autopatrolleds, including ...". So, while the situation could be improved (that is not acceptable honestly to me as-is) as compromise we should think about how to still give to our dear CheckUsers the ability to monitor the situation of registered users (so, CU should be able to "spy" whatever sysop that is exiting from non-predictive Internet nodes like "open proxies", for whatever is their weird legitimate investigative reason to explain such invasive eye on trusted "coworkers"...)

Aug 1 2023, 1:09 PM · User-Frostly, Community-consensus-needed, MediaWiki-Blocks

Jul 21 2022

Vermont added a comment to T313446: Make non-CUs linking users and IPs when CUs use block forms in CheckUser harder.

Perhaps that could be formalized, with a little help from the software. Imagine a work flow like this:

Jul 21 2022, 12:55 PM · Trust and Safety Product Sprint (Sprint Tabla (1st - 14th April)), Trust and Safety Product Team, CheckUser, Epic

May 18 2020

Aklapper renamed Vermont from Adotchar to Vermont.
May 18 2020, 1:55 PM
Vermont created T253019: Change username from Adotchar to Vermont.
May 18 2020, 1:52 PM · Phabricator

May 14 2020

Vermont added a comment to T189717: Better handle block reasons on mobile (specifically templates and HTML comments).

It appears that the many users affected by T-Mobile range blocks, which of course will (for the most part) only affect mobile devices, are not able to see any of the helpful templates intended to be viewed in the block notice on mobile, because of this issue.

May 14 2020, 11:32 PM · Epic, MediaWiki-Blocks, Web-Team-Backlog (Tracking), Anti-Harassment, MobileFrontend

Jan 28 2020

Vermont reopened T242291: Since early January 2020, no feed available for the Copy Patrol tool as "Open".

It hasn't worked for the Spanish Wikipedia's CopyPatrol since the 4th of January, it seems. Same with the French version.

Jan 28 2020, 12:10 AM · CopyPatrol, Community-Tech

Jan 3 2019

Vermont added a comment to T212268: Make the abusefilter-blocker user not be a sysop.

Another complaint about this account at https://meta.wikimedia.org/wiki/Talk:Steward_requests/Permissions#Strange_administrator_wikiquote:de:user:Missbrauchsfilter

Jan 3 2019, 3:12 PM · Patch-Needs-Improvement, AbuseFilter (Overhaul-2020)

Dec 10 2018

Vermont renamed T211532: users with oathauth-enable access via global groups are unable to enroll in two factor authentication from users with oathauth-enable access via global groups are unable to entroll in two factor authentication to users with oathauth-enable access via global groups are unable to enroll in two factor authentication.
Dec 10 2018, 2:49 PM · MediaWiki-extensions-OATHAuth

Nov 30 2018

Vermont created T210840: Simple English not shown in “Languages” section of pages for interwiki linking.
Nov 30 2018, 2:29 PM · Language-Team (Language-2019-April-June), UniversalLanguageSelector, ULS-CompactLinks, Wikimedia-Interwiki-links

Nov 27 2018

Vermont added a comment to T150826: Remove unblockself right on wikimedia wikis (but allow blocked admins to block their blocker).

There's discussion on enwiki about also having a rate limit on blocking users. Seems like a reasonable enough idea, but we'd want it high, as we really only want it in cases of truly malicious users.

Nov 27 2018, 7:17 PM · User-notice-archive, MW-1.33-notes (1.33.0-wmf.8; 2018-12-11), MediaWiki-User-management, Community-consensus-needed, Wikimedia-Site-requests
Vermont added a comment to T150826: Remove unblockself right on wikimedia wikis (but allow blocked admins to block their blocker).

I believe this should be handled by a meta RfC rather than discussion at the enwiki Village Pump and a Phab ticket. (Unless, of course, the WMF wants to act on it immediately as a security issue)

Nov 27 2018, 4:17 PM · User-notice-archive, MW-1.33-notes (1.33.0-wmf.8; 2018-12-11), MediaWiki-User-management, Community-consensus-needed, Wikimedia-Site-requests

Jan 18 2018

Vermont added a comment to T181848: Experiment with using English Wikipedia models on Simple English.

Oh this is done. It has been reviewed by @Adotchar

@Halfak @Adotchar can either of you confirm that this task can be closed? I remember some confusion on IRC when Aaron's comment went through. I would assume that experimentation would have to be done on the beta cluster, which doesn't have the models enabled yet, so unsure how this task would be completed. I'll update the task description per my understanding, please edit if I'm off-base.

Jan 18 2018, 7:49 PM · MW-1.31-release-notes (WMF-deploy-2018-01-02 (1.31.0-wmf.15)), Patch-For-Review, Machine-Learning-Team (Active Tasks), Bad-Words-Detection-System, revscoring, artificial-intelligence

Dec 2 2017

Vermont added a comment to T181848: Experiment with using English Wikipedia models on Simple English.

OK so here's what I suggest you do.

  1. Disable the new recent changes filters in your preferences.
  2. Edit your "/common.js" to look like mine: https://simple.wikipedia.org/wiki/User:EpochFail/common.js
  3. Go back to Special:RecentChanges and wait a little bit. ORES should highlight changes that are likely to be damaging.
  4. Tell us how it goes!

I did a little bit of testing and I was able to catch some damaging edits :)

Dec 2 2017, 10:52 PM · MW-1.31-release-notes (WMF-deploy-2018-01-02 (1.31.0-wmf.15)), Patch-For-Review, Machine-Learning-Team (Active Tasks), Bad-Words-Detection-System, revscoring, artificial-intelligence
Vermont closed T181849: Edit quality campaign for simple.wikipedia.org as Resolved.
Dec 2 2017, 5:32 PM · Machine-Learning-Team (Active Tasks), editquality-modeling, Wikilabels, artificial-intelligence

Dec 1 2017

Vermont created T181849: Edit quality campaign for simple.wikipedia.org.
Dec 1 2017, 8:23 PM · Machine-Learning-Team (Active Tasks), editquality-modeling, Wikilabels, artificial-intelligence
Vermont placed T181848: Experiment with using English Wikipedia models on Simple English up for grabs.
Dec 1 2017, 8:20 PM · MW-1.31-release-notes (WMF-deploy-2018-01-02 (1.31.0-wmf.15)), Patch-For-Review, Machine-Learning-Team (Active Tasks), Bad-Words-Detection-System, revscoring, artificial-intelligence
Vermont created T181848: Experiment with using English Wikipedia models on Simple English.
Dec 1 2017, 8:19 PM · MW-1.31-release-notes (WMF-deploy-2018-01-02 (1.31.0-wmf.15)), Patch-For-Review, Machine-Learning-Team (Active Tasks), Bad-Words-Detection-System, revscoring, artificial-intelligence