Difference between revisions of "ArchWiki talk:Administrators"

From ArchWiki
Jump to: navigation, search
m (Removing unnecessary redirects / pages: add Google chrome)
m (Removing unnecessary redirects / pages: add Intellij idea‎)
Line 267: Line 267:
 
* [[Openjdk]]
 
* [[Openjdk]]
 
* [[Google chrome]]
 
* [[Google chrome]]
 +
* [[Intellij idea‎]]
  
 
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 06:14, 30 September 2018 (UTC)
 
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 06:14, 30 September 2018 (UTC)

Revision as of 15:58, 9 October 2018

Meaning of Administrator

[Split from #Automatic sorting. -- Kynikos (talk) 12:36, 4 May 2014 (UTC)]

One more thing, it might be useful to describe the difference between this list and [1]. I assume those not listed here are the (former) devs? -- Lahwaacz (talk) 06:12, 4 May 2014 (UTC)

The users with administrative rights not listed here are Developers, Trusted Users, Arch Fellows, Forum Admins etc.
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.
-- Kynikos (talk) 12:38, 4 May 2014 (UTC)
wikipedia:Wikipedia:User access levels is really great. With the current scheme, creating an equivalent for ArchWiki does not make much sense, but it should be considered in case more groups are created. -- Lahwaacz (talk) 19:05, 5 May 2014 (UTC)

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)

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

Cite extension

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

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


Some text<ref name=myRefName />

== References ==

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

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

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

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.
An alternative, which I like less, would be to leave them as they are, but instead make ArchWiki:Archive transclude safely with some mw:Transclusion#Transclusion markup magic.
The old revisions of articles have always looked "broken" because of the various template modifications, that's not something that archiving has introduced :)
A similar problem exists for Categories, of course, maybe they should be renamed as well.
Kynikos (talk) 13:29, 9 February 2016 (UTC)
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)
edit: forget about the prepending, I missed the namespace colon ":" needs replacing anyway.Kynikos' rule now seems simplest to me, perhaps using an underscore instead of hyphen. --Indigo (talk) 18:35, 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...)
-- Lahwaacz (talk) 18:54, 9 February 2016 (UTC)
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.
Kynikos (talk) 08:38, 10 February 2016 (UTC)
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.
-- Alad (talk) 12:39, 10 February 2016 (UTC)
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?
Finally, with a "Deprecated" or "Archived" template, ArchWiki:Archive should be merged into Category:Archive.
Kynikos (talk) 03:31, 11 February 2016 (UTC)
Self-transclusion is smart indeed. Regarding Template:Archived, to me that's two birds with one stone, i.e. it would also solve the issue with (double) redirects. For some inspiration, a wiki that uses this approach (together with page protection for Archived pages, cf #Restoring revisions and redirection) is [3] (translation). -- Alad (talk) 09:05, 12 February 2016 (UTC)
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)

Deprecated templates

See deprecated templates here, see Article status templates, Should these be translated and How to archive templates. -- Svito (talk) 01:08, 26 July 2018 (UTC)

Is moving pages to user space a good idea?

Some pages in my watch list are deleted. Dig into the history, found some are moved to user namespace without leaving a redirection.

Pro:

  • Make Arch wiki main namespace clean.

Con:

  • The page is complete gone, some user may re-create it without knowing it exist before.
  • Information in user namespace is hard to find and reuse.
  • Some pages should merged to List of applications but it is harder to track them now.
  • New contributors will have very bad feeling and may stop here.

I think we should restrict such edits and use page flag template instead.Thoughts?

-- Fengchao (talk) 06:59, 5 September 2017 (UTC)

[Copied from User talk:Larivact. -- Fengchao (talk) 10:07, 2 July 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.[4] --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. [5], [6], [7] would fall under the above "single contributor" criterion...
Also I'll take advantage of this to remind ourselves of the behemoth discussion ArchWiki_talk:Administrators#Should_we_remove_or_archive_obsolete_articles.3F which is not yet completed. -- Alad (talk) 18:55, 18 August 2017 (UTC)
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.
@Larivact: thanks again. --Indigo (talk) 17:10, 19 August 2017 (UTC)
I agree too with Lahwaacz's proposed guidelines, we can make them official in Help:Procedures#Remove an entire page. Sorry I don't have time to resume ArchWiki_talk:Administrators#Should_we_remove_or_archive_obsolete_articles.3F at the moment. -- Kynikos (talk) 09:39, 20 August 2017 (UTC)
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 [8] 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)

Policy on abuse/blocking users

Hi all, do we have a policy on blocking users?

The reason I ask is Special:Contributions/LennartD who has been vandalizing systemd. I've given him a warning after the first edit and banned him for a week after the second.

Lonaowna (talk) 18:55, 28 January 2018 (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)
Got it, thanks! -- Lonaowna (talk) 23:52, 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.

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

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

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

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

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

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

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.

-- Lahwaacz (talk) 21:14, 17 September 2018 (UTC)

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:
  1. 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;
  2. Submit the LocalSettings PR but don't merge it yet; agree instead on an exact date/time when the patch will be merged;
  3. A few hours before the patch is applied, move all the pages to a temporary prefix with the bot;
  4. Wait until the patch is merged;
  5. Move the pages back with the bot.
-- Kynikos (talk) 17:46, 18 September 2018 (UTC)

Removing unnecessary redirects / pages

Unnecessary redirects (because of linktrail):

Ambiguous redirects:

Redirect to user page:

Accidentally created:

Archived categories:


Lowercase redirects without usage / history:

--Larivact (talk) 06:14, 30 September 2018 (UTC)

Groups & Users used to have content before they become redirects, the pages should be archived instead of removed. -- nl6720 (talk) 07:31, 30 September 2018 (UTC)
In that case they should stay redirects. --Larivact (talk) 07:36, 30 September 2018 (UTC)