ArchWiki talk:Maintenance Team

From ArchWiki
Jump to navigation Jump to search
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.


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

Regular Wiki Cleanup Days

I think it would be really useful to have regular wiki cleanups where people gather together to work on the wiki. This could help with organizing categories, cleaning out mentions of rc.conf, or doing major edits/reorganizations. They could be held every 3 months (4x a year) with lots of advertisement and be a great way to get more people involved in Arch Linux. Meskarune (talk) 19:45, 11 October 2016 (UTC)

Admin guidance

Show we add some guidence that an admin should follow, the responsibilty they should take?


  • Encourage contribution from Arch users.
  • Guide new contributor to follow Arch Wiki Style.

--Fengchao (talk) 13:23, 11 July 2014 (UTC)

Well, if somebody becomes an admin, (s)he's probably been judged to be already fully aware of all his/her responsibilities, since becoming an admin requires quite a bit of experience as an editor (most likely as a maintainer first). Yes, some users are given administration rights because of other roles in the community, e.g. Devs, TUs, forum admins etc., but they usually don't act as "real" wiki administrators. Nonetheless, some guidelines may help users understand what is the role of an admin, and the same goes for maintainers, and we could create a proper page for that, as was conceived in #Meaning of Administrator. -- Kynikos (talk) 06:06, 12 July 2014 (UTC)

Cite extension

[Moved from User talk:Kynikos#Cite extension. — Kynikos (talk) 10:04, 15 January 2015 (UTC)]

I'm feeling bad about not having a way to cite my sources properly in my article. As I do for the LibreOffice Newsletter I'm in charge of I'll do as it for my Arch Linux articles:

Some text<ref name=myRefName />

== References ==

<ref name=myRefName>[http://someURL The link]</ref>

I don't know if this system suits you. Let me know. -- wget (talk) 01:07, 10 December 2014 (UTC)

Unfortunately you cannot use the ref tag in this wiki, since it requires the Cite extension, which we don't have installed. Generally we don't require to support every statement with citations, unlike for example on Wikipedia, but it will be very useful if you will add references to external sources simply using links on keywords, like this, or this[2] (see the source text for the implementation; we don't have style rules about this for the moment). If you want to mention the generic sources that you use for writing the article, you should just add them to Dynamic Kernel Module Support#See also. -- Kynikos (talk) 05:49, 10 December 2014 (UTC)
I don't like this idea very much. The See also section sounds like we invite the user to read these documents to provide more detailed information to the reader, implying the Arch Linux documentation is not complete enough. This isn't actually what we want to do in this case: we just adapted an existing article to build a section of the Arch Linux documentation page. And yes, I would really like to have citations like in Wikipedia, but without the need to cite every assumptions we make obviously. Would you mind installing the Cite extension? -- wget (talk) 12:00, 11 December 2014 (UTC)
Unfortunately installing extensions requires write access to the repository, which is restricted to Developers, and a feature request should be opened in the bug tracker. I don't see other alternatives to the methods I proposed above.
That said, ArchWiki articles are not intended to be "complete" as in "it shouldn't be necessary to read anything else in order to understand every detail of the topic"; if the topic has good upstream/official documentation, there's no point in duplicating it, see also Help:Style#Hypertext metaphor.
-- Kynikos (talk) 14:12, 12 December 2014 (UTC)
Hi Kynikos. Happy New Year! Any news about the citation extension? Yet again today, I wanted to write on the wiki that yaourt does support bash and zsh completion, and to link these assumptions to the source code. The cite extension is indeed very useful, especially in the case (like this one) when upstream has not good documentation. If you haven't already reported the feature request on the bug tracker, are you willing to support the one I'm gonna write? Otherwise, I don't see the interest in writing that request: devs will unlikely accept it without your support. Thanks in advance. -- wget (talk) 23:50, 6 January 2015 (UTC)
Happy New Year mate :) Honestly I don't see the need for the cite extension here: can't you just use simple inline links as I proposed above? (And as it's done in every article?) Sorry, but unless you prove that you really have no way to add that link without the extension, I can't support your request... Just try to amend the article with inline links and let's see how it looks, ok? I'll try to help you fix the style, if needed ;) -- Kynikos (talk) 05:34, 7 January 2015 (UTC)
Yesterday again, I was cleaning/updating the Browser plugins and wanted to put a link to the official where I took that information from. That link concerned two locations in that article: Disable the "Press ESC to exit full screen mode" message and Multiple monitor full-screen fix, the solution using inline links was to duplicate that URL which I didn't. Regarding the your message, the problem seems to be a lack of workforce then. A possible solution would be merging wikis and forums of the native languages communities into Arch Linux infrastructure, bringing along all these admins/maintainers to the Arch infra. But for that a bunch of work needs to be done first: easy multilanguage support (especially regarding links) on the Wiki (maybe native language staff can help for that). -- wget (talk) 14:59, 8 January 2015 (UTC)
I see, actually if you want to use the same link in two different sections, there's nothing against it; even if there was the Cite extension installed, you'd have to duplicate the <ref> tag, right? There are already many articles with multiple instances of the same internal or external links, I don't see any harm with that, as long as the duplicated links are found in indipendent parts of an article.
-- Kynikos (talk) 15:18, 9 January 2015 (UTC)
Yes, just the <ref> tag will need to be duplicated, but the URL, authors, description, etc. will not. That ref will just act as a very short reference to the long <ref> tag written at the end of the article. See this example, this is the way we are working at TheDocumentFoundation. -- wget (talk) 21:20, 13 January 2015 (UTC)
In general, also expanding on what I wrote in my arch-general post that you linked, my position is that it's too late to install the Cite extension now, because that would only introduce a new style standard for external links that would make all the existing articles style-obsolete, in practice starting a very long — if not infinite — transition period over which articles would have both inline and referenced links, which I wouldn't see as an improvement at all.
-- Kynikos (talk) 15:18, 9 January 2015 (UTC)
Don't underestimate my patience or my scripting abilities ;-), I'm the kind of guy a bit maniac, with obsessive need to get everything neat. So transition period isn't really a problem ;-) -- wget (talk) 21:20, 13 January 2015 (UTC)
Eheh I understand, I guess I'm a bit like that myself :P Well, considering that we've got this far, I'm going to move this branch of the discussion to ArchWiki talk:Administrators and see what are the opinions of the rest of the team. — Kynikos (talk) 09:51, 15 January 2015 (UTC)
Maybe I'm missing something obvious, but I dislike the Wikipedia citation style simply because it needs 3 clicks instead of one: one to see the link, a second to open it, and a third to return to the article. That said I'm a proponent of requiring citations for statements made on this wiki: Help_talk:Style#Citations and reasoning (one of these days I'll get to making a draft). -- Alad (talk) 18:31, 29 October 2015 (UTC)
What I was saying is that if Wikipedia-style citations had been used from the beginning of this wiki, I think we'd probably be used to them by now; it's true that they require more effort to follow a link if you don't use the mouseover tooltip (e.g. when using pentadactyl, vimfx etc.; tooltips can also be set to appear on click though); on the other hand, though, they encourage the maintenance of a comprehensive list of external reference links at the bottom of each article. Anyway, as I've repeated multiple times, now I'm against introducing Wikipedia-style citations.
Regarding requiring citations, I'll wait for your draft, but I think making them a requirement could be too much: what do we do with unreferenced statements? Delete them? Or fill articles with "Citation needed" templates? Wikipedia needs citations more than us because it deals with topics that can be easily discussed from biased standpoints; also, it doesn't allow original research, see also Wikipedia:Wikipedia:Verifiability. In this wiki, I'd talk more of a recommendation, and well specify what kind of statements should better be referenced.
Kynikos (talk) 15:27, 30 October 2015 (UTC)
Please see it like this: using inline or referenced links are just two different style conventions: the ArchWiki happens to use the first one, let's just stick to it and concentrate on the rest, ok? :)
There is indeed a lack of workforce on the back-end, although I have to acknowledge the fact that Pierre has recently finally pushed MediaWiki 1.24 in the repo, which means it will reach the server very soon; anyway, his policy regarding internationalization has always been the opposite of your proposal, i.e. encourage localized versions to host their own wiki, so your idea would find some opposition there; but even if it didn't, I think you're greatly overrating the state of the external Arch wikis: of them, only the German and French wikis are actually alive, and the German wiki is already maintained by Pierre himself :)
-- Kynikos (talk) 15:18, 9 January 2015 (UTC)
Didn't know much about the wiki infrastructure and native language frequentations, but what I've seen on the #archlinux-fr freenode IRC channel, there are some people involved with the French wiki who could be returned to the official wiki, recovering a bit more workforce. Its a great subject for discussion between officials (Pierre) and third parties IMHO. Yes, I'm in complete favour of federating around a same well defined goal: "Unity makes strength", "United we stand, divided we fall" is my country motto. -- wget (talk) 21:20, 13 January 2015 (UTC)
Well, my personal opinion, which is not an official position because we've never discussed this among the admins, is that I'd be in favour of returning all the translations in the same wiki, but only after implementing Help talk:I18n#Language namespace(s) in place of suffixes? and proving that it works efficiently with the languages that are already hosted here; we should also prove that we can merge the databases of the external wikis safely and effectively. Only after that we could discuss the return of the external languages, stressing the fact that the admins coming from the other wikis should be willing to adapt to the English wiki customs, which I wouldn't take for granted.
For the first step I'll need to complete some adaptations to my bot, but that's not on high priority at the moment: I have a todo list that I follow more or less strictly, and I promise I'll get there :)
Kynikos (talk) 09:51, 15 January 2015 (UTC)
Another advantage of being able to use <ref> is that one could also add meta information to the URL that's being linked to in order to prevent link rot. Not all URLs are descriptive enough to figure out where they might have gone when they're not reachabe anymore and the Wayback Machine wasn't able to crawl the site. -- Ckujau (talk) 17:07, 16 July 2017 (UTC)


I would like the mw:Scribunto extension to be installed to the ArchWiki, so that we can improve existing templates and create new useful templates, which currently cannot be implemented. For example we currently cannot implement Template:Info. Furthermore mw:Lua scripting would make template code more readable and facilitate maintenance by allowing for translated templates without duplicating the template logic.

--Larivact (talk) 20:07, 17 August 2018 (UTC)

Frankly, I don't know how to feel about this. Obviously it would help to fix a lot of problems, but I wouldn't overestimate its usefulness. Lua modules still have to deal with arguments in the MediaWiki markup and the output is integrated back into the MediaWiki markup, so some problems will inherently persist. And since the core markup language sucks, combining it with a perfect scripting language would still be a sucking experience...
Another thing is that WMF moved to Lua primarily due to performance reasons and I don't think that our wiki has any performance problems with the current templates.
The last thing is a question whether we really need to invent more and more complicated templates or whether we can keep them simple like they are now. For example, we can say that Template:hc cannot be used inside lists, which covers at least 99% of the use cases, and for the remaining 1% I'm sure it is possible to adjust the surrounding content of the page to look good even if the template is not inside a list. Having a limited language for writing templates really helps to control the complexity of the resulting templates.
More opinions needed (especially from the administrators and maintainers).
-- Lahwaacz (talk) 11:40, 23 August 2018 (UTC)

Patch Vector skin to display categories at the top of the page

Categories on the ArchWiki are currently displayed at the bottom of the page. While this is the MediaWiki default, it does make the categories of an article less accessible, especially if the article is long. Because categories provide such a great way to find related articles, I think they deserve to be prominently placed at the top, right below the page heading. This is also more consistent with our convention to keep categories at the top of the source text. I initially tried to implement the change using CSS but had to figure out that the two ways to move catlinks to the top with CSS, absolute and flex positioning, cannot be implemented cleanly as both don't work with margin collapsing. Kynikos asked WikiMedia if they would accept a Vector skin patch to implement the feature as an option, to which they didn't respond. I managed to patch the Vector skin to implement the desired change. Although we would need to maintain the patch ourselves, I think it is doable (the patch only changes 10 lines) and warranted as it would improve ArchWiki for every reader (that uses the default skin).

I submitted my patch as a pull request to the ArchWiki GitHub repository.

--Larivact (talk) 03:01, 18 August 2018 (UTC)

Now that my patch was declined the only way left appears to be upstream. --Larivact (talk) 15:39, 18 November 2018 (UTC)

Convention for splitting sections to new page

Under what circumstances should sections be split into new articles ? (I could not find any articles mentioning it exploring ArchWiki:Contributing. For exemple current OpenSSH#Tips_and_tricks, or pacman#Troubleshooting.

-- Apollo22 (talk) 22:01, 15 June 2019 (UTC)

Hi, it would probably be too hard to find generic criteria to decide when it's ok to split sections, it's always been discussed case by case. If you have solid arguments in favor of splitting those examples, you can flag them with Template:Move and start a discussion in their talk pages (not here).
Otherwise you can try to propose some generic guidelines, for the moment we have a procedure to implement a split after an agreement has been reached.
-- Kynikos (talk) 09:03, 16 June 2019 (UTC)
Maybe not generic criterias, but specific ones. For example sections like Tips and tricks or Troubleshooting can expand quickly. A generic rule like: if more than 10 subsections are listed, you can move the section in a subarticle without asking first -- Apollo22 (talk) 10:58, 16 June 2019 (UTC)
Another example is applications lists. Splitting them in a subarticle would allow direct inclusion in both the specific article and the applications list. -- Apollo22 (talk) 10:58, 16 June 2019 (UTC)
That's not enough, because e.g. Chromium/Tips and tricks is flagged to be merged with the main page again. In any case, splitting sections into separate pages has to be discussed first, because it is a radical restructuring of an article and we have ArchWiki:Contributing#The 3 fundamental rules. -- Lahwaacz (talk) 11:59, 16 June 2019 (UTC)
In case the Chromium page, I believe the separation in two pages is sane (I think the main page is long enough to justify the split). Also, in my mind, splitting a file is not a radical restructuring, but I understand the position of always announcing it first. Which template should be used to announce a split ? The Template:Move description suggest it is only for renaming articles ? -- Apollo22 (talk) 10:18, 17 June 2019 (UTC)
I've fixed the Template:Move description, the template has frequently been used to flag sections to be split, e.g. Network configuration#Device driver, Arch terminology#Arch Linux or List of applications#Network managers, which works pretty fine. -- Kynikos (talk) 16:16, 17 June 2019 (UTC)

Also, the related articles sidebar can appear to be a little bloated on some articles (for exemple pacman). Should there be a dedicated side bar for subarticles (not sure about the name) like pacman/Tips_and_tricks in pacman ?

-- Apollo22 (talk) 22:01, 15 June 2019 (UTC)

I don't find pacman's related articles box bloated; I'm instead afraid that I would find a separate dedicated side bar for subarticles to be an unnecessary complication. -- Kynikos (talk) 09:03, 16 June 2019 (UTC)
I understand. On a related note, how about adding an explicit rule/procedure to put subarticles first or last ? Also, if this is accepted, shoud/could there be a separator between subarticles and related articles ? Current exemple in ArchWiki:Sandbox -- Apollo22 (talk) 10:58, 16 June 2019 (UTC)
I don't have a preference about the order of subarticles in related links, you can see if you gain some interest in Help talk:Style, I suggest listing some example articles and show how their related boxes would change if an ordering rule was enforced, and assess pros and cons.
About separators, I don't like them in this context regardless of the links order :)
-- Kynikos (talk) 16:26, 17 June 2019 (UTC)

Remove redirect page with bad title

This topic is similar to above #Removing unnecessary redirects / pages but with a different target redirections.


  • The Help:Article naming guidelines changes along the years, so there exist many Old_Title -> New_Title redirections.
  • Many new users contribute to Arch Wiki before they notice there is Help:Article naming guidelines, so there exist many Bad_Title -> Good_Title redirections.
  • The Arch Wiki search field got a suggestion function years ago (Maybe since v1.3?), it is more user friendly but a new problem arise.

Problem: Redirect pages show up in search suggestion, so the search suggestion is usually very messy. For example for "Installation", I may get some thing likes:

Installation guide
Installation Guide
Installation guide(Català)
Installation guide (Català)
Installation Guide (Català)

Solution: Delete pages with bad_title/old_title after some transition time? 6 months or 1 year? Any objection or better suggestion?

—This unsigned comment is by Fengchao (talk) 14:21, 14 May 2020‎ (UTC). Please sign your posts with ~~~~!

I think that pages with bad titles can be deleted after a week, and pages with old titles can be deleted after half a year. -- Blackteahamburger (talk) 09:21, 7 June 2020 (UTC)

Are there statistics of page access?

Out of curiosity, is there a resource of analytics or any other statistics of pages access for, e.g., knowing which pages are more demanded by users? This subject came up in my translation group when talking about where to focus translation in. -- Josephgbr (talk) 00:05, 28 June 2020 (UTC)

I don't think so, but you can try asking the devops team to filter the web server logs and make some statistics public. -- Lahwaacz (talk) 08:43, 28 June 2020 (UTC)
I think this is very good and can be used to confirm the priority of translation and confirm the pages that should be maintained from time to time. -- Blackteahamburger (talk) 10:00, 28 June 2020 (UTC)
Agreed. Would be nice to review and assist with what matters most to our users. Adamlau (talk) 05:13, 11 July 2020 (UTC)

Acceptable user names and signatures

I've just blocked User:🥚 for a week until we make a decision on a general policy, they had only edited their User page, so it's borderline spam or a joke, but that's not my main point.

I think the user name is practically unsearcheable without copy-pasting, and too hard to address for example in talk pages, it may mess up logs, bots etc.

1) I propose to limit user names to ascii characters, plus possibly the other languages' characters that we support, but exclude emoticons and other fancy unicode characters. We'd either need a comprehensive definition or reserve the right to decide case by case.

-- Kynikos (talk) 12:44, 11 August 2020 (UTC)

Well, it messed up wiki-scripts and it took me more than an hour to figure out the problem... [3] To actually limit the user names, we could write an abuse filter with some regex matching (assuming that the extension actually works). -- Lahwaacz (talk) 13:00, 11 August 2020 (UTC)
If we find an exact character set, sure we can try with an abuse filter. For the moment I'm also adding a reference to w:Wikipedia:Username_policy#Non-script_usernames (and the rest of the page): we may even default to using that page too. -- Kynikos (talk) 13:18, 11 August 2020 (UTC)
Yes, I think that would be a good policy for us too. It's certainly much better than writing our own from scratch :) -- Lahwaacz (talk) 14:11, 11 August 2020 (UTC)
I don't really see an issue with these kind of usernames; if some script can't parse them, then it's the fault of the script not the username. There hasn't yet been a influx of users with malicious intents and not-easily typable usernames, so I'd rather we don't take a heavy handed approach. Let's not overreact over an egg. -- nl6720 (talk) 09:40, 12 August 2020 (UTC)
Ok that bots are supposed to be able to handle unicode, and the "too hard" in my OP should have better been "needlessly hard", of course we can find our way around weird usernames, still assuming that MediaWiki and the extensions that we use are "ok" with that too (MW is mainly developed around Wikipedia, and adopting a looser username policy may end up into unexplored territory).
In general though I think nobody whose goal is constructive interaction with the community would choose a clearly deliberately hard-to-handle username. After all, the purpose of a username is to make oneself easily identifiable by the other members of the community, it's not there only for aesthetic or artistic reasons.
I wouldn't see adopting w:Wikipedia:Username_policy as heavy handed, the restrictions on misleading and disruptive usernames make a lot of sense to me, still leaving a lot of freedom of choice.
I'd also be ok to take this to a vote.
-- Kynikos (talk) 17:59, 13 August 2020 (UTC)

2) While I'm at it I'd also propose to ban custom signatures, which are very rare, but when used they badly mess up the source text of talk pages for no reason.

-- Kynikos (talk) 12:44, 11 August 2020 (UTC)

Or at least ban custom signatures that hide or change the real username. -- Kynikos (talk) 17:59, 13 August 2020 (UTC)

Switch to another editor

There is a request to switch to another editor: FS#55828. Apparently the original "2006-core-Editor" was removed in MW 1.30 and now there is only a plain textarea without any toolbar with various markup buttons. Some users may find it difficult to format an article without knowing the MediaWiki markup, but I'm not fond of enabling something that provides buttons to insert <code>, <pre> and even other HTML tags. Users should always learn the markup and Help:Style (at least basics) if they want to contribute regularly. What do you think? -- Lahwaacz (talk) 09:22, 12 September 2020 (UTC)

I've only taken a quick look at the proposed extension, but it seems it can be customised to a great extent, so I'd be in favour only if we adapt it to comply with our style rules.
[devil's_advocate]$ Requiring people to edit without UI aids may end up resulting in more typos/syntax mistakes, or simply discouraging contributions. Also, we're in 2020 and we must assume that there are people who want to contribute through smartphones, and entering non-alphanumeric characters on a thumb keyboard can be exhausting.
-- Kynikos (talk) 02:21, 13 September 2020 (UTC)
I'm not against switching the editor. The only issue I see with the proposed Extension:WikiEditor is that it has a "Reference" button that inserts <ref></ref> and ArchWiki doesn't enable Extension:Cite. Changing the toolbar requires editing a file in the extension's directory which is not really pretty or feasible.
We could also wait for MediaWiki 1.35 and use the "2017 wikitext editor", but that's part of Extension:VisualEditor and I don't know if it's possible to disable the visual editing mode.
On the topic of editor improvements, both of the aforementioned editors support syntax highlighting using Extension:CodeMirror. If we're changing the editor, I'd like to enable syntax highlighting for it too.
-- nl6720 (talk) 08:36, 13 September 2020 (UTC)
Draft PR: -- 09:19, 13 September 2020 (UTC)
VisualEditor requires setting up Parsoid and RESTBase, which seems too complicated. The "2017 wikitext editor" probably works without that, but we would still have to find the configuration to disable the "visual" mode (if it is even possible). It also probably still includes the <ref></ref> button.
The Extension:WikiEditor might be configurable with a site-wide javascript: mw:Extension:WikiEditor/Toolbar_customization#Removing_things I think that would be good enough for us...
-- Lahwaacz (talk) 09:36, 13 September 2020 (UTC)
According to mw:Parsoid, "Parsoid (the PHP version) is natively bundled in MediaWiki 1.35". That's why I said if we want the "2017 wikitext editor", we should wait till MediaWiki 1.35 is released. -- nl6720 (talk) 09:39, 13 September 2020 (UTC)
According to the docs, it should be possible to remove the button with:
$( '#wpTextbox1' ).wikiEditor( 'removeFromToolbar', {
	'section': 'main',
	'group': 'insert',
	'tool': 'reference'
$( '#wpTextbox1' ).wikiEditor( 'removeFromToolbar', {
	'section': 'help',
	'page': 'reference'
But I could only get it to work this way:
$( '#wpTextbox1' ).on( 'wikiEditor-toolbar-doneInitialSections', function () {
	$( '#wpTextbox1' ).wikiEditor( 'removeFromToolbar', {
		'section': 'main',
		'group': 'insert',
		'tool': 'reference'
	$( '#wpTextbox1' ).wikiEditor( 'removeFromToolbar', {
		'section': 'help',
		'page': 'reference'
} );
Unfortunately the button is visible for a moment before it's removed.
-- nl6720 (talk) 10:11, 13 September 2020 (UTC)
MediaWiki 1.35 is out, so it's time for some testing.
It is possible to disable visual editing mode of Extension:VisualEditor and use only the "2017 wikitext editor":
wfLoadExtension( 'VisualEditor' );
$wgDefaultUserOptions['visualeditor-enable'] = 0;
$wgHiddenPrefs[] = 'visualeditor-enable';
$wgVisualEditorEnableWikitext = true;
$wgDefaultUserOptions['visualeditor-newwikitext'] = 1;
$wgHiddenPrefs[] = 'visualeditor-newwikitext';
And unlike with Extension:WikiEditor, in 2017 wikitext editor there is no "reference/cite" button if Extension:Cite is not enabled.
I haven't gotten far with the visual mode. I followed mw:Parsoid/PHP and since I'm using mediawiki, I set $PARSOID_INSTALL_DIR = '/usr/share/webapps/mediawiki/vendor/wikimedia/parsoid';. Unfortunetly I'm stuck with Error contacting the Parsoid/RESTBase server (HTTP 403) :(
-- nl6720 (talk) 18:59, 26 September 2020 (UTC)
Actually Parsoid doesn't need configuring. I missed the obvious thing that RESTBase needs to be installed separately, that's too much of a hassle for me. -- nl6720 (talk) 05:50, 27 September 2020 (UTC)

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

Define a clear, comprehensive and professional model of documentation

In the beginning of ArchWiki:Contributing it's written:

"ArchWiki strives to be a clear, comprehensive and professional model of documentation. "

However, when I suggested edits to various pages, it turned out that other users had very different views of what makes a page better or worse. Could we create a more concrete and detailed document on the principles of a good page and good wiki?

Ynikitenko (talk) 16:21, 17 November 2020 (UTC)

How to complain about a user

There is a user User_talk:Scimmia. I'd like to make a complaint about his behaviour. Where can I do that? I couldn't find this in ArchWiki:Contributing Ynikitenko (talk) 16:53, 18 November 2020 (UTC)

You can do it right here, but think twice before doing so. Did you consider that it may have been your behaviour which provoked whatever reaction you want to complain about? Scimmia is a staff member who obviously knows more about Arch than yourself and should be respected appropriately. -- Lahwaacz (talk) 20:25, 18 November 2020 (UTC)
Ok, thanks for the answer. "think twice before doing so" - is it prohibited to complain or what? What are the sanctions for complains that Administrators find not appropriate? Does you phrase "should be respected appropriately" mean that one should not complain about moderators?
"Did you consider that it may have been your behaviour" - yes, of course. I also try to do my best judgement.
"who obviously knows more about Arch than yourself" - I think that this phrase and your whole comparison of me and him is disrespectful towards me. We had a duscussion on codecs, and he stated a false position, and couldn't prove that, though I proved mine. Anyway, knowledge about Arch doesn't allow moderators or staff members to show disrespect to other users (their knowledge not important, their manner of reasoning and communication may be). I also think that if you don't tolerate criticism of your actions here, create a special page where users can complain about admins and moderators, and staff members - if you find it right, of course. Ynikitenko (talk) 08:09, 19 November 2020 (UTC)

Complaint about an administrator

I originally came to this page from "If you have any generic negative remarks or complaints about how the wiki is moderated or administered" ArchWiki:Contributing#Complaining. In Code_of_conduct#Contacting_the_staff, however, it's written "If you feel that an egregious oversight has been made, or if you need to alert the staff of any abusive behavior" - so I refer to this. I think it would be useful to make these pages in sync (because from the first page it's unclear that one should address complaints here).

Ynikitenko (talk) 17:43, 19 November 2020 (UTC)

Hi, Code_of_conduct#Contacting_the_staff links to ArchWiki:Maintenance Team, which in turn explicitly suggests to use this talk page in ArchWiki:Maintenance Team#Members; ArchWiki:Contributing#Complaining links to ArchWiki talk:Maintenance Team directly, so in my opinion the two pages are already consistent, but we're open to more detailed suggestions to improve. -- Kynikos (talk) 02:05, 24 November 2020 (UTC)
Hi. It looks like you add here the 3rd page I didn't notice. In ArchWiki:Maintenance Team it's also suggested to use this talk page "for generic remarks or if you require assistance from the Maintenance Team, or to discuss wiki organization, conventions, etc. ". When I originally came from "If you have any generic negative remarks or complaints about how the wiki is moderated or administered" it wasn't clear for me whether concrete complaints are appropriate on this page. To keep things synchronized best, I suggest
  • write at the top of this page:
(header) Use this page to contact Wiki Maintenance Team
Union of all reasons and topics from previous pages.
I wanted to suggest it myself, but I see that there are important admin discussions right now at the top of the page.
  • separate internal admin communications from communications with users. Do you expect users to take part in your communications? Then leave it as it is. But I think it would be easier for users to have just one dedicated page to communicate with the maintainers/moderators.
Ynikitenko (talk) 18:42, 26 November 2020 (UTC)
Let's keep it simple, I've added a Note at the top of this page as you suggested: all discussions here are meant to be public and accessible to anybody interested to share their opinion, not only maintainers. The staff has a private mailing list for internal communication. -- Kynikos (talk) 01:34, 30 November 2020 (UTC)

When I initially wanted to make a complaint about a user, an administrator Lahwaacz wrote this (full citation):

"You can do it right here, but think twice before doing so. Did you consider that it may have been your behaviour which provoked whatever reaction you want to complain about? Scimmia is a staff member who obviously knows more about Arch than yourself and should be respected appropriately. "

I think such a form has several problems:

1) it looks like a threat. "think twice before doing so" - ?.. It also looks like a minor insult (I should learn how to think).

Ynikitenko (talk) 17:43, 19 November 2020 (UTC)

"think twice before doing so" would "look like a threat" if his post had ended there, however it follows with a sensible suggestion to first objectively review your own behaviour, which fully explains the meaning of "think twice" in the previous clause. Perhaps the full stop may have helped misinterpreting what he meant, and using a colon would have been more suitable, i.e. "think twice before doing so: did you consider...". I see no insult either, and hopefully when re-reading the comment after a few days you will agree that there's no sign of that intention. -- Kynikos (talk) 02:05, 24 November 2020 (UTC)
I think there were several problems of my interpretation of this. One of them is that I don't know about sanctions on this wiki. When I'm unsure, I can interpret this as if I can wait for a ban if I complain about a staff member.
Another problem was that Lahwaacz didn't answer my question on what he meant. So I had to include all possibilities. And when there is a possibility to read neutrally or as an offence, the whole phrase obtains some offensive tinge (because that possibility is present).
Another problem is that the very meaning of his answer was unclear to me. It ended that the staff member "should be respected appropriately." - which is absolutely vague, and vagueness doesn't improve feelings.
Probably you are right that the meaning of his answer was not personally offensive, but I sensed several emotionally charged words in his reply.
"think twice" according to Wiktionary is "To reconsider, use judgement" (which is re-consider, or maybe cancel). ", but think twice", "Did you consider", "provoked", "whatever ... you want to complain", Scimmia has a one-time "reaction", while I have general "behaviour". "obviously", highlighted "respected" in the end.
Why "respect" looks vague: I think it's not very polite to expect from me to write socially unacceptable things about other people, and I see no reason why someone could expect that from my previous messages. So the only thing to be "respectful" looked like not to complain at all.
So my general feeling was a strong disapproval of my complaining and blaming me of any of my complaints. Ynikitenko (talk) 19:21, 26 November 2020 (UTC)

2) "who obviously knows more about Arch than you" (stress mine) - this looks like a personal insult too. I didn't ask here to compare me with other users. Moreover, Arch wiki is not exclusively about Arch. Various software is discussed there as well, and even Arch staff may hardly know everything.

Ynikitenko (talk) 17:43, 19 November 2020 (UTC)

Here honestly I'm really struggling to understand where you may have felt insulted, unless I take into account the fact that you were already taking his comments personally at this point, which would have influenced your interpretation of the rest of the observation. "obviously" means that a member of the Arch staff is assumed to know more about Arch than non members, and I don't see why it shouldn't be so, i.e. there must have been some reason why a person became an official member. ArchWiki is not exclusively about Arch in the sense that Arch Linux is per se simply a distribution of software plus maintenance and support services, so there wouldn't be much to say about a mere box without talking about the items it holds, but the wiki's content only refers to the distributed software within the context of Arch Linux, never in a more abstract way. Nobody knows everything, including the Arch staff: if you know objectively more/better about something, it is up to you to prove it with facts; unfortunately sometimes discussions are not simply about facts, but they involve opinions, and there's often no absolutely true or false opinion per se, so a decision has to be made at some point, and that's why we have some people to cover official staff roles here. -- Kynikos (talk) 02:05, 24 November 2020 (UTC)
I have to agree that the phrase "who obviously knows more about Arch than you" in itself is true. Yes, my reaction was due to other context and previous discussions on other pages. Yes, I tried to provide links to "facts". Yes, some "facts" are indeed someone's opinions. Ynikitenko (talk) 19:52, 26 November 2020 (UTC)

3) "is a staff member... and should be respected appropriately" - does this mean that staff members are more respected than other users? (usually it's formulated that their decisions are not argued on corresponding pages). Does that mean that staff members have any special role in Arch Wiki? I thought that the chosen moderators and administrators have.

Ynikitenko (talk) 17:43, 19 November 2020 (UTC)

"appropriately" does not mean "more than other users". Arch Linux is not run as a democracy though, so it's not a matter of "respect", but of "authority", i.e. members do have more authority than non members. In this light, this includes staff members in the wiki, and wiki staff in the rest of the Arch platforms. -- Kynikos (talk) 02:05, 24 November 2020 (UTC)
In that link it's written "are charged with the responsibility of maintaining peaceful, civil order for the majority of the community". As I understand, "respect" wiki maintainers means to conform to their maintenance decisions. "this includes staff members in the wiki" - if this is the rule, then why aren't staff members automatically maintainers of the Wiki?
I thought that Wiki maintainers are most experienced and work most on Wiki. If someone works on other parts of Arch, it doesn't make him or her a good Wiki maintainer - therefore they are not. I think that Wiki requires some special skills, and as a concrete suggestion I propose to leave the distinction "staff" as real staff of the Wiki. Or maybe I shall ask all maintainers on their opinion on that after I write the complaint I wanted. Ynikitenko (talk) 19:30, 26 November 2020 (UTC)
When a wiki maintainer makes a definitive decision, yes, everyone's supposed to respect it unless they have a really cogent reason to argue against (i.e. with facts, no longer opinions).
Not all Arch support staff members are official wiki maintainers, and not all wiki maintainers are official Arch support staff members (only wiki administrators are both). Because the generic word "staff" is used in the wider Arch community, we cannot reserve it to only wiki maintainers here: when referring to "Arch staff" in general we mean any official member of the community; when referring to "Wiki staff" we mean official maintainers.
If you'll ever have more complaints to write, there won't be the need to explicitly ask maintainers for their opinion: those interested will read your complaint and intervene as needed.
-- Kynikos (talk) 01:34, 30 November 2020 (UTC)

4) "your behaviour which provoked" - blaming me for what?.. Or is it a confession that that user's behaviour was indeed inappropriate? I didn't see any criticism of his actions from that moderator though (only mine).

Ynikitenko (talk) 17:43, 19 November 2020 (UTC)

This was mostly dealt with in Talk:General recommendations#Mods intervention needed: it was an edit war, however small, so the original content prevails until an agreement is explicitly reached in the talk page. -- Kynikos (talk) 02:05, 24 November 2020 (UTC)
"the original content prevails until an agreement is explicitly reached in the talk page" - I think this is a good example of a rule, which should be probably stated somewhere.
I understood this rule before it was stated here; however, I made a small edit on another section and I didn't restore the deleted section (which we discussed), so in my opinion that was a different thing (and the moderator created a separate talk for that eventually). Ynikitenko (talk) 19:52, 26 November 2020 (UTC)
We aren't trying to write rules for everything, for we're people here, not machines: we have some official staff who were also elected for their ability to resolve issues case by case, using their judgement: this is the "not a democracy" part cited above. In general, please just accept the maintainers' final decisions unless you have new objective facts to bring to the discussion. -- Kynikos (talk) 01:34, 30 November 2020 (UTC)

I think that Arch Wiki users should have a freedom to complain about what they consider inappropriate. No one should prevent them from doing that, threatening or ridiculing their intent. I also think that presuppositions about not-written-yet complaints is not a polite and respectful behaviour. It would be nice to formulate this in the community wiki (or guidelines for the maintenance team).

I wouldn't say that this is an extremely bad behaviour, and I must say that usually Lahwaacz provides a rather useful and respectful feedback. However, when I'm about to write a complaint, I already have problems within the community, and disrupting that and adding new ones is rather unfair.

I know that one complaint may be not very productive for the community, but I also think that changing views, policies and rules/guidelines is. That's why I hope that right general conclusions will be done from this particular case (by User:Lahwaacz and/or the maintenance team).

Ynikitenko (talk) 17:43, 19 November 2020 (UTC)

As I wrote abote, all detailed improvement suggestions are welcome in the appropriate talk pages. -- Kynikos (talk) 02:05, 24 November 2020 (UTC)
I hope I can make proposals here, and if there is a general agreement, and if more details are needed, they can be provided afterwards. Otherwise I don't think details are useful when people don't need something at all.
  • If it's clear from the top of this page when a user can use that - it's done. No need to think about polite or impolite answers of administrators.
  • Maybe user rights don't have to be stated explicitly, but they should be understandable. The only other right apart from complaining I can think of is the right to remain in the wiki. That means that there must be warnings before a user is banned. Maybe several warnings. This should be stated in some page (probably in the Code of conduct, or linked from there). The code of conduct (or a special page linked from there) must be concrete in what is considered misbehaviour and how exactly the Wiki fights with that. Right now it generally states what is bad, but provides no concrete policies against that.
  • Probably there should be a guideline (though not strict rules) for discussions. An example from here may be "don't make presuppositions of other user's intentions" and "Check if you can sound ambivalently before writing. Ask if you are unsure what the other person meant. Answer if people ask for details."
  • There should be concrete rules about how the wiki is edited. Edit wars, etc. Also who and where shall complain about misbehaviour. For example, a user says "stop this bikeshed", which is not polite and looks like an order to an ongoing discussion between other people. Maybe this should be moderator's right to judge and mark discussions as bikeshed. (this is probably not a rule, but what is considered polite/impolite).
Ynikitenko (talk) 20:18, 26 November 2020 (UTC)
And thanks for your replies, to the point and comprehensive. Ynikitenko (talk) 20:22, 26 November 2020 (UTC)
No worries, yes you can make proposals here.
  • I added a note at the top of the page.
  • Yes, users are warned before being blocked, very often several times, but always completely at the discretion of administrators. If you do something "bad", whether deliberately or unintentionally, in the eyes of an administrator, you will be notified and absolutely given the chance to understand, learn and rectify, with the exception of egregious violations such as spamming, harassing etc., so there's no need for more specific descriptions of the policies. Whenever it appears that some unwritten rule is violated or misunderstood too frequently, it will be explicitly stated in the most appropriate place. I don't remember the last time (if there ever was one) when I had to discuss all these concerns explicitly to this extent.
  • You can add specific suggestions to Help talk:Discussion.
  • See above about why we can't write concrete rules about everything: just please comply with definitive maintainers' decisions unless you have new facts to support your case.
-- Kynikos (talk) 01:34, 30 November 2020 (UTC)