User Details
- User Since
- Apr 9 2015, 4:16 PM (278 w, 2 d)
- Availability
- Available
- IRC Nick
- Sky2042
- LDAP User
- Unknown
- MediaWiki User
- Izno [ Global Accounts ]
Thu, Aug 6
So just for concrete example's sake (please rebut each as appropriate):
The double dash is kind of not in keeping with the style of the other selectors (in general as well as the classes on body). Can a quick followup be done to use one dash instead? Or some rationale provided for why two were used?
Ah yeah, ok. And I went and looked at the other task.
Wed, Aug 5
I don't think there's an easy way to link to action URIs?
{{fullurl:{{FULLPAGENAME}}|action=history}}
Slightly off-topic... (The handful of upgraders who have stopped in the MediaWiki Discord usually make smaller, jumps indeed, such as LTS to LTS.)
Fri, Jul 31
Wed, Jul 29
Tue, Jul 28
Mon, Jul 27
This one might be a good one to backport to 1.35...
Tue, Jul 21
Fri, Jul 17
Anyway, I think your request is declined T203967: TemplateStyles should allow for "mobile-only" styles and I think this should be declined accordingly.
Tue, Jul 14
Sun, Jul 12
This task doesn't strike me as actionable unless it points to specific places where there are "anonymous" users rather than "unregistered" users. Otherwise, it risks being an issue that the communities should solve rather than the MediaWiki developers.
Sat, Jul 11
Be cognizant of "blocklist" discussion from T254646#6199977 and surrounding and consider whether that word is preferable to 'disabled' or similar other words identified there and other patches down the way.
Jul 9 2020
Jul 8 2020
The general direction or concern has been that someone will have to deal with presumed private communications that turn or start abusive. The number of admins on hand might be sufficient to do so but are not generally vetted for handling concerns of privacy. Meanwhile the set of users who are vetted are not sufficient in number to take that on. That leaves us taking at a person's word that what they have received is abuse if we want to have a chance to deal with it.
I found a declined ancient task for this at T11062: [Request] Private Message System as well as the MediaWikiChat .
Jul 5 2020
Even if valid, user was shortly blocked after for socking (CU-confirmed).
The side note is not-quite T202921: Re-design the Editing preferences to make it easier to pick the editing environment that you want to use, but that might be interesting.
You will need to fix this on the wiki. This is not a problem in the software.
Jun 29 2020
Just as an FYI, another instance I think can be chalked up to this one is here.
Jun 25 2020
Jun 24 2020
I would personally like if it were easier to target mobile-friendly skins like Minerva and Timeless with one selector rather than two in TemplateStyles, so a body.skin-mobile-friendly might be nice, or something like that. See also Main page template styles. I don't think that's what PC is looking for, but would still make my life easier. :)
Kind of illuminating that it might be a good idea to have a separate Default selection (which defaults to whatever the default deployed skin is for the wiki) as well as Vector (extend for N additional new default deployed skins).
I'll note that my response, as with this thread, is offtopic to this task (the corrector one is above, of course). However, the discussion started here...
Jun 22 2020
Yeah, I'm fairly certain it's that one. Please feel free to reopen if it does not work right now, since the change above went live a few hours ago, after the above reports.
Jun 21 2020
This task might be interesting again in the case of multi-content revisions, as on Commons and potentially elsewhere.
Jun 20 2020
Jun 19 2020
Yeah, I think this is a reasonable close (and Krinkle edit-conflicted my decline 😃 ). I will respond to one specific requested actionable: T231161: Add in/not in content namespace to Special:Linterrors is a request to make it easy to tell what needs to be fixed in a content namespace. Consider subscribing/following.
The other way this could be fixed is by using a similar UI as Special:Search or Special:Watchlist, which allows selection of arbitrary namespaces.
Jun 15 2020
Never mind, made T255499: Make input forms more responsive since OOUI can be messy.
Ignoring earlier comment, maybe a way to get this implemented would be for the edit toolbars or a piece of user Javascript to provide a "reverse sort button" which does the heavy lifting of actually reverse sorting the table in the wikitext on the particular column.
Jun 14 2020
Is this the right task to ask for a more responsive inputbox? On Minerva on small width the form forces an embedded scrolling element and on Timeless the whole page overflows because of a larger form.
Jun 12 2020
Please consider using a different task for implementation then. This one requested all linter errors. The implementation the discussion tools work resolved to does not include all errors, AIUI (per T248632: Implement new signature requirements). All linter errors includes some things that were deliberately excluded in the other task, including obsolete elements and font color mismatch as examples.
Jun 9 2020
Jun 8 2020
Dragging my comment over from the parent:
Jun 7 2020
The issue seemingly to be identified with "blocklist" is that it can trivially be confused with the block log and other user block related concepts, specific to MediaWiki. There is an unfortunate (English) semantic partial-overlap.
I think generally the rule has utility (please don't use overqualified selectors, for the same reasons the lint was originally added), so I don't think the generalization of the task to removing "is overqualified" is reasonable.
Jun 5 2020
The sidebar order was changed today. See https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/2020_left_sidebar_update . If you would prefer another implementation of that task, you will need to consult on your local wiki. I think this task should be rejected.
Jun 2 2020
May 30 2020
That would be T140606: Check user signature for linter errors, which is in the parent task chain.
May 24 2020
May 23 2020
May 19 2020
Kind of curious to know why <article> isn't in the list. Seems like an obvious inclusion. :)
I do not think this fits the UBN description, especially based on the lack of obvious action.