ArchWiki talk:Maintenance Team

From ArchWiki
Latest comment: Saturday at 10:00 by Erus Iluvatar in topic Add a rule about regulating self promotion
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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
For the moment I've done points 6 and 7. — Kynikos (talk) 03:43, 24 May 2015 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]

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)Reply[reply]

Admin guidance

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

Example:

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

--Fengchao (talk) 13:23, 11 July 2014 (UTC)Reply[reply]

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)Reply[reply]
"Encourage contribution from Arch users" sounds like something even maintainers should do, in my opinion.
-- NetSysFire (talk) 14:53, 28 April 2021 (UTC)Reply[reply]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]

Remove redirect page with bad title

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

Background:

  • 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 ~~~~!Reply[reply]

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)Reply[reply]
I think this makes sense, also discouraging redirects with spelling errors (like "Flatpack" to Flatpak which was recently suggested). Of course, all this assuming that the redirect does not contain any relevant history which should be kept. — Lahwaacz (talk) 10:30, 9 May 2021 (UTC)Reply[reply]
One such redirect (that I think should be deleted) is Keeping Docs and Info Files. No other wiki pages link to it either. -- Flyingpig (talk) 18:44, 9 May 2021 (UTC)Reply[reply]
That one contains a history, so it should be kept (or archived at most). — Lahwaacz (talk) 15:37, 15 May 2021 (UTC)Reply[reply]
What about renaming it (to something like Keeping documentation and information files) and deleting the page with the old title? I think that should keep the revision history while maintaining compliance with style guidelines. -- Flyingpig (talk) 18:14, 15 May 2021 (UTC)Reply[reply]
I think "info" here was referring to info, but it's still better than the old title which I now deleted. — Lahwaacz (talk) 14:01, 7 June 2021 (UTC)Reply[reply]
Thanks. I guess the "bad" title wasn't as bad as I thought then. -- Flyingpig (talk) 15:17, 7 June 2021 (UTC)Reply[reply]
Guys, I have made some mess while moving a page into a user subpage, so some redirect pages ought to be deleted:
-- Duodai (talk) 06:26, 8 June 2021 (UTC)Reply[reply]
Both pages are now deleted. -- nl6720 (talk) 10:11, 8 June 2021 (UTC)Reply[reply]
Thanks. I have found that there are a lot of badly named redirects in the Russian AW (Pacman/Tips and tricks (Русский), Pacman (Русский)/Советы и приёмы, etc.), so later I shall create a list of such pages and put it here.
-- Duodai (talk) 10:44, 8 June 2021 (UTC)Reply[reply]
Here is one, please delete it: RTorrent(简体中文)。 -- Blackteahamburger (talk) 10:27, 22 June 2021 (UTC)Reply[reply]
Done. -- nl6720 (talk) 15:47, 24 June 2021 (UTC)Reply[reply]
I'm joining in here with two more pages that should be deleted : Securing arch linux and Arch Linux Server, neither have an history and both are needlessly using Arch Linux in the page title without being used anywhere. --Erus Iluvatar (talk) 19:05, 4 March 2022 (UTC)Reply[reply]
And one more Etkinleştir --Erus Iluvatar (talk) 19:29, 4 March 2022 (UTC)Reply[reply]
All done, thank you. -- Kynikos (talk) 06:16, 20 March 2022 (UTC)Reply[reply]
Thank you ! I've stumbled upon one more : Expansão, which links to Template:Expansion but is not used anywhere as this template should not be used on translations. --Erus Iluvatar (talk) 08:41, 20 March 2022 (UTC)Reply[reply]
Done. -- nl6720 (talk) 12:18, 20 March 2022 (UTC)Reply[reply]
Three unnecessary redirects from today: ASUS B9450CEA, ASUS B9450 and ASUS ExpertBook B940CEA and three older ones: Partial upgrades, TUXEDO InfinityBook S 14 v6 and Lenovo ThinkPad X1 Titanium Gen 1 --Erus Iluvatar (talk) 17:32, 25 July 2022 (UTC)Reply[reply]
I removed all the laptop redirects. -- nl6720 (talk) 06:34, 26 July 2022 (UTC)Reply[reply]
Thank you! Should I ask about partial upgrades? It was flagged with Template:Style since 2018, we have partial upgrade already, only two user pages use it, and it has no history as far as I can tell. --Erus Iluvatar (talk) 07:27, 26 July 2022 (UTC)Reply[reply]
It was created by User:Kynikos, so I'll leave it up to him to decide what to do with it. -- nl6720 (talk) 10:48, 26 July 2022 (UTC)Reply[reply]
Good work everyone, I've deleted partial upgrades. -- Kynikos (talk) 14:19, 21 August 2022 (UTC)Reply[reply]
Thank you! --Erus Iluvatar (talk) 14:20, 21 August 2022 (UTC)Reply[reply]
One more redirect with no history nor page linking to it: Terminal as a Transparent Wallpaper. --Erus Iluvatar (talk) 10:25, 3 August 2022 (UTC)Reply[reply]
Removed. -- nl6720 (talk) 10:56, 3 August 2022 (UTC)Reply[reply]
Thanks! Three other old and unused redirect without history, but for these I am not sure they deserve deletion: /etc/fstab, OS X and /. --Erus Iluvatar (talk) 12:30, 7 August 2022 (UTC)Reply[reply]
Here are a few more redirects with no history, flagged with Template:Remove for a while: Category:Dynamic WMs, Category:Tiling WMs, Category:Stacking WMs, Category:Lietuviškai, Category:Slovenský and Category:Česky. --Erus Iluvatar (talk) 12:15, 10 August 2022 (UTC)Reply[reply]
Deleted. Can you update the backlinks of the first three? — Lahwaacz (talk) 05:50, 11 August 2022 (UTC)Reply[reply]
Thank you! I have found Category:Stacking WMs (Italiano) while doing so, it can probably be deleted too. --Erus Iluvatar (talk) 07:04, 11 August 2022 (UTC)Reply[reply]
Thanks, deleted that one too. — Lahwaacz (talk) 07:19, 11 August 2022 (UTC)Reply[reply]
Two more candidates for deletion: Xterm Automatic Transparency and Configuring Terminal as a Transparent Wallpaper. --Erus Iluvatar (talk) 19:05, 11 August 2022 (UTC)Reply[reply]
Both deleted. Please fix Special:WhatLinksHere/Configuring Terminal as a Transparent Wallpaper. -- nl6720 (talk) 08:47, 12 August 2022 (UTC)Reply[reply]
Thank you! User page updated to the right redirect, the last link is this discussion. --Erus Iluvatar (talk) 10:17, 12 August 2022 (UTC)Reply[reply]
One new redirect which is unused and without history: Workstation. --Erus Iluvatar (talk) 20:13, 17 August 2022 (UTC)Reply[reply]
It's gone. -- nl6720 (talk) 14:08, 18 August 2022 (UTC)Reply[reply]
Thanks! --Erus Iluvatar (talk) 14:57, 18 August 2022 (UTC)Reply[reply]
On today's menu:
--Erus Iluvatar (talk) 12:14, 19 August 2022 (UTC)Reply[reply]
I deleted some of them.
MSI GE75 8SX has history, so it cannot be deleted. It was moved by copy-pasting instead of doing it properly.
-- nl6720 (talk) 09:44, 20 August 2022 (UTC)Reply[reply]
Thanks! --Erus Iluvatar (talk) 12:32, 20 August 2022 (UTC)Reply[reply]
Deleted the Asus stuff. Please fix Special:WhatLinksHere/Asus EEE PC 1025c, Special:WhatLinksHere/Asus EEE PC 1215n, Special:WhatLinksHere/Asus Eee PC and Special:WhatLinksHere/Asus x205ta. -- nl6720 (talk) 09:55, 31 August 2022 (UTC)Reply[reply]
Thank you very much, the pages in user space are fixed! --Erus Iluvatar (talk) 10:31, 31 August 2022 (UTC)Reply[reply]
Three more redirects with no history: Dv7-2120so, Install and configure xorg and IPv6 - Disabling the Module. --Erus Iluvatar (talk) 15:20, 30 August 2022 (UTC)Reply[reply]
I have encountered three ancient redirects that are unused and have no history: Internet Access, Dialup Access and Direct Modem Connection. --Erus Iluvatar (talk) 19:36, 5 September 2022 (UTC)Reply[reply]
More redirects I have stumbled upon today: Automatic Configuration with Cdist, Tiling window managers (we already have tiling window manager), Official Repositories Web Interface, Lenovo Ideapad Z580 --Erus Iluvatar (talk) 12:26, 15 September 2022 (UTC)Reply[reply]
One more today: MBA --Erus Iluvatar (talk) 10:43, 30 September 2022 (UTC)Reply[reply]
One more while fixing broken section links: CloudCross (portugues). --Erus Iluvatar (talk) 07:58, 18 October 2022 (UTC)Reply[reply]
It's gone. -- nl6720 (talk) 08:01, 18 October 2022 (UTC)Reply[reply]
/o\ I never said thanks! I found an other one today: Alacrity. --Erus Iluvatar (talk) 08:17, 21 October 2022 (UTC)Reply[reply]
Done. -- nl6720 (talk) 08:57, 21 October 2022 (UTC)Reply[reply]
Thanks! --Erus Iluvatar (talk) 05:35, 22 October 2022 (UTC)Reply[reply]
I've encountered Localization(文言文) today, it can be safely deleted. --Erus Iluvatar (talk) 07:09, 27 May 2023 (UTC)Reply[reply]
It's gone now. -- nl6720 (talk) 07:13, 27 May 2023 (UTC)Reply[reply]
Thanks! --Erus Iluvatar (talk) 08:05, 27 May 2023 (UTC)Reply[reply]
Here's a recent one: Dell 7440 :) --Erus Iluvatar (talk) 08:03, 15 July 2023 (UTC)Reply[reply]
It's been put to rest. -- nl6720 (talk) 08:06, 15 July 2023 (UTC)Reply[reply]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
Agreed. Would be nice to review and assist with what matters most to our users. Adamlau (talk) 05:13, 11 July 2020 (UTC)Reply[reply]
In the meantime, we can have a good approximation with Special:MostLinkedPages and Special:MostRevisions, possibly with Special:MostTranscludedPages. --Erus Iluvatar (talk) 16:24, 12 July 2022 (UTC)Reply[reply]

Acceptable user names and signatures

Ban custom signatures

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)Reply[reply]

Or at least ban custom signatures that hide or change the real username. -- Kynikos (talk) 17:59, 13 August 2020 (UTC)Reply[reply]
User:😎 just registered, although this is just a test account of User:Klausenbusk, who is a member of the devops team, this is still relevant. I am still in favor of adopting the blocklist used by Wikipedia, as mentioned in #Abusefilter.
-- NetSysFire (talk) 02:34, 5 June 2021 (UTC)Reply[reply]

Obscene usernames

I'd like to point out that a user was just deleted for having an obscene username (credits to me for finding and annoying the wiki admins with it). Having a wikipedia-like automated check if the username matches a regex would definitely help with detection of that. Wikipedia:Wikipedia:Usernames for administrator attention. -- NetSysFire (talk) 15:38, 26 December 2021 (UTC)Reply[reply]

I don't see any automation on that wikipedia page. If you give us a regex, we could try blocking that with AbuseFilter (assuming it actually works...). — Lahwaacz (talk) 08:12, 29 December 2021 (UTC)Reply[reply]
The automation is doing a bot, which does regex matching. The bot reports it on the aforementioned page so it can be reviewed since false positives are a thing. We are not as big as wikipedia anyways, so just having something report it might even be a bit too much. The other part is users reporting accounts since a bot can not possibly catch everything. There is a list of regexes that the bot uses though: Wikipedia:User:AmandaNP/UAA/Blacklist
-- NetSysFire (talk) 10:53, 29 December 2021 (UTC)Reply[reply]
I tried those patterns in Special:AbuseFilter/test using
_regex := "INSERT_REGEX_HERE";
action === 'createaccount' & accountname irlike _regex
From 2021-12-22 it matched only three account creations.
❄️❄️ nl6720 (talk) 11:58, 29 December 2021 (UTC)Reply[reply]
A little while ago I created Special:AbuseFilter/16. It blocks usernames matching w:User:AmandaNP/UAA/Blacklist and a few other words, but not Unicode ranges. So far it has 49 hits. -- nl6720 (talk) 10:40, 2 February 2022 (UTC)Reply[reply]
The account name regex matching is part of AbuseFilter/15. -- nl6720 (talk) 17:07, 24 September 2022 (UTC)Reply[reply]
Using Wikipedia:User:AmandaNP/UAA/Blacklist results in blocking more than we may want. The user caught in Special:AbuseLog/36741 reported the issue in #archlinux-wiki. As can be seen in [2], some names that do not deserve being blocked.
Should we curate the Wikipedia regex or build our own?
-- nl6720 (talk) 17:07, 24 September 2022 (UTC)Reply[reply]
I removed a few things from AbuseFilter/15 for now. -- nl6720 (talk) 17:22, 24 September 2022 (UTC)Reply[reply]
Removed one more following a request on #archlinux-wiki.
Perhaps using Wikipedia:User:AmandaNP/UAA/Blacklist in AbuseFilter was not the best idea.
-- nl6720 (talk) 18:15, 30 November 2022 (UTC)Reply[reply]
And another one. I removed that Wikipedia blacklist from AbuseFilter/15. We're back to manually policing the user names, let's see how that goes. -- nl6720 (talk) 07:51, 13 February 2023 (UTC)Reply[reply]
Unfortunately we had at least two problematic usernames in the last week. Namely one with both the N-word and the F-slur that rhymes with maggot and User:Semee1488. 1488 is a known hate symbol and there are next to no false positives. And the chances that the user was born on the 1st of april in 1988 or 4th of january are exceedingly slim. I agree that we do have false positive problems BUT wikipedia is using that list for reporting ONLY. Banning is still manual there, too but I am not sure if that applies to the harder slurs such as the N-word, which would make sense to ban automatically. We can probably thin out the list a bit and remove some less offensive stuff. So I would potentially accept usernames such as "FuckTypos" but not "IFuck<insert something here>", IrrelevantIdiot, one mentioned just above, is also fine.
-- NetSysFire (talk) 14:44, 23 March 2023 (UTC)Reply[reply]
So it didn't last long, sadly. AbuseFilter/15 once again has a curated Wikipedia:User:AmandaNP/UAA/Blacklist. And I deleted the mentioned user account (it didn't have any contributions). -- nl6720 (talk) 15:23, 23 March 2023 (UTC)Reply[reply]

Visual editor

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

Why isn't there any visual editor in ArchWiki, as in Wikipedia? -- FOSS ভক্ত (talk) 12:54, 18 September 2020 (UTC)Reply[reply]
AFAIK no one has proposed adding a visual editor. -- nl6720 (talk) 13:28, 18 September 2020 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
Note that VisualEditor requires setting up Parsoid, which might be quite hard to configure properly. — Lahwaacz (talk) 06:40, 27 July 2023 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
Then I guess their documentation is wrong or outdated... Thanks for testing it. — Lahwaacz (talk) 11:58, 27 July 2023 (UTC)Reply[reply]

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)Reply[reply]

Creation of a hardware team

As you might have noticed, there was significant recent activity on pages documenting hardware, especially laptops. The Laptop page guidelines have been created and all uncompliant pages have been flagged.

There is a lot more to hardware pages than just laptop pages, even if there are roughly 450 laptop pages (440 flagged, and there are a handful of good, newer ones). There are docks on the wiki, exotic USB devices, more exotic USB devices, modems and more. Also tablet PCs and apparently ARM-devices (yes User:nl6720, I agree that they do not belong here but they are still hardware pages).

Combined this may not yet be 500 pages but this is still a significant amount, this is why I propose the creation of a hardware team.

There are currently maybe two people (me and User:DerpishCat) working on hardware pages, but there should still be a central place to discuss everything relevant to hardware pages.

The goals are:

  1. Enable transparent discussions and decision making, this sounds awfully like a buzzword. But I want users to know why we do things and how
  2. Make current tasks public so others know what we need help with
  3. Coordination between users, also very buzzword-like. However it makes sense to split tasks sometimes.

The final goal we want to reach is that hardware pages are not a mess anymore. It is well-known that the wiki admins (fail to) pretend those pages do not exist since they sometimes ignore e.g Help:Style, some even violate the Code of Conduct by specifying things specific to e.g Manjaro, there is a big bunch of outdated pages and every page looks different in a bad kind of way.

-- NetSysFire (talk) 00:49, 7 April 2021 (UTC)Reply[reply]

So you want to create ArchWiki:Hardware Team? With only two team members, I think it's a little too soon for that.
If you simply want a central discussion page, you can use Category talk:Hardware.
-- nl6720 (talk) 07:59, 7 April 2021 (UTC)Reply[reply]

Abusefilter

As you all may know, the Abusefilter is currently not very helpful. It randomly marks newly registered users as spam and sometimes (not very often though) even marks new pages as spam even though they are legitimate. These are two different things, I want to specifically discuss the filter that marks new users as spam.

I am in favor of adopting the "block"list that Wikipedia uses, with a few modifcations of course. There are a few things that are just not fitting or not necessary (like the filter for football clubs) and things I would add, for example:

  • If certain derivatives (e.g Manjaro) or other distros are in the name.
  • Mentioning of the archwiki or other related projects (e.g the AUR) perhaps? As a sort of self-reference.
  • This is quite old, but since there has been harassment of Allan in the past, maybe add some well-known nicks or names to the list, too? This would also be nice to highlight anyone who potentially tries to impersonate someone.

Fortunately there is not much spam currently, but it is always good to be prepared. Wikipedia also uses a variety of other things, like ClueBot NG but these may be overkill or just not applicable. I do not know how well the bot would work here, since the ArchWiki is much more technical in nature than Wikipedia. I can imagine there may be many false positives.

It may also be possible to instantly undo edits not using a (proper) edit summary this way. This is something that is purely beneficial in my opinion. Even very minor edits should have an edit summary.

-- NetSysFire (talk) 14:50, 28 April 2021 (UTC)Reply[reply]

We should also enable mw:Extension:AntiSpoof. — Lahwaacz (talk) 07:14, 30 April 2021 (UTC)Reply[reply]
I agree with that. That looks like it will be beneficial, too.
-- NetSysFire (talk) 10:01, 30 April 2021 (UTC)Reply[reply]

How to change packaging policies

I recently made a note about the Wine Package Guidelines talk page because I want to modify them slightly. I'm new to editing here, so I was wondering if there was a proper procedure for doing this. Do I simply take initiative and watch for if people complain?

VinceUB (talk) 07:42, 5 August 2021 (UTC)Reply[reply]

Long, cluttered and hard to maintain pages

Unfortunately there are some pages on here which are hard to maintain because:

  • It is hard to validate the information without the specific hardware or software (which tends to be proprietary and may cost a lot)
  • No one knows if this still applies since the information may be ancient and the above still applies
  • There is so much content that transformed the page into something that is not feasible to maintain.

These are pages where lots of users contributed their individual solutions to and this basically spiralled out of control. The worst pages in this category are:

Other pages which are not as bad yet but should be monitored:

Both lists are unfortunately yet incomplete I suspect.

-- NetSysFire (talk) 01:23, 10 August 2021 (UTC)Reply[reply]

The same applies to almost all troubleshooting sections and pages: Network configuration/Wireless#Troubleshooting drivers and firmware, Bluetooth#Troubleshooting, PulseAudio/Troubleshooting, Firefox#Troubleshooting, NVIDIA/Troubleshooting etc. — Lahwaacz (talk) 06:56, 10 August 2021 (UTC)Reply[reply]
At least for troubleshooting sections, Help:Style#"Troubleshooting" section says to link the bug or create a bug report if there isn't any. There's nothing we can do for sections that don't include any bug links. -- nl6720 (talk) 09:50, 10 August 2021 (UTC)Reply[reply]

Syntax highlighting in code blocks

MediaWiki since version 1.21 has the SyntaxHighlight extension bundled. It adds the <syntaxhighlight> block, which lets editors add code blocks with syntax highlighting in specified language for easier readibility. As ArchWiki is a highly technical wiki, with configuration file and script snippets sprinkled everywhere, I was surprised to find this wasn't enabled yet.

Is there a specific reason for this omission? If not, I'd happily welcome this addition to the wiki. -- Zaroth (talk) 12:39, 15 February 2022 (UTC)Reply[reply]

I wouldn't say there's a "specific reason for this omission". It simply was never enabled. Even if we do get it enabled, we would not want it to be used directly in pages, only through templates. I think it should be possible to adjust Template:bc and Template:hc to add an additional parameter to specify syntax highlighting language. -- nl6720 (talk) 09:36, 17 February 2022 (UTC)Reply[reply]
That sounds reasonable, I understand that the parameter would be directly passed to the tag and would have to be one from the list of languages that SyntaxHighlight supports. Assuming that approach, I looked at the extension's parameters to check which ones also would be useful to expose via template on ArchWiki. So:
  • lang - specifies lexer to use for highlighting, e.g. python, cfg, pacmanconf or one of many others. Would be useful in {{bc}}, {{hc}}, possibly even {{ic}} (for e.g. shell one-liners, using shell-session lexer so the # prompt is correctly interpreted)
  • highlight - highlights specified line(s), e.g. 3-5, 7. I can see this being useful in {{bc}} and {{hc}} for e.g. showing context of a config file section while highlighting the important/modified lines.
  • line and start parameters enable showing line numbers and choose the start of the shown numeration, respectively. I don't see it being particularly useful on ArchWiki, especially since the highlight parameter works fine without them. If one finds a plausible usecase, I guess they could be exposed in {{bc}} and {{hc}}.
  • class, style and inline parameters control style and are already covered by the existing templates, so no need to consider them (except maybe when modifying the templates' code).
I wanted to be helpful and try my hand at drafting what the new template code could look like. However, I can't tell whether the <pre> hack used in {{bc}} and {{hc}} will still be needed with the extension enabled without trying it out. If not, this change would certainly make these templates' code easier to read and understand. -- Zaroth (talk) 10:39, 17 February 2022 (UTC)Reply[reply]
I don't think we should care about any parameter other than lang.
Also adding wfLoadExtension( 'SyntaxHighlight_GeSHi' ); to LocalSettings.php will not be enough. The extension requires python-pygments python. I think, it would need to be added to https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/master/roles/archwiki/tasks/main.yml#L20.
-- nl6720 (talk) 11:26, 21 February 2022 (UTC)Reply[reply]
Actually, I was wrong. pygmentize is shipped in extensions/SyntaxHighlight_GeSHi/pygments/pygmentize, so only python is needed. -- nl6720 (talk) 12:34, 21 February 2022 (UTC)Reply[reply]
Thinking about it more, it doesn't feel quite right to have a python binary running on the server just to provide syntax highlighting for a few code blocks. -- nl6720 (talk) 05:14, 10 April 2022 (UTC)Reply[reply]
There is another way: Highlightjs integration, which, instead of doing the highlighting server-side via pygmentize, shift the burden to the client using highlight.js. AFAIK, it's intended to be a drop-in replacement for SyntaxHighlight, so the syntax and functionality should be nearly identical. Obvious cons of this solution are:
  • not being bundled with Mediawiki, which adds more maintenance weight of downloading and updating the plugin separately
  • making ArchWiki pages heavier due to added JS
But if including Python binary is the main issue, highlight.js is an alternative to that. -- Zaroth (talk) 07:47, 10 April 2022 (UTC)Reply[reply]
It's not a real issue, but just my subjective feeling. Last time I asked, DevOps were ok with python on the server. I'll go with whatever solution other Maintenance Team members support. -- nl6720 (talk) 16:59, 11 April 2022 (UTC)Reply[reply]
I would love to see some kind of syntax highlighting extension in the wiki. However I also think it makes sense to have lang, highlight and line as options to configure. They are vital configuration options to any good syntax highlighting. Segaja (talk) 20:07, 4 July 2022 (UTC)Reply[reply]
I opened a MR to enable the extension: https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/667 ❄️❄️ nl6720 (talk) 14:22, 29 December 2022 (UTC)Reply[reply]
👍 from me for enabling with the lang parameter, line is of dubious use since every change would have to be reflected on all text referencing the line number, while highlight is clashing a little with our existing usage of bold. --Erus Iluvatar (talk) 12:38, 30 December 2022 (UTC)Reply[reply]
After some testing I got: {{#tag:syntaxhighlight|{{{1|{{META Error}}}}}|lang={{#if:{{{lang}}}|{{{lang}}}|text}}}}. The issue with it is that you can't use MediaWiki markup inside it :/ ❄️❄️ nl6720 (talk) 13:17, 30 December 2022 (UTC)Reply[reply]
Now that's something of a blocker since we rely on italics for pseudo variables :/ --Erus Iluvatar (talk) 13:33, 30 December 2022 (UTC)Reply[reply]
As pointed out by Lahwaacz, there are issues with Extension:SyntaxHighlight. -- nl6720 (talk) 09:55, 5 January 2023 (UTC)Reply[reply]

Adding code of conduct and terms of service links in the footer

According to mw:Manual:Footer#Add links to the footer additional footer links can be created by editing LocalSettings.php. I think it would be a good idea to links to the code of conduct and terms of service.

I've prepared https://github.com/archlinux/archwiki/pull/53 https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/583. Thoughts?

-- nl6720 (talk) 11:06, 21 February 2022 (UTC)Reply[reply]

I like the idea. What determines the order of the links? Can we order the three "Terms" links alphabetically? — Lahwaacz (talk) 11:16, 25 June 2022 (UTC)Reply[reply]
No idea. From what I understand, the hook simply appends. -- nl6720 (talk) 14:57, 25 June 2022 (UTC)Reply[reply]
Seems like so, it's still better than nothing. — Lahwaacz (talk) 13:57, 31 December 2022 (UTC)Reply[reply]

Improving the default MediaWiki "page changed" template

Currently, the "page you're following has been changed" emails use the default formatting. I believe this can be seen here and looking at `enotif_body`.

Current template results in this email.

My suggested template would look something more like this.

My suggestion could probably use some changes if this is to be actually done, I put it together quickly just to show what massive improvements can be gotten.

I brought this up on #archlinux-wiki initially, and it was pointed out to me that this would be somewhat of a large undertaking due to this change needing to be applied for all the translations. I can help with the Czech one if this change is desired.

C0rn3j (talk) 09:24, 5 July 2023 (UTC)Reply[reply]

Unofficial installation process

See arch-general, @Alad @M1cha

TL;DR: User:M1cha/Install Arch Linux inside OSTree was moved inside userspace as unofficial (and because it uses the author's AUR package, apparently?), and the user is perplexed as to why such guides aren't allowed. Aaron Liu (talk) 04:55, 1 January 2024 (UTC)Reply[reply]

[3] sums it up pretty well. If this kind of method is included as an alternate means of installation, it needs to be properly discussed first and made general to not rely on some user's personal scripts. -- Alad (talk) 06:45, 2 January 2024 (UTC)Reply[reply]
As explained in [4], it looks like this was a misunderstanding due to an outdated GitHub repository description. archlinux-ostree is not a "personal script" anymore, it's a generic tool that intends to support every partition scheme and usecase that is supported by Arch Linux. I've updated the guide to make the purpose of the tool more clear and have also addressed feedback from the mailing list. Please let me know, if this affects your decision. -- M1cha (talk) 18:05, 24 January 2024 (UTC)Reply[reply]

Add a rule about regulating self promotion

Self promotion, whether done "malicously" or not, has, in my view, been increasing here. It has been present in the past and will be present in the future. We do not have any rule we can refer to and that often causes unnecessary conflicts between people undoing the self promotion and the one adding it. One of the most infamous cases on here is, in my opinion, when we still had the hosting provider list in Arch Linux on a VPS, various small hosting providers have actually signed up here just to add whats essentially an advertisement to the list. But there are also cases of where developers offload their README.md here. Or advertise their freshly started, immature, very small and essentially irrelevant projects (not referring to a specific case here, I say this because there was a very recent case) in a well populated category in List of applications. No, we do not need another bash email client there. Or tar wrapper.

Proposed (and WIP of course) rules:

  • Absolutely no self promotion if you commercially benefit from it. These are advertisements and we do not need advertisements here.
    • This includes affliate links.
    • Potential edge case: What if a project dev of e.g Godot, which runs on donations, comes here and adds some utils into e.g one of the List of applications pages? It depends on the actual content of course but this sounds okay.
  • Do not put documentation for your project here. This is not a place for READMEs. However, feel free to improve already existing documentation added by your users.
  • Do not add your projects into any List of applications or similar page if the targeted category is already well populated. Additionally, avoid adding your projects while they are very small and immature, as this very often makes them irrelevant and just clutter the list.

Yes, this is harshly written but its just a proposal yada yada. NetSysFire (talk) 21:52, 1 March 2024 (UTC)Reply[reply]

The rule is a good idea since it's enforced in practice anyways.
One way of making it seem less harsh might be to present it as a "notability" requirement; after all, if there isn't commercial incentive, then I don't think the issue is with projects being self-advertised so much as them being low-quality. I also think that, above all, they should be encouraged to ask if unsure. I started out by just including the IRC channel since talk pages can go unnoticed. My take on the last bullet:
  • Projects added to List of applications or any other well-populated categories must be notable and relevant. Projects should have substantial functionality, especially if there exist well-established alternatives. If unsure, you should first ask for permission in the #archlinux-wiki IRC channel before adding a project made by you or somebody else.
As for the potential edge case, I think it can be left unspoken. I think FOSS contributors know who they are, as opposed to more traditional companies who would require some very precise word selection to properly exclude. -- CodingKoopa (talk) 02:02, 2 March 2024 (UTC)Reply[reply]
My sleep-deprived thoughts rambling, sorry y'all I can't manage to shape these into something more coherent:
  • we don't want to bore people to death with legalese-sounding bullshit
  • drive-by/first time contributors that only seek to promote their work are most of the time not providing a useful content to the community
  • we don't want to bar entry to friendly newcomers either
  • ideally a simple (but hard to evaluate) rule of thumb would be "will this addition benefit more the readers or the contributor"?
  • an other option is notability, but that blocks by default new or niche projects that could still be of interest to readers (and does not match the current content of some pages) :/
  • maybe we want to have a first barrier being "is it packaged or in the AUR"? If a project is not packaged for Arch, what's the point of linking to it from a Wiki for Arch?
  • An out of scope but related question: do we want to provide an exhaustive list of all packaged software? If yes, is a wiki page the best place for it (this will not scale and should be semi-automated, no tools exist for this yet)? If not, where do we draw the line to say what's to be listed (curation is a tough problem to solve)?
-- Erus Iluvatar (talk) 05:05, 2 March 2024 (UTC)Reply[reply]
Hi, a quick comment: the https://terms.archlinux.org/docs/code-of-conduct/#spamadvertisingsolicitation section formulates our policy and can/should be linked during maintenance activity (such as undos).
Any policies and refinement of help texts (e.g. for LOA) must base and should point to it.
--Indigo (talk) 11:31, 2 March 2024 (UTC)Reply[reply]
This is great, as it covers explicitly the "first time contributor" pattern: "Registering just to promote your issue/cause, FOSS-related or not, treats the community as a resource and is not acceptable".
Sadly, this does not cover the case that sparked the discussion (user account has roughly an edit per year since 2016), they could argue in good faith their contribution falls under "Publicity, if it is related to Arch (as a project or community) or GNU/Linux/FOSS, will usually be allowed."
Clear +1 if we make a rule somewhere it should definitely link to the CoC as its introduction.
-- Erus Iluvatar (talk) 16:51, 2 March 2024 (UTC)Reply[reply]
It should be added that cases like the latter are exceedingly rare. Adding rules that make things more complicated for everyone because of one vocal user with sparse contributions isn't great. -- Alad (talk) 14:19, 3 March 2024 (UTC)Reply[reply]
Not a wiki team member, but have some technical pinpoints.
  • It is hard to find and proof affiliation. People can switch accounts etc. Better to consider all links to proprietary/paid products as advertisement, regardless of editor affiliation and intentions.
  • "very small and immature" is relative and subjective. In fact we have very small projects even in official repos (with 1-digit GitHub stars, non-existent sourceforge downloads etc.). Blocking niche projects is not good IMO, think of how only minoity of users need specialized tools like HEX-editors, this does not mean they shouldn't exist. Not saying that desktop Linux itself is a minority.
  • Instead, we could consider all newly created users (users without other submissions) as potentially malicious.
  • AUR package should be pretty much a requirement. With that we automatically apply rules from AUR submission guidelines, like presented software should be useful for others etc. Also easier to check and control. Same as above, all fresh packages from new users (no other noticable packages maintaned) could be considered as potentially malicious.
Hanabishi (talk) 15:24, 2 March 2024 (UTC)Reply[reply]
  • Funnily, most of the time there's no hiding from the people who do self-promotion behind a sockpuppet. The issue with a blanket ban for proprietary/paid products is it would "contradict" existing notable pages, e.g. Minecraft. It's a regular occurence but probably not the main/only metric we should rely on.
  • IMO the distinction between "small and immature" and "niche" is both in the notability for their specific use and the duration for which the project has existed. Although it does not mean we necessarily should have a blanket ban on new projects either.
  • We're not on Wikipedia, but "don't bit the newcomers" comes to mind: most new contributors will be making minor mistakes and we should not punish them for it, if we're not welcoming we'll be dead sooner rather than later. Edits from newcomers and learners should still be met with some scrutiny though.
  • I'm happy to see I'm not the only one thinking that the packaging status of a project is a good way to measure its relevance to Arch :)
-- Erus Iluvatar (talk) 17:03, 2 March 2024 (UTC)Reply[reply]
  • I should have clarified that it is not about well-known and widely adopted products. Of course mentioning Minecraft or Discord doesn't count. Only linking some shady like it's already done in https://wiki.archlinux.org/title/Talk:AUR_helpers stuff, or with unclear purpose.
  • True. Although, it is hard to formulate some distinct criteria for that.
  • It is a simple sanity check. If user's first message is a bunch of links to random websites and software, seems reasonable to be cautious about it.
  • Yeah, it is at least one more indicator that the user is not just passing by.
Hanabishi (talk) 18:32, 2 March 2024 (UTC)Reply[reply]
I can understand the reasoning but don't think it's worthwhile overall.
  1. The commercial part is covered by the code of conduct.
  2. Encouraging authors to document their projects upstream seems reasonable at first. (I remember a case where someone created an article for a picom fork they created, with most content copied, and the project eventually dying out.) The obvious place to add this would be Help:Editing#Creating_pages. This creates an ambiguity however: what if the project is an Arch project? Is it prohibited to document it on the wiki, even though it is clearly relevant to Arch?
  3. It's fine to have notability criteria for specific articles, where what is notable and what isn't can be clearly defined. This is already done in some articles like AUR helpers. However, doing the same in general is difficult. See the complex legalese in w:Wikipedia:Notability for example.
Package requirements are already mentioned in the first paragraph of List of applications:
This article is a general list of applications sorted by category, as a reference for those looking for packages.
If a project is added without Arch package, AUR or otherwise, they can already be removed with that reason. And by AUR submission guidelines, a package can only be on AUR if it's useful in some shape or form. If an existing package is removed because it isn't useful, it can be removed from List of applications.
-- Alad (talk) 14:05, 3 March 2024 (UTC)Reply[reply]
That works for the List of applications, but we have other pages where there already are un-packaged projects listed: I'm not against keeping the status quo, but I don't like that we have a kinda "grey area" that opens the door for arguments when we revert things that seem out of place.
Maybe a blanket "No self-promotion, ask for approval by a Maintainer or Administrator in the talk pages" with a link to the CoC? It will probably not be a worse workload than what we're doing today :P
-- Erus Iluvatar (talk) 18:42, 3 March 2024 (UTC)Reply[reply]
Strictly speaking I'm fine with removing project links, if there was no AUR package added in a reasonable time frame. It's a sign upstream or their communities have no real interest in Arch. That being said, it's unclear if this is actually beneficial to users. Category:Pages with missing package links shows relevant projects (e.g. borbpdf in PDF,_PS_and_DjVu#Python) that someone could easily pick up and package for Arch, should they not be satisfied with the packaged alternatives listed.
It's true that the "transitive notability" no longer holds in that case. Perhaps we could hint in ArchWiki:Contributing that "self-promoted" content may be deleted without warning, e.g. in ArchWiki:Contributing#Improving. This might be throwing out the baby with the bathwater, though, since one of the core tenets in Arch is sharing of new projects to the community, i.e. [5]. A blanket ban on "self-promotion" would be like requiring explicit approval from the forum moderators before a topic in Community contributions can be published. -- Alad (talk) 21:59, 3 March 2024 (UTC)Reply[reply]
Maybe simply adding a reminder to read the CoC in ArchWiki:Contributing would be enough, a the only link to it is in ArchWiki:Contributing#The 3 fundamental rules through "respect" while the CoC covers more than that.
-- Erus Iluvatar (talk) 22:04, 3 March 2024 (UTC)Reply[reply]
Another link to the CoC is on the Main page, but yes. Personally, I'd see adding a reference, e.g. of unwanted behaviour in the Archwiki:Contributing#The 3 fundamental rules warning as overdoing it (IMO too much of a negative connotation when we're happy for new users contributing and 'respect' links to the CoC in the first sentence of the section), but if it becomes a more wide-spread issue in the future, that may be a place.
I suggest to
edit: after second and third thought, I now think you're right - the link is too sublime. I'd add the following:
  • Let the CoC start the Archwiki:Contributing page with a plain statement like "The Arch Linux Code of conduct governs all projects." and change the 'respect' link to point to respect, which encompasses both the three rules and the topic at hand.
--Indigo (talk) 13:31, 8 March 2024 (UTC)Reply[reply]
Sounds good to me, unless someone is against it I'll make the change in a few days :)
-- Erus Iluvatar (talk) 14:00, 8 March 2024 (UTC)Reply[reply]
Done and done :) --Erus Iluvatar (talk) 10:00, 16 March 2024 (UTC)Reply[reply]

Disabling (some) archival redirections

Many articles of old software or old advice are archived. This is understandable.

My suggestion is instead of redirecting to ArchWiki:Archive, do this instead:

1. clear the content of the original page

2. insert the intro stated in ArchWiki:Archive

3. explain why the page was archived or why the software was deprecated.

4. explain alternative software or articles to the archived one

Example: upower is an archived page, but as a user wanting to learn more about it, the redirection is not helpful. It would make more sense if the article explained these four things I listed.

Sure, the user can manually go to article history or see the discussion page, but why go through this instead of summarizing the current state of the topic? AvidSeeker (talk) 07:41, 5 March 2024 (UTC)Reply[reply]

It's an interesting suggestion. Yet, our archiving process to give the reason in the Template:Archive in the first place, as well as find a suitable redirect target. Basically it would mean to create a stub page (similar to those in Category:Disambiguation pages) for an article with the same info for (3) and research for (4).
Let's take your example: Upower was redirected itself to pm-utils for years, which was archived too. A replacement could be a sentence referring to upower(1), a redirect to Power management but the redirect has only an indirect upower reference to an aur package (which is probably why it was not created), or a stub page with both. What else would you include in its stub page?
--Indigo (talk) 20:31, 5 March 2024 (UTC)Reply[reply]
Unlike redirects, stub pages clutter the search results and category pages. Somebody would also have to maintain these stub pages to ensure that the additional hints are correct. This is pretty useless since most of the time people are not interested in outdated, historical information. If we expect that many people are still interested in a particular topic, we would not archive the page in the first place. — Lahwaacz (talk) 12:14, 10 March 2024 (UTC)Reply[reply]
Then how about mentioning the reason in the discussion page of the archived pages? This way no stubs are created and users don't need to browse history to see the reason and alternative. --AvidSeeker (talk) 13:55, 15 March 2024 (UTC)Reply[reply]
This way you create stub talk pages and the rest of my argument still applies. — Lahwaacz (talk) 17:05, 15 March 2024 (UTC)Reply[reply]
How about redirecting archived articles to alternatives OR if no alternatives exist to a section of a non-archived article that explains why tool X was deprecated. E.g: netstat is deprecated but it redirects to Network_configuration#Investigate_sockets section which provides the alternative OR explains the reason for deprecation. No stubs will be harmed in this process. AvidSeeker (talk) 19:41, 15 March 2024 (UTC)Reply[reply]
We are already considering redirects to other existing pages before the archival according to the procedure in ArchWiki:Archive#How to archive a page. If you find that something was missed or that some topic came alive, feel free to suggest a better target for the redirect, but we are not going to do this for all archived pages just to add a reason why it was archived.
Closing as the upower page, which lead to starting this discussion, was changed this way and none of the suggested alternatives are acceptable.
Lahwaacz (talk) 07:01, 16 March 2024 (UTC)Reply[reply]
Stub talk page are not more accessible to a reader than simply looking at the page history. Also, if you're already discussing a topic, finish the discussion and reach a consensus before making changes to pages related to said discussion. Erus Iluvatar (talk) 18:24, 15 March 2024 (UTC)Reply[reply]