Project:Village Pump

About this board

This page is only for discussing issues related to MediaWiki.org site.
To get help with MediaWiki software, ask on Project:Support desk.
 
Jingxingtv (talkcontribs)
Ciencia Al Poder (talkcontribs)

Can you actually understand what the message says?

Reply to "new activity"

Propose restricting editing flow topic titles to autoconfirmed users

15
Summary by P858snake
Bawolff (talkcontribs)

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?

P858snake (talkcontribs)

Support

Dinoguy1000 (talkcontribs)

+1

Ammarpad (talkcontribs)

Support. Sysop only is fine too.

Clump (talkcontribs)

+++support

Jdforrester (WMF) (talkcontribs)

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?

Bawolff (talkcontribs)

The ux code seemed to already exist. They just no longer have it as a choice in the menu.

Flounder ceo (talkcontribs)

Oppose. This wiki is already difficult to edit. Why do we have Flow?

Bawolff (talkcontribs)

@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?

Flounder ceo (talkcontribs)

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.

Mainframe98 (talkcontribs)

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.

Ciencia Al Poder (talkcontribs)

Strong support!

Pppery (talkcontribs)

Support

Bawolff (talkcontribs)

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.

Bawolff (talkcontribs)

Yes Done

Reporting vandal/problematic translation

1
Summary by Mainframe98

Seemingly already done

~aanzx (talkcontribs)
AxG (talkcontribs)
Jdforrester (WMF) (talkcontribs)

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?

AxG (talkcontribs)

The SVG appears oddly on Firefox, but not on Chrome, but the SVG itself is poorly drawn in the first place.

Jdforrester (WMF) (talkcontribs)
Reply to "MediaWiki logo"

Interwiki prefix to link source files in MediaWiki core

5
Push-f (talkcontribs)

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!

Legoktm (talkcontribs)
Push-f (talkcontribs)

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?

Legoktm (talkcontribs)

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.

Push-f (talkcontribs)

New filters for recentchanges

2
Bawolff (talkcontribs)

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.

example with filters enabled

Dinoguy1000 (talkcontribs)

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.

Reply to "New filters for recentchanges"

Switching this wiki to use the new talk page tools?

21
Barkeep49 (talkcontribs)

Has there been any thought about using the new talk page tools (Talk pages project) on this wiki?

Legoktm (talkcontribs)
Whatamidoing (WMF) (talkcontribs)

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.

Barkeep49 (talkcontribs)

That really was my question and I appreciate the feedback.

Whatamidoing (WMF) (talkcontribs)

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.

MarcoAurelio (talkcontribs)

I support enabling DiscussionTools here, and moving away from Flow. Thanks.

Whatamidoing (WMF) (talkcontribs)

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.

Whatamidoing (WMF) (talkcontribs)
Ladsgroup (talkcontribs)

I also support enabling DiscussionTools here, and moving away from Flow. Thanks.

Taavi (talkcontribs)
Lectrician1 (talkcontribs)

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.

Ladsgroup (talkcontribs)

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)

Lectrician1 (talkcontribs)
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.

Barkeep49 (talkcontribs)

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.

Ciencia Al Poder (talkcontribs)

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.

CapnZapp (talkcontribs)

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)

Matma Rex (talkcontribs)

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.

Ladsgroup (talkcontribs)

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.

Barkeep49 (talkcontribs)

If that's technically possible yes that seems like a good compromise.

Pppery (talkcontribs)

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.

Pppery (talkcontribs)

Africa Wikimedia Technical Community/Project Scope

2
Summary last edited by Pppery 02:18, 7 January 2023 28 days ago

Page was moved by Taavi

Shirayuki (talkcontribs)
Ciencia Al Poder (talkcontribs)

Add "Support" namespace

4
Summary by Jdforrester (WMF)

This seems to be declined now.

Lectrician1 (talkcontribs)

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.

Ciencia Al Poder (talkcontribs)

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.

Dinoguy1000 (talkcontribs)

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).

Lectrician1 (talkcontribs)

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.

Summary by Jdforrester (WMF)

This is not the venue, you need to ask on Phabricator once you've got agreement on that thread.

Lectrician1 (talkcontribs)
Ciencia Al Poder (talkcontribs)

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.