This page is only for discussing issues related to MediaWiki.org site.
Archives
|
|---|
|
|
Lots of vandalism on this wiki is people editing flow topic title. Now that https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Flow/+/845771 has been merged, I am proposing that we restrict that to be autoconfirmed only (Personally I would also be fine with sysop only). This only affects editing other people's flow topics. You can still edit the titles of posts you create yourself.
Thoughts?
What does the UX look like with your patch? I don't see any JS-land code, so presumably non-autoconfirmed users will be given an edit button that just doesn't work?
The ux code seemed to already exist. They just no longer have it as a choice in the menu.
@Flounder ceo: Well I'm not opposed to killing flow, can we have that in a separate discussion?
As far as making the wiki more difficult to edit, can you point to any examples of such edits that this would block that are good edits?
On general principle it is good for wikis to be editable. It doesn't really encourage participation when new users run into roadblocks. But maybe there is a ton of vandalism I'm not seeing.
Support Flow makes reverting topic titles a pain. Preventing that would go a long way.
Having that said, I'd prefer Extension:DiscussionTools. Thankfully, this is already partly in progress, see Topic:Wvqji3vfu2j1na7g and phab:T325907.
This seems pretty snowball, so I made https://phabricator.wikimedia.org/T328097 and am making a patch. Of course nothing is going to happen until Monday at the earliest so discussion can continue if need be.
Seemingly already done
The main MediaWiki logo used on the Vector 2022 needs a tweak to the right leg of the 'M' to make the line straight, as I can see a slight gradient when one is not needed. See: File:MediaWiki wordmark in Vector 2022 with gradient.png
I think that's a rendering artefact of your browser? That's a plain SVG file (mediawikiwiki-wordmark.svg) which your browser is rendering oddly, perhaps?
The SVG appears oddly on Firefox, but not on Chrome, but the SVG itself is poorly drawn in the first place.
The current SVG file dates from https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/668241 when it was provided (as a reduced copy of File:MediaWiki-2020-wordmark.svg which is just word->path of the site name) as part of the switch to the new logo; before that we just fell back to the browser printing the site name in text. I'm not sure I see you think needs fixing?
I am working on a client library for the MediaWiki action API and would like to always link the source code of the respective PHP class, so for example:
# https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/master/includes/api/ApiParamInfo.php
However I would like these links to be less verbose and future proof in the case the code is migrated from Gerrit to GitLab in the future, so I would ask an administrator of this wiki to please create a core interwiki prefix at Special:Interwiki/add with the Forward flag enabled and the URL https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/master$1, so that I could link PHP classes within MediaWiki core as follows:
# https://mediawiki.org/wiki/core:/includes/api/ApiParamInfo.php
Thank you!
I think it's much more common that the class will be renamed or moved in the Git repository than how often we switch Git providers, so I'm not really sure there's a good way to link to a specific API class's source that will be super future-proof.
FWIW https://www.mediawiki.org/wiki/git:mediawiki/core/+/refs/heads/master/includes/api/ApiParamInfo.php works I guess.
The classes in includes/api/ are renamed only very seldomly, e.g. ApiParamInfo.php has been named that way since it was created in 2008, which is now nearly 15 years ago.
I am well aware that these links will break if the file is renamed but there's really no way around that ... I just want URLs that are more readable and web frontend agnostic ... so can you create that interwiki prefix for me?
It'll be renamed as part of T166010 (specifically the api folder to Api). I think it's more likely that we'll set up redirects from Gerrit URLs to GitLab ones, like we did when the GitBlit viewer was shut down, and with Special:CodeReview URLs.
In any case, I can't add the interwiki prefix, on Wikimedia wikis they're managed centrally, see m:Interwiki map.
Oh I just discovered that
is also available at
https://gerrit.wikimedia.org/g/mediawiki/core/%2B/master/includes/api/ApiParamInfo.php
That's good enough for me. Thanks for your insights :)
I hope this isn't too offtopic.
Special:Recentchanges now supports 2 new filters - hiding the new user log and hiding translation subpages. I've found them really useful on this wiki in particular where RC is can be super overcrowded. You can set as default with the little bookmark icon on the right hand side. Thought i'd mention it in case it is useful to others.
If you're taking suggestions at all, I keep wanting a way to explicitly hide options on RC; currently, to do this you have to explicitly show all the options in the same category except for the one(s) you want to hide, e.g. if you don't want to show autopatrolled edits, currently you have to explicitly show unpatrolled and manually patrolled edits.
Has there been any thought about using the new talk page tools (Talk pages project) on this wiki?
Kind of - see Topic:Wq5fsfui1dlcxvk4. I don't know/remember what the outcome of that discussion was though, @Whatamidoing (WMF)?
The [reply] tool is on by default for all wikitext-based talk pages. I've asked the Editing team in the past to turn on the DiscussionTools Beta Feature by default.
Is your real question closer to "Has there been any thought about making wikitext be the default page model for talk pages on this wiki?" I don't think I would recommend that until we know whether automatic topic subscriptions (the [subscribe] button) is a good thing to enable by default for all users.
The page model was originally switched to Flow because the admins kept getting so many requests for "one-off" changes to new pages. It proved to be less work to change the default and freely grant one-off changes back to wikitext (ask any admin you know, or start a thread here whenever you want; if the page doesn't already exist, it's not considered a big deal, and Flow-to-wikitext conversions are possible).
Editing's planning an A/B test for Talk pages project/Notifications. It will hopefully emerge from instrumentation purgatory at the end of this month, run for about a month, and spend another month while the analyst figures out what happened. Depending on the results, the Editing team will make a recommendation. My guess (but data rules) is that they'll suggest enabling automatic subscriptions for newbies and manual subscriptions for old hands. My second guess is automatic for everyone, but with a highly visible opt-out button, which would have to be built. (Also, by this point, it'll be August, which means Wikimania, and nothing else will happen for weeks.)
On the assumption that the local community would first want to have this information plus (assuming the results are favorable) have the [subscribe] button deployed, I think the very earliest that people would want to talk about any changes would be September (October or even November being more realistic, since everything takes longer than it should).
As for the Editing team's role: They'll provide information and recommendations to all WMF wikis, but they weren't consulted on the switch to Flow in the past, and I don't think they expect to be consulted on any switch away from Flow in the future.
I support enabling DiscussionTools here, and moving away from Flow. Thanks.
Update: The devs have accepted my proposal to enable DiscussionTools here, by default, for everyone. This will happen on Wednesday, when they have a backport window reserved for some other things anyway.
I believe the goal is that phab:T311456 will add to previous deployments to end up with the result that everyone has everything by default, and that logged-in users can turn off any pieces they don't want in Special:Preferences#mw-prefsection-editing-discussion. If there are problems, of course, please let me know.
Please have a look at User talk:Whatamidoing (WMF), which is showing the latest (but not final) version.
I also support enabling DiscussionTools here, and moving away from Flow. Thanks.
Why would we do this? Structured Discussions is much easier for newcomers to use than DiscussionTools, especially on this wiki where most people are new and are coming here looking for support for their wiki... You also can also easily edit your responses in Structured Discussions compared to DiscussionTools.
I respectfully disagree, Flow has much more issues than DT. For example search practically doesn't work in flow so you can't really search for old questions (at least last time I checked). DT is also much more newcomer friendly once the new design for DIP gets deployed. I agree editing your response is a good idea to have but it doesn't mean it won't be there in near future. Also flow is a maintenance nightmare. e.g. my bot can't properly do any archive of even non-flow pages because it can't create new archive pages and I have to manually create them (e.g. Talk:Reading/Web/Desktop Improvements/Archive9)
For example search practically doesn't work in flow so you can't really search for old questions (at least last time I checked).
For most questions I've personally had regarding MediaWiki, I always use Google to look them up, never the wiki. That way I can get results from Flow posts on this wiki or Stack Overflow. Searching the wiki sucks outright even if we're using DiscussionTools. Search engines are able to index Flow perfectly and I'd guess that's where most others do their initial searching of questions as well.
DT is also much more newcomer friendly once the new design for DIP gets deployed.
Still not as newcomer friendly in other regards though. New topics in Flow are posted at the beginning of the page, the new topic creator is clearly at the top of the page and not a small "Add topic" button in the upper right, users aren't confused what happens to their topic when it becomes "archived", and you can easily mark the topic as resolved.
Why should we remove the opportunity for users to use these features when we don't need to? Until DiscussionTools has these features and more, then that's when we should consider switching systems. We shouldn't go through the work of switching systems right now when there's no net benefit of doing so.
This isn't some "newcomer" wiki. The people you're describing are ambitious enough technically that they can setup their own mediawiki but easily confused enough that they can't use Discussion Tools which has had fairly extensive user experience testing? I'm sure that's a real person who exists but I also don't know that mediawiki needs to be organized around them rather than other types of people who use this wiki. And it does things that would be confusing for newcomers too. For instance if hit reply to your message @Lectrician1. But it doesn't thread in a way that someone with forum or reddit experience would expect.
I think Project:Support desk actually benefits from having Flow enabled, since it's a pretty busy discussion page.
However, all other spaces probably should default to the new talk page tools.
My opinion: StructuredDiscussions is markedly inferior to the previous ("classic") system: imposing a lot of bloat I care little for. I am neutral towards DiscussionTools, but I guess it has the advantage of not being StructuredDiscussions. CapnZapp (talk) 16:42, 6 January 2023 (UTC)
It seems to me like this is a trade-off between making this wiki more accessible to third-party MediaWiki users (using Flow), and making it more accessible to other Wikimedia wiki users (using DT). Most of us are in that second group, so that's what we prefer, but one could reasonably prefer the other.
Maybe the answer is to make it easier to enable/disable Flow on individual pages. On the other hand, I'm sensing a desire to decommission Flow entirely, so that might be giving its fans false hope.
It seems the natural compromise here is to disable flow for default (at least for now) but keep newcomer facing page as flow boards. It makes sense a newcomer might want to discuss something in Project:Support desk and flow would be useful but if that person wants to discuss something like advanced linter error issues, I assume they at least know how to use a talk page.
Agreed that switching Flow off by default while leaving it enabled on some specific pages is a reasonable solution, and appears to be technically possible.
Page was moved by Taavi
Rename African Wikimedia Technical Community/Project Scope to Africa Wikimedia Technical Community/Project Scope per the base page's rename.
This seems to be declined now.
I think we should add a secondary talk page to every software page called "Support". It would be a link to the right of "Discussion" to a page of the same name in the "Support" namespace".
Currently we point users to Project:Support desk for all types of support questions related to MediaWiki. This has the downside that not everyone adds Project:Support desk on their watchlist and therefore, if a question comes up that those who look at Project:Support desk do not know how to answer, then it may not be answered.
By providing a "Support" talk namespace for every software page, users who are familiar with a topic would be able to put that page on their watchlist and give support for that particular topic they have knowledge about. This will mean questions users have will be answered more-often.
Note that watching the Extension: or Skin: page would not automatically watch the "associated" page in the Support: namespace.
While viewing related support questions would be good, I don't think your proposal would be a big improvement. It would be easier to allow support questions on the talk page itself.
Many extension/skin talk pages are already used as support pages; I don't see the point to introducing a whole new namespace versus just continuing to encourage talk page use in this way. In addition, fragmenting Project:Support desk in this way just makes it harder to keep track of discussions you might be able to comment on, since it increases the number of places you need to watch (this is already true of talk pages as well, but at least there you don't have to go out of your way to watchlist another page beyond the extension or skin page itself).
I agree that doing this would be burdensome to implement when we could just use the talk page. I've created a separate topic proposing that we allow using the talk page.
This is not the venue, you need to ask on Phabricator once you've got agreement on that thread.
Could an administrator please move Gerrit/Tutorial to Gerrit/Git tutorial and Gerrit/Tutorial/tl;dr to Gerrit/Git tutorial/tl;dr?
For explanation please see Topic:X9mxl87i9na7ppu9
As Shirayuki pointed out, the page can not be moved because it has a lot of subpages. It needs to be requested on phabricator, since only someone with command line access can perform the move.
Because adding a "Support" namespace would be too burdensome, could we remove all the usages of Template:Not a support forum and make it policy that talk pages can be allowed for software support?
I dont think all would be appropriate, but im fine with specific ones if someone is watching them (especially extensions). The biggest concern is individual talk pages might go unnoticed.
If a question goes unnoticed well then we can direct users to go to Project:Support desk.
Could we have a message at the top of talk pages that points users to the Support desk if their question isn't answered there?
You've just reinvented Template:Not a support forum, with weaker wording.
I don't see why we need to relax things across the whole wiki. If an individual extension's maintainers want to use the extension's talk page as their support channel, that's their choice.
I agree with @Dinoguy1000. Not sure there's a need for a general change, but extension maintainers are already welcome to invite support requests there if they wish.
I think it's more natural to ask questions about a particular feature alongside that feature's page, but can see how some things might slip through the cracks.