ArchWiki talk:Maintenance Team

Note This talk page is not reserved to wiki maintainers: any user can write here to contact the team about organization or administration issues not related to a specific article.

Reorganization

The Maintenance Team was officially launched 3years-2weeks ago, and has since become an indispensable resource for the wiki, vastly improving the effectiveness of wiki maintenance, and also proving to be a fantastic ground for training new future administrators.

However, even things that work well can be further improved, and through time I've collected several ideas that I'd like to outline here:

1. I'd like to rename the "Maintainers" group as a more commonly recognized "Moderators".
2. ✓ This page would stay with this title, and the "Maintenance Team" would represent the team made by admininstrators and moderators, serving as the central page where to organize the collaboration workflow.
3. ✓ We should use this very talk page as the best place to point users to for generic questions, complaints etc., instead of ArchWiki talk:Administrators (e.g. update the link in ArchWiki:Contributing#Complaining).
4. ✓ I'd like to deprecate ArchWiki:Reports, and just invite to report issues directly in the affected articles' talk pages, possibly also adding proper status templates where useful. I don't know if we should keep the Reports page as an additional page where to also report urgent problems, what I've seen is that almost each of us has his own methods for keeping track of discussions, and the "Recent talks" page in the left column is quite efficient at signalling new issues for those who don't follow the full recent changes.
   Historically, ArchWiki:Reports was created because there wasn't anybody doing a systematic patrolling of the changes, even if only limited to talk pages, but in modern days this seems to have improved, so this can be another argument in favor of its deprecation.
   Maintainers who add entries to the table manually wouldn't be too much affected, since it takes the same effort to add an entry to a table or add a quick report to a generic talk page. Those who instead are using Wiki Monkey to add quick reports to the table, will of course see a difference, but I will commit myself to modifying the plugin so that it can insert reports in the article's talk page, probably with an explicit message stating that the report has been created automatically.
5. Note mostly to myself, Wiki Monkey has some feature requests that are related to this restructuring: #175, #176, #197 and #198.
6. ✓ The ArchWiki:Maintenance_Team#Current_patrols list can be deprecated, since it hasn't helped improving the number of full-range patrols, also apparently ending up including inactive members.
7. ✓ ArchWiki:Maintenance_Team#Statistics was useful to track the evolution of the initial 146 reports, but now I think it's useless and can be deprecated together with ArchWiki:Reports.

Opinions needed. — Kynikos (talk) 09:11, 6 May 2015 (UTC)

Point 1) Sounds good to me.

Point 2) Agreed.

Point 3) I think that's a good idea. In so doing, that would ensure that the admin talk page is freed up for purely administrative discussions.

Point 4) Personally, I agree with the removal of the reports page. The people who are most likely to be able to fix issues for a particular article are probably the people who keep track of that article's talk page. I don't think that trying to centralize issue reporting achieves much.

Points 6 & 7) Agreed

-- Chazza (talk) 10:11, 7 May 2015 (UTC)

1,2,3. Also agree, this matches the BBS title "Forum Moderator". We could perhaps ask Jason to update the profiles of maintainers with a BBS account

4,7. I'm neutral on this... I think having ArchWiki:Reports as a central place for edits offers a better overview than WhatLinksHere, Recent Talks, and whatnot, also considering the table format. But perhaps I'm just lazy. :)

6. Yep, and not including active members as well. -- Alad (talk) 19:10, 7 May 2015 (UTC)

Also agreed. W.r.t 4 & 7, we might also try to generate some lists/tables based on the status templates and make a nice, sorted, filtered and ranked report e.g. once per month. Extracting the original flag date would be probably difficult, but perhaps not impossible.

Is it also the time to consider ArchWiki_talk:Administrators#Meaning_of_Administrator at this point?

-- Lahwaacz (talk) 19:27, 7 May 2015 (UTC)

About 1, I'm adding that it has to be done in 3 steps: create the moderators group, then move each maintainer to moderator, and finally delete the maintainers group.

Of course point 4 is the most controversial, replacing it with some kind of fully automated log/report would be ideal, but IMO it can be implemented later on. @Alad: I understand your concerns, but the benefits of always reporting directly in the articles' talk pages are quite clear now that talk pages seem to be much more watched than they were in the past (also thanks to the fact that IIRC finally MediaWiki is adding modified/created pages to watchlists by default for new users), and if we start doing that, keeping ArchWiki:Reports would mean having to do at least two edits for each report (or three if a status template is added), so that's why I proposed deprecating it; as I said, I will try to update Wiki Monkey to automate the new reporting procedure as much as possible, and I guess I could still have it append entries to ArchWiki:Reports too, but the problem would be keeping the table in sync with the linked reports in the talk pages... I'll think about it.

ArchWiki_talk:Administrators#Meaning_of_Administrator could surely be implemented in this article, it's very related indeed.

— Kynikos (talk) 14:21, 8 May 2015 (UTC)

I'm ok with everything, but +1 to keep (4) the reports. There is no question that you are right, items should be handled in the respective article's talk pages - the sooner, the better. Yet, I believe this is done anyway by all and the current reports are only a residual. I find it valuable to keep this as an opportunity (also for the visible quicklink), at least for some time. Reason: Imagine someone patrols a problematic in recent changes but the article is outside the own interest/ expertise and/or time to open a proper talk item (which would often be more elaborate than the report comment) is sparse. It would be a pity, if it is foregone or tracked in the backhead todo list only.

How about doing it like you propose, but changing procedure for the reports that may still be opened: They could be moved directly by anyone (incl. the creator on return) to the respective talk pages. If we then see the list stays tiny, it can be fully deprecated. --Indigo (talk) 19:07, 10 May 2015 (UTC)

My idea (which I hadn't eleaborated yet here) was to allow the creation of quick reports (also automated with Wiki Monkey) in articles' talk pages similar to the current entries in ArchWiki:Reports' table, probably also using a template to stress the fact that the comment has been added quickly and the reporter may only be confused about the edit and in need for confirmation. I'll use an existing report from ArchWiki:Reports as an example of how it could look instead in the affected article's talk page:

Quick report

[This is an automatic report about https://wiki.archlinux.org/index.php?title=PhpPgAdmin&curid=11293&diff=346886&oldid=345943, please help reviewing it]

Comment: I'm not qualified to check the content, but style is poor regardless. -- User, Timestamp

The whole thing could be manually added simply with:

{{Report|https://wiki.archlinux.org/index.php?title=PhpPgAdmin&curid=11293&diff=346886&oldid=345943|I'm not qualified to check the content, but style is poor regardless.}} -- ~~~~

The link to ArchWiki:Reports (the "report" anchor text) could be useful to list all the open reports with a search like https://wiki.archlinux.org/index.php?title=Special%3AWhatLinksHere&target=ArchWiki%3AReports&namespace=1 since it's unlikely that Talk pages link there for other reasons.

If using Wiki Monkey, more details could be added automatically, e.g. the timestamp and author(s) of the edit(s), Special:Diff could be used instead of the full link, and it could create the report in full text (i.e. like using the template with subst).

— Kynikos (talk) 10:54, 11 May 2015 (UTC)

Now in this case I'd like to nominate "(4) to deprecate Archwiki:Reports" for the Archwiki Understatement of the Year(TM) category. No, really - ace idea. That would be an ingenious enhancement imo. --Indigo (talk) 21:48, 11 May 2015 (UTC)

Yeah sorry, my original idea was still very vague, replying to your post has given me the chance to develop it into something that could actually work, although it would still need some refinement. I'm glad you like it, hoping that you weren't sarcastic of course :P Maybe we can see what the others think of it too, since I'm sure you're not the only one who didn't imagine that (4) was about something like that... — Kynikos (talk) 15:55, 12 May 2015 (UTC)

For the moment I've done points 6 and 7. — Kynikos (talk) 03:43, 24 May 2015 (UTC)

I think you got it, but of course it was not sarcasm, just trying to make a funny remark. Your idea with the quick report is great lateral thinking. One small reservation I have is about using a Template for it. We all know the hazzle of template breaking characters and I wonder if it might be cumbersome to use a template, but that can be seen. In any case it should be useful to get forward with a decision on where to go with the reports. Anyone else want to share an opinion on (4)? --Indigo (talk) 20:14, 29 July 2015 (UTC)

Eheh I got it I got it, thanks for confirming your support. I think the quick report would only be for short messages, like those in ArchWiki:Reports' table, which are probably even worse when it comes to breakability, so unsupported characters wouldn't be an added problem. I suppose that if somebody wants to reply to a new-style quick report, they can do it below (i.e. outside of) the template, like in a normal discussion.

I don't think we'll find many more people interested in replying, anyway I'm waiting to find some time to update Wiki Monkey's plugin, that's probably my main reason for delaying (4).

To complete the status update, (5) will come with (4), while (2) and (3) practically depend on (1), which in turn is on the shoulders of who is currently maintaining the back-end, even though it's a micro patch.

— Kynikos (talk) 20:54, 11 August 2015 (UTC)

Even if the WikiMonkey additions aren't completed yet, I'd now suggest to deprecate ArchWiki:Reports rather sooner than later. Over the course of the year, it has hardly seen any usage, and old reports which are long fixed amassed on the page. -- Alad (talk) 12:49, 13 September 2016 (UTC)

I'm still on with this plan. About Wiki Monkey (and my other software projects) I should be able to resume allocating some time within a couple of weeks, without promising anything, but yes, I don't want it to be a blocker for this idea. — Kynikos (talk) 10:51, 14 September 2016 (UTC)

I've flagged the page for archiving for now [1]; it should be straightforward to translate the few remaining reports to article templates. We can do the actual redirect once WikiMonkey is updated -- take your time. :) -- Alad (talk) 11:40, 14 September 2016 (UTC)

I'd like to know if there's still consensus on 1?

If it were to be implemented, here's a list of things to do:

1. Replace $wgGroupPermissions['maintainer'] = array(); with $wgGroupPermissions['moderator'] = array(); in LocalSettings.php and get it deployed.
2. Ask DevOps to run php maintenance/MigrateUserGroup.php 'maintainer' 'moderator'. See mw:Manual:migrateUserGroup.php.
3. Move MediaWiki:Grouppage-maintainer to MediaWiki:Grouppage-moderator.
4. Delete MediaWiki:Group-maintainer and MediaWiki:Group-maintainer-member.
5. Create MediaWiki:Group-moderator and MediaWiki:Group-moderator-member.
6. Update ArchWiki:Access levels and roles, ArchWiki:Maintenance Team and other pages.

-- nl6720 (talk) 06:26, 26 October 2021 (UTC)

Visual editor

[Moved from Help talk:Editing#Visual Editor. -- nl6720 (talk) 09:22, 23 September 2020 (UTC)]

Why isn't there any visual editor in ArchWiki, as in Wikipedia? -- FOSS ভক্ত (talk) 12:54, 18 September 2020 (UTC)

AFAIK no one has proposed adding a visual editor. -- nl6720 (talk) 13:28, 18 September 2020 (UTC)

Oh, I see. How to make a request? I'm talking about the editor of Wikipedia which contains both Visual Editor and Source Editor. -- FOSS ভক্ত (talk) 17:39, 23 September 2020 (UTC)

You already have :) And I gathered that you're talking about Extension:VisualEditor.

MediaWiki 1.35.0 will be released this week, so VisualEditor together with 2017 wikitext editor are a valid option to consider as the new default editor.

The concerns with VisualEditor is how will the wikitext turn out. We'd also need to create TemplateData for all templates. Looking at Wikipedia, adding templates is not at all intuitive if you don't know which template you need beforehand. But that's probably not that relevant since we have rules that govern wiki editing.

-- nl6720 (talk) 06:43, 24 September 2020 (UTC)

In the meantime I think the Extension:VisualEditor got quite some time to stabilize itself and maybe also to improve its generated wikitext. What would be needed in order to get support for said extension into archwiki? I would assume just LocalSetting.php needs changing as there are no additional deps to be installed since MediaWiki 1.35.0. Gromit (talk) 10:27, 28 March 2023 (UTC)

Also as discussed on IRC it also is possible to enable for some namespaces only (as per https://www.mediawiki.org/wiki/Extension:VisualEditor#Changing_active_namespaces), so a partial rollout and some practial testing would be possible.

-- Gromit (talk) 10:24, 27 July 2023 (UTC)

If the talk pages can serve as a testing ground, and it avoids us "wasting" our time with Template:Unsigned by also enabling DiscussionTools I'm for it. --Erus Iluvatar (talk) 10:31, 27 July 2023 (UTC)

Note that VisualEditor requires setting up Parsoid, which might be quite hard to configure properly. — Lahwaacz (talk) 06:40, 27 July 2023 (UTC)

Since Version 1.35 Extension:VisualEditor does not require parsoid anymore as the used things are now built into their own API.

-- Gromit (talk) 08:04, 27 July 2023 (UTC)

It still requires Parsoid, just not as a separate service. Parsoid#Installation says "If you are using a MediaWiki version newer than 1.35, explicitly loading Parsoid is required since August 24, 2020". I'm wondering if we need any further configuration or not. The documentation on VisualEditor is completely outdated, talking about 1.36-alpha as the newest version... — Lahwaacz (talk) 10:01, 27 July 2023 (UTC)

It might require parsoid in the background, but configuration is not a problem here. I have just confirmed with archlinux/archwiki (Mediawiki version 1.40) that adding wfLoadExtension( 'VisualEditor' ); is enough to get it working. You can have a look at the full LocalSettings.php here if you want to.

I'd also volunteer to take care of technial details if this is an addition we want.

-- Gromit (talk) 10:21, 27 July 2023 (UTC)

Then I guess their documentation is wrong or outdated... Thanks for testing it. — Lahwaacz (talk) 11:58, 27 July 2023 (UTC)

It seems to me like this discussion is somewhat stalled, as nobody is voicing any opinions anymore.. Additionally to some of the positive feedback above I still think this is a worthwhile topic to look into as every time I edit i.e. a table it's not much fun with the regular wiki editor. Generally the lack of visual editor keeps me from contributing more to the wiki.

As the pretty much the only concern seems to be that the generated wikitext is not up to standards I think we should do a trial run on some test namespace like the User Pages or the DeveloperWiki. -- Gromit (talk) 08:46, 16 June 2024 (UTC)

Sounds good to me, especially if you want to be the "guinea pig" in the DeveloperWiki namespace: that way we can see if the generated text is adequate or not :) Erus Iluvatar (talk) 09:36, 16 June 2024 (UTC)

It has been more than a year since my previous reply and Extension:VisualEditor only got better!

I'd like to propose to include it into the live Arch Wiki configuration and gather some real world data and experience whether it improves our community or creates a burden for the maintenance team. -- Gromit (talk) 18:00, 15 July 2025 (UTC)

From memory the single issue I saw from running the visual editor through Extension:DiscussionTools is that inline code gets translated to <code></code> instead of a Template:ic.

I have not tested if there's the same issue with Template:bc and Template:hc though.

Still a big thumbs up from me to make it more accessible for newcomer to add to the Wiki.

-- Erus Iluvatar (talk) 18:19, 15 July 2025 (UTC)

A 👎 from me. We are a technical community so the quality of the wikitext (as defined by our own style rules) matters. -- nl6720 (talk) 07:03, 16 July 2025 (UTC)

Does this mean that if there's a technical solution to be found so that the emitted wikitext for the code snippets uses Template:ic you would be on board with the change?

Also why is the above template superior from a style POV? -- Gromit (talk) 11:22, 21 July 2025 (UTC)

It's not just about Template:ic, but all our style conventions. The thing I particularly care about (for no apparent reason) is whitespace.

Think of the wikitext as the source code; even if no regular user reads it, it should still be look presentable for those who care (i.e. us).

-- nl6720 (talk) 12:48, 21 July 2025 (UTC)

But what exactly makes you convinced that there will be a load of problems with regards to wikitext style and maintainability once we enable the proposed extension?

While I agree that the style compliance of the "source code" within a project is an important topic to keep it in a maintainable state, it's even more important that there is something to maintain, which raises the necessity to find new paths to make our project an attractive project to contribute to.

I think lowering the barrier of entry would have exactly that effect, since there is not really any other context from which potential new contributors could already know the WikiText syntax (unlike markdown or other formats). Whether this change has a long-term effect on the maintainability of this knowledge base will need constant and careful evaluation, but I do not think it should serve as blocker for the change in the first place. -- Gromit (talk) 13:14, 21 July 2025 (UTC)

I can't really give you a good reason for why I'm negative about this. It just don't seem worth the effort to pursue something where there's no guarantee of a positive result. Everything, including what I wrote, so far is mostly just guesswork or gut feeling.

Another thing to consider is that, if no one learns the mediawiki syntax (no one actually likes it, so there's less chance people would learn it willingly), then where would we get fresh blood after the last batch of wiki maintainers die out‽

-- nl6720 (talk) 13:42, 21 July 2025 (UTC)

I've seen you made WikiEditor more compliant, maybe there is a chance to do something similar for VisualEditor?

In any case, I'll propose enabling VisualEditor for the User: namespace as a compromise: we would be able to test it better, it might already help some users to create drafts and we could easily disable it later if we really don't like it.

— Lahwaacz (talk) 19:40, 14 August 2025 (UTC)

I couldn't find a way to do the same for VisualEditor. It may be possible to execute an altered ve.ui.wikitextCommandRegistry.register, but I don't know how to trigger it at the right time. -- nl6720 (talk) 08:09, 15 August 2025 (UTC)

Enabling it for the User namespace sounds fine to me.

If we ever decide to enable it for more namespaces, we'll need to set up and make use of mw:Extension:TemplateData too.

-- nl6720 (talk) 06:47, 25 August 2025 (UTC)

Extension:VisualEditor shows a notice when creating a new page:

You have followed a link to a page that does not exist yet. To create the page, start typing in the box below (see the help page for more info). If you are here by mistake, click your browser's back button.

We would want to modify the link to stay on the same site.

— Lahwaacz (talk) 12:26, 5 August 2023 (UTC)

It uses MediaWiki:Helppage. -- nl6720 (talk) 06:56, 25 August 2025 (UTC)

Highlight the "Show preview" button instead of the "Save changes" one

This time the "Save changes" button is highlighted (with solid blue colour in my case; I use light theme if it matters). But, wait! It is definitely not the button I want to press—it's even more harmful than "Cancel" (which is coloured in red), because cancelling leads to throwing away my edit, and erroneously saving leads to corrupting a whole page.

Could you highlight the "Show preview" button instead (or "Show changes" if you prefer it)?

With other words: I press "Save changes" only once, and it is extremely deliberate action. I don't like that editor interface tells me "hey! press it! look, it's bold. press it right now!"

— Andrei Korshikov (talk) 18:34, 18 August 2025 (UTC)

Enable automatic Vector 2022 night mode

I think the current state of our dark colors is good enough to enable Vector 2022 night mode by default (i.e. based on the browser preference: archlinux/archwiki#79). I propose adding the following to LocalSettings.php:

$wgDefaultUserOptions['vector-theme'] = 'os';

-- nl6720 (talk) 16:11, 28 August 2025 (UTC)

👍 — Lahwaacz (talk) 13:25, 13 September 2025 (UTC)

What about "Containment" category?

We have a number of articles about Linux containers (do not confuse with Linux Containers)—LXC, systemd-nspawn, Docker, Podman (and maybe I miss something). All these are part of Category:Sandboxing and Category:Virtualization. In principle, I agree that containment is both about sandboxing and virtualization in some sense, but I think that containers are quite recognizable feature on their own. — Andrei Korshikov (talk) 17:34, 3 September 2025 (UTC)

I think "Containment" sounds a little ominous. How about Category:Containers instead? -- nl6720 (talk) 06:05, 6 September 2025 (UTC)

I agree. — Andrei Korshikov (talk) 20:31, 6 September 2025 (UTC)

And how would you change the categorization of the existing pages? — Lahwaacz (talk) 13:31, 13 September 2025 (UTC)