Well, of course we can mention it, however Special:RecentChanges does show newly created pages too, so patrolling Special:NewPages could be presented as a less demanding task for those who would like to patrol but don't have enough time to cover all the recent changes. We should probably restructure the article a bit, or add a new section? Do you have any ideas? -- Kynikos (talk) 14:21, 25 February 2014 (UTC)

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:

I'd like to rename the "Maintainers" group as a more commonly recognized "Moderators".

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.

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

Note mostly to myself, Wiki Monkey has some feature requests that are related to this restructuring: #175, #176, #197 and #198.

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.

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.

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.

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:

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

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)

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.

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)

Automatic sorting

Starting from Sunday 4 May, the list of maintainers will be sorted every Sunday automatically by User:Kynikos.bot in descending order by the number of edits made in the previous 30 days (current values are in Special:ActiveUsers) plus the number of edits made with any associated bot accounts in the same period.

Reasoning:

The users at the top of the list are more likely to be contacted for generic questions, and the most active maintainers are more likely to be up to date with the current wiki status, procedures and conventions, so their answers can in general be more accurate.

In accordance with the concept of meritocracy this will give more credit to the users that spend more time and effort than the others to maintain the wiki, in particular listing the inactive ones at the bottom.

I agree that it can be confusing for users approaching the ArchWiki from experiences on other wikis to see from that page that there are dozens of users with administrator rights but in fact only a handful actually act as wiki admins as they are commonly perceived on e.g. Wikipedia.

However I think the proper way to clarify this is the natural MediaWiki's way: creating more specific user groups (which should still inherit the rights from the administrators group), like it happens on Wikipedia and in analogy with what happens on our Forums. Unfortunately this would require the good old FS#35545 to be solved first.

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)

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[4] (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.

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.

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.

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.

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

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

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)

How to archive templates

Now I'm not sure what archived templates should look like. If they redirect to ArchWiki:Archive like normal pages, its transclusions will be completely wrong. Somebody could use it in the future by mistake, and I think it would also affect browsing the history of pages that transcluded it in the past. -- Lahwaacz (talk) 16:47, 8 February 2016 (UTC)

Interesting question. Now that history is freshly filled with the resolved deletion transclusions, how about one dares to ArchWiki:Archive the Template:Deletion as a test case to have a look at revision examples? -- Indigo (talk) 18:15, 8 February 2016 (UTC)

Hmm I agree that archived templates shouldn't be usable anymore => they should be removed from the Template namespace => they must be renamed to something else: I was thinking about adding some sort of symbol after "Template", maybe change them from "Template:Something" to "Template~:Something", so their titles still appear where one would look for templates.

To be frank, this sounds a bit overcomplicated. Is there really much use in keeping these old templates available? They're not article content to be possibly restored later, and are typically only deprecated after careful discussion. -- Alad (talk) 16:36, 9 February 2016 (UTC)

To me any mw:Transclusion#Transclusion markup magic sounds like too much effort and broken transclusions not to worry about too. I like the idea of simply renaming when moving them. Deprecation is usually discussed in the template's talk page, why not handle them as everything else. Further, a simple renaming rule for such could be applied in other cases as well, e.g. DeveloperWiki, if wanted. Perhaps prepending something is a simpler rule, e.g. "_Template:Something", "_DeveloperWiki:something". -- Indigo (talk) 18:22, 9 February 2016 (UTC)

The colon does not need to be replaced, but underscores are treated the same as spaces and page title cannot start with a space, see mw:Manual:Page title.

They could also be moved as subpages of some central page (e.g. ArchWiki:Archive) or even into separate Archive: namespace (as was one of the original suggestions). Or we could just leave them in place and replace the content with something like {{Archived template}} flag (see how mediawiki.org does this for extensions: mw:Extension:ABC), which would also do the <onlyinclude> magic. And then why do this only with special pages and not with all of them? (Seems like we're at the beginning again, sorry about that...)

Discarding the transclusion markup idea, that I mentioned only for completeness' sake, but didn't like in the first place, I've given an example of how I think Templates can be archived with the now-called Template;Wikipedia (thanks Lahwaacz for fixing its remaining transclusions). I think changing the colon to a semicolon is the most natural thing we can do: I've updated the procedure accordingly.

Archiving a Template (or a Category) is not something we are going to do every day, probably not even every month, so I don't think that the procedure os "overcomplicated", i.e. not worth it: I think saving months, when not years of contributions that had been part of the wiki's life until then, is enough to justify the little more time needed to move the page when archiving it.

I don't like the idea of using a completely new Archive namespace (I suppose Lahwaacz meant to use it in every case, not only for Templates/Categories): we can easily do without, and if we implemented it, we'd have to always rename a page when archiving it. I don't like the {{Archived template}} flag idea either because then the archived pages would still appear e.g. in Special:SpecialPages lists.

Ok, I can see what you mean on the extra mile. I'm still not convinced on using a semi-colon (or generally renaming templates) - IMO, it's difficult to spot the difference with regular, semi-colon templates at first glance.

Revisiting Lahwaacz's suggestion: a "deprecated archive" template doesn't involve renaming, keeps the history of the template, and explicitely directs users that a template is deprecated: w:Template:Deprecated_template. Consequently old revisions look cleaner, rather than just have a red link to a (now moved) template.

It would also offer better seperation between archived content (articles) and formatting (templates).

Arguably, new revisions may still end up using the template (only showing a warning text). However, considering how few templates in recent use the problematic applies to - particularly when we redirect, rather than archive, Template:Deletion - this shouldn't be a problem. We also clean up backlinks before deprecating templates, as a general rule.

edit: I don't have a suggestion on Special:SpecialPages. However in this case I believe the benefits outweigh the drawbacks; the arguments above are from a user's perspective, and the Special: namespace is mostly our turf ... -- Alad (talk) 13:06, 10 February 2016 (UTC)

I don't want to insist obstinately of course, so if you guys prefer archiving by tagging rather than by redirecting, I'll be fine with it, no worries.

Probably the most affected special pages will be Special:UnusedTemplates and Special:UnusedCategories, as their archived members will grow in number in the long run. There's a quite smart solution we can use for this, though, i.e. self-transcluding the archived templates, and self-categorizing the archived categories: this will keep them off the Unused* special pages.

But now I'm thinking, if we use a "Deprecated" template for such pages, why not just be consistent and use it for any page, and maybe just call it generically Template:Archived?

True, I think the most affected special pages would then be Special:DeadendPages (no, self-linking doesn't do the trick in this case), Special:LonelyPages and Special:ShortPages; also, it will be more difficult to find unused templates in Special:MostTranscludedPages (those that self-transclude them as an example), and Special:Categories will show everything too, but these shouldn't be real problems. At ubuntuusers.de they also move the pages as subpages of the main Archive page by the way (plus leaving the content visible including all the links). There are advantages and disadvantages on both sides, can Lahwaacz confirm that, after the latest considerations, he's still in favor of the Template:Archived solution? If so, I won't object at trying it, as now I'm getting undecided myself... — Kynikos (talk) 08:57, 13 February 2016 (UTC)

Lahwaacz is undecided yet. As Alad mentioned first, is there really much value in keeping deprecated templates around? Would having a multi-choice vote among administrators help to advance this discussion forward? -- Svito (talk) 13:00, 9 June 2018 (UTC)

Hi, scrolling recent changes here, I'm not sure about a couple of moves today. For example, User:Thestinger/Nessus. It has a dozen contributors over years, software is uptodate & article covers some specific info, a Nessus_(Русский) translation exists too. Why does it not have enough flesh to stay in Main? --Indigo (talk) 19:14, 17 August 2017 (UTC)

Hi, the installation note is superfluous, if you are interested in how a PKGBUILD file works, read it; when a PKGBUILD does a silent HTTP request this should be fixed. The post-installation setup section is unnecessary as the localhost page tells you to do that anyway. The service name and the localhost URL are echoed in post_install. The removal note should be echoed in post_remove. So the few info that's there can just be echoed during installation / removal and doesn't require an article. I now commented my suggestions at the AUR package.[6] --Larivact (talk) 05:25, 18 August 2017 (UTC)

Thanks, all good reasons, and good move to suggest the improvements to the AUR package. Yet, consider the following: (1) How did you come up with the improvements for the PKGBUILD? Without installing the package or scrolling years of comments, the info in the article helped you. You sure are right it is better served in the PKGBUILD, but it is not there yet - and if you did not explain here, the move reasons would not be transparent. (2) What may happen in six months, if another user sees there is no article on Nessus yet? S/he may create one from scratch, rather than improving an existing (fixing style and removing then superfluous info), or reconsider after finding the previous one via a Template:Archive). (3) Since User pages are not indexed in our search, there is no direct way to find the current one. Moving it like this also leaves translator teams in a flux figuring why the original is gone.

I'm appreciating your effort to clean-up too, please don't think otherwise. I'd like to make another suggestion: We have Template:Stub and want to archive it. The problem is that it is still used in many articles, Special:WhatLinksHere/Template:Stub. Among these will be clearer cut candidates for archiving/Template:Merge for otherwise useful info/move to user space (the latter should be primarily for articles a single contributor started but never got round to bringing it to a full article). Cheers. --Indigo (talk) 08:28, 18 August 2017 (UTC)

Thanks, I wasn't aware of the confusion I caused. I moved the articles to the User namespace since I didn't get archiving - I thought it was a dedicated feature. I'll undo my recent moves. --Larivact (talk) 18:27, 18 August 2017 (UTC)

So do we have a uniform strategy on when to Archive something and when to move something back to the original author's user page? E.g. [7], [8], [9] would fall under the above "single contributor" criterion...

I'd say if it has only one contributor (excluding translators adding language links, bot edits etc.) and it is not very old (e.g. up to 1 or 2 years), then move it to the user namespace, otherwise archive it. -- Lahwaacz (talk) 19:36, 18 August 2017 (UTC)

Sounds good to me. While it can get arbitrary, I'd also exclude simple fixes done by staff to help a new article to par style-wise.

I'd make it depend on the current amount/quality of information. When something is only a short stub / a style mess it's not really worth archiving. On the other hand when we deal with all such pages and monitor new pages the two year rule should work.--Larivact (talk) 15:13, 23 August 2017 (UTC)

Also note that when a page has dozens of contributors and it's still "a short stub / a style mess", it's not really worth moving to the subpage of the first editor. If something's not worth archiving, we might as well delete it. -- Lahwaacz (talk) 16:43, 23 August 2017 (UTC)

I've started deleting pages that are either irrelevant to Arch (e.g. ArchAudio which was some random third-party project, now dead) or are "stubs" without meaningful contribution (e.g. Bankid). @Larivact: great work on the categorizing/cleanup you're doing btw. -- Alad (talk) 10:29, 24 August 2017 (UTC)

N.B. If there's a related page (such as a modern replacement), it's likely better to redirect pages there rather than delete or archive them. All this does show there's gaps in Help:Procedures#Remove an entire page and I agree to expand it. -- Alad (talk) 10:36, 24 August 2017 (UTC)

I absolutely don't want to duplicate ArchWiki talk:Administrators#Should we remove or archive obsolete articles? here, but my position is that for the moment the issue is regulated by Help:Procedures#Remove an entire page which only considers deletion in case of "spam or other clearly malicious content". I think that all contributions that made it to stay published for long periods (ArchAudio even since 2009) are part of the history of the wiki and should not be deleted. I don't see the advantages of deleting except when in need to censor the content; the data is not actually removed from the database, so it's not even a relief for the server, as small as it would even be, and I still regret having the habit of deleting pages and especially discussions before the only (and I hope last) occasion in which the deleted articles were actually purged from the database without any warning. -- Kynikos (talk) 17:40, 26 August 2017 (UTC)

In the case of ArchAudio I would say it never belonged on the wiki in the first place, or classifies as spam. See [10] which raised the original concern but was closed arbitrarily by two users. In the other cases I agree they might as well have been moved back to the user namespace. -- Alad (talk) 12:54, 27 August 2017 (UTC)

Topic is closed but I do think some pages should redirect/merged to List of applications. I am now reviewing pages moved to user namespace and do the work if approprite. -- Fengchao (talk) 06:13, 5 September 2017 (UTC)

It happens quite rarely so I don't think a dedicated policy is needed. Usually a warning is issued when a user goes against the code of conduct, and should he disregard it, he is banned indefinitely. In this particular case it applies even more, as that same user was already banned on BBS for exactly the same behavior, and he's very likely to repeat it after his return.

Side-note: you may also want to set the "block email" and "prevent user from editing talk page" flags when issuing bans. -- Alad (talk) 22:17, 28 January 2018 (UTC)

Scribunto

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.

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.

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

Namespace for developers' pages

There are many pages grouped with the DeveloperWiki: but which are technically not in a separate namespace. We should create a true MediaWiki namespace, but we should probably use a different prefix for technical reasons - any ideas?

As for the technical reasons: although there is a maintenance script to deal with existing pages after creating a namespace), it handles only existing pages and not the archive table. There is most likely more, I guess it's not really a tested solution.

I can't think of much better names, maybe just "Developer" or "Development". However I was thinking that renaming all those pages may break many external links, since that prefix has been used forever, so as an alternative we can sort of follow mw:Manual:Using_custom_namespaces#Move_conflicting_pages, coordinating the creation of the namespace like this:

Prepare a bot to move all the pages; I can easily make a plugin for Wiki Monkey, or it should be easy also with wiki-scripts;

Submit the LocalSettings PR but don't merge it yet; agree instead on an exact date/time when the patch will be merged;

A few hours before the patch is applied, move all the pages to a temporary prefix with the bot;

Sentence case in team name

Then the others should also be renamed to be consistent with the rest of the wiki. --Larivact (talk) 16:21, 3 November 2018 (UTC)

Rearrange sections

I think people visiting ArchWiki:Maintenance Team should see the list of existing members before the "How to join". I propose placing the active/inactive Maintenance Team members in a common section and moving it before the "How to join" section.