ArchWiki talk:Maintenance Team

From ArchWiki
Jump to: navigation, search

New pages patrolling

I have the feeling that Special:NewPages is somewhat overlooked in regard to patrolling. It should be definitely mentioned on this page, here are a few common mistakes that should be looked for:

More detailed investigation is probably also in order...

-- Lahwaacz (talk) 19:49, 24 February 2014 (UTC)

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)
I read just Special:NewPages along with Special:DoubleRedirects and Special:BrokenRedirects. I don't have time for more.
I don't think we need to mention them explicitly. -- Karol (talk) 14:57, 25 February 2014 (UTC)
Well, a link to Special:NewPages is now easily accessible from the sidebar, see MediaWiki talk:Sidebar#Link to NewPages?. -- Kynikos (talk) 10:15, 27 February 2014 (UTC)


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

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

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

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

Point 1) Sounds good to me.
Point 2) Agreed.
Point 3) I think that's a good idea. In so doing, that would ensure that the admin talk page is freed up for purely administrative discussions.
Point 4) Personally, I agree with the removal of the reports page. The people who are most likely to be able to fix issues for a particular article are probably the people who keep track of that article's talk page. I don't think that trying to centralize issue reporting achieves much.
Points 6 & 7) Agreed
-- Chazza (talk) 10:11, 7 May 2015 (UTC)
1,2,3. Also agree, this matches the BBS title "Forum Moderator". We could perhaps ask Jason to update the profiles of maintainers with a BBS account
4,7. I'm neutral on this... I think having ArchWiki:Reports as a central place for edits offers a better overview than WhatLinksHere, Recent Talks, and whatnot, also considering the table format. But perhaps I'm just lazy. :)
6. Yep, and not including active members as well. -- Alad (talk) 19:10, 7 May 2015 (UTC)
Also agreed. W.r.t 4 & 7, we might also try to generate some lists/tables based on the status templates and make a nice, sorted, filtered and ranked report e.g. once per month. Extracting the original flag date would be probably difficult, but perhaps not impossible.
Is it also the time to consider ArchWiki_talk:Administrators#Meaning_of_Administrator at this point?
-- Lahwaacz (talk) 19:27, 7 May 2015 (UTC)
About 1, I'm adding that it has to be done in 3 steps: create the moderators group, then move each maintainer to moderator, and finally delete the maintainers group.
Of course point 4 is the most controversial, replacing it with some kind of fully automated log/report would be ideal, but IMO it can be implemented later on. @Alad: I understand your concerns, but the benefits of always reporting directly in the articles' talk pages are quite clear now that talk pages seem to be much more watched than they were in the past (also thanks to the fact that IIRC finally MediaWiki is adding modified/created pages to watchlists by default for new users), and if we start doing that, keeping ArchWiki:Reports would mean having to do at least two edits for each report (or three if a status template is added), so that's why I proposed deprecating it; as I said, I will try to update Wiki Monkey to automate the new reporting procedure as much as possible, and I guess I could still have it append entries to ArchWiki:Reports too, but the problem would be keeping the table in sync with the linked reports in the talk pages... I'll think about it.
ArchWiki_talk:Administrators#Meaning_of_Administrator could surely be implemented in this article, it's very related indeed.
Kynikos (talk) 14:21, 8 May 2015 (UTC)
I'm ok with everything, but +1 to keep (4) the reports. There is no question that you are right, items should be handled in the respective article's talk pages - the sooner, the better. Yet, I believe this is done anyway by all and the current reports are only a residual. I find it valuable to keep this as an opportunity (also for the visible quicklink), at least for some time. Reason: Imagine someone patrols a problematic in recent changes but the article is outside the own interest/ expertise and/or time to open a proper talk item (which would often be more elaborate than the report comment) is sparse. It would be a pity, if it is foregone or tracked in the backhead todo list only.
How about doing it like you propose, but changing procedure for the reports that may still be opened: They could be moved directly by anyone (incl. the creator on return) to the respective talk pages. If we then see the list stays tiny, it can be fully deprecated. --Indigo (talk) 19:07, 10 May 2015 (UTC)
My idea (which I hadn't eleaborated yet here) was to allow the creation of quick reports (also automated with Wiki Monkey) in articles' talk pages similar to the current entries in ArchWiki:Reports' table, probably also using a template to stress the fact that the comment has been added quickly and the reporter may only be confused about the edit and in need for confirmation. I'll use an existing report from ArchWiki:Reports as an example of how it could look instead in the affected article's talk page:

Quick report

[This is an automatic report about, please help reviewing it]
Comment: I'm not qualified to check the content, but style is poor regardless. -- User, Timestamp
The whole thing could be manually added simply with:
{{Report||I'm not qualified to check the content, but style is poor regardless.}} -- ~~~~
The link to ArchWiki:Reports (the "report" anchor text) could be useful to list all the open reports with a search like since it's unlikely that Talk pages link there for other reasons.
If using Wiki Monkey, more details could be added automatically, e.g. the timestamp and author(s) of the edit(s), Special:Diff could be used instead of the full link, and it could create the report in full text (i.e. like using the template with subst).
Kynikos (talk) 10:54, 11 May 2015 (UTC)
Now in this case I'd like to nominate "(4) to deprecate Archwiki:Reports" for the Archwiki Understatement of the Year(TM) category. No, really - ace idea. That would be an ingenious enhancement imo. --Indigo (talk) 21:48, 11 May 2015 (UTC)
Yeah sorry, my original idea was still very vague, replying to your post has given me the chance to develop it into something that could actually work, although it would still need some refinement. I'm glad you like it, hoping that you weren't sarcastic of course :P Maybe we can see what the others think of it too, since I'm sure you're not the only one who didn't imagine that (4) was about something like that... — Kynikos (talk) 15:55, 12 May 2015 (UTC)
For the moment I've done points 6 and 7. — Kynikos (talk) 03:43, 24 May 2015 (UTC)
I think you got it, but of course it was not sarcasm, just trying to make a funny remark. Your idea with the quick report is great lateral thinking. One small reservation I have is about using a Template for it. We all know the hazzle of template breaking characters and I wonder if it might be cumbersome to use a template, but that can be seen. In any case it should be useful to get forward with a decision on where to go with the reports. Anyone else want to share an opinion on (4)? --Indigo (talk) 20:14, 29 July 2015 (UTC)
Eheh I got it I got it, thanks for confirming your support. I think the quick report would only be for short messages, like those in ArchWiki:Reports' table, which are probably even worse when it comes to breakability, so unsupported characters wouldn't be an added problem. I suppose that if somebody wants to reply to a new-style quick report, they can do it below (i.e. outside of) the template, like in a normal discussion.
I don't think we'll find many more people interested in replying, anyway I'm waiting to find some time to update Wiki Monkey's plugin, that's probably my main reason for delaying (4).
To complete the status update, (5) will come with (4), while (2) and (3) practically depend on (1), which in turn is on the shoulders of who is currently maintaining the back-end, even though it's a micro patch.
Kynikos (talk) 20:54, 11 August 2015 (UTC)
Even if the WikiMonkey additions aren't completed yet, I'd now suggest to deprecate ArchWiki:Reports rather sooner than later. Over the course of the year, it has hardly seen any usage, and old reports which are long fixed amassed on the page. -- Alad (talk) 12:49, 13 September 2016 (UTC)
I'm still on with this plan. About Wiki Monkey (and my other software projects) I should be able to resume allocating some time within a couple of weeks, without promising anything, but yes, I don't want it to be a blocker for this idea. — Kynikos (talk) 10:51, 14 September 2016 (UTC)
I've flagged the page for archiving for now [1]; it should be straightforward to translate the few remaining reports to article templates. We can do the actual redirect once WikiMonkey is updated -- take your time. :) -- Alad (talk) 11:40, 14 September 2016 (UTC)

Regular Wiki Cleanup Days

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