Help talk:Procedures

Deal with talk pages after redirecting a page to another

After seeing [1], and in light of ArchWiki:Requests#Should we remove or archive obsolete articles?, I'd like to propose to amend Help:Procedures#Deal_with_talk_pages_after_redirecting_a_page_to_another so as to discourage deleting the original title. This is my proposed new wording:

---

If page A has been redirected to page B, for example after merging the content of A into page B, and Talk:A exists:

• If Talk:B does not exist, move the entire Talk:A to Talk:B, letting MediaWiki automatically redirect Talk:A to Talk:B.
• If Talk:B exists:

1. Move all the existing discussions from Talk:A to Talk:B, using one or multiple edits with proper edit summaries.
2. Redirect Talk:A to Talk:B.
3. Among the discussions just moved to Talk:A, close those that are no longer relevant due to the restructured content.

---

— Kynikos (talk) 01:36, 2 January 2016 (UTC)

This may be a nitpick, but I'd like to avoid moving discussions from one page to another, just to be closed there and deleted (c.f. User talk:Alad#Talk pages of redirects). This is useless especially if Talk:A is not going to be deleted, so the content will be available for everybody in the history. -- Lahwaacz (talk) 10:16, 2 January 2016 (UTC)

Yes, I too thought of that problem, however the alternative would be to do close the old discussions on the old page, but in that case technically we wouldn't be able to redirect the page immediately because of the 7-day policy; we'd only be able to still mark the page for deletion like we're doing now, and then redirect it instead after one week. Of course let's keep in mind that it doesn't happen often at all to have to merge two talk pages, so this is a minor issue in any case IMO.

But can I assume that you agree with my proposal in general?

— Kynikos (talk) 14:55, 3 January 2016 (UTC)

The talk pages of redirects that are not redirects themselves are quite easy to identify using a script. Unfortunately the web interface does not allow this, so the deletion flag is abused to keep track of closed discussions on such "forgotten" pages. If the talk pages are not to be deleted, we could simply create a new template -- at least temporarily, until the closed discussions are removed automatically by a bot (then redirecting the blanked talk pages automatically would be trivial).

And of course I agree with the general idea of your proposal.

-- Lahwaacz (talk) 19:58, 3 January 2016 (UTC)

I'd be in favor of creating a new Template:Redirect that we could also use in most other cases when we're using Deletion instead (at least until we create the Template:Archive thing). A bot could indeed easily handle talk pages flagged with it, by double checking that all the existing headings are stricken and the timestamp of the latest edit is older than 1 week. — Kynikos (talk) 03:59, 4 January 2016 (UTC)

Before I fell asleep yesterday, it occurred to me that a bot could also be used to flag the pages, just in case humans forget to do it (btw. there are currently 78 non-redirecting talk pages of redirects, I doubt that most of them are recent). What would be the message text of "Template:Redirect" and shouldn't the title include more than just a "Redirect" (e.g. "Broken redirect")? If it is too short, or if the briefest explanation is too long for a flag template, we could use a (possibly hidden) maintenance category instead. It's probably not a bad idea to include a special category even from the existing article status templates, just because unlike Special:WhatLinksHere, the pages included in a category are sorted. What do you think? -- Lahwaacz (talk) 13:59, 4 January 2016 (UTC)

I think Template:Redirect may look something like this (we already have a redirect icon uploaded):

This is my new wording proposal then:

---

If page A has been redirected to page B, for example after merging the content of A into page B, and Talk:A exists:

• If Talk:B does not exist, move the entire Talk:A to Talk:B, letting MediaWiki automatically redirect Talk:A to Talk:B.
• If Talk:B exists:
  1. Move the still relevant discussions, if any, from Talk:A to Talk:B.
  2. Ensure that the discussions left in Talk:A, if any, are closed.
     • If Talk:A hosts discussions that have been closed for less than the period specified in Help:Discussion#Closing a discussion, flag Talk:A with Template:Redirect, so that the page will be redirected to Talk:B after the closing period.
     • Else, immediately redirect Talk:A to Talk:B.

---

Using hidden status categories indirectly through status templates could be a good idea. Once upon a time, there were categories like that, but they were normal (visible) ones, and we deprecated them instead of hiding them, as far as I'm concerned because we didn't think about that possibility. I'd be against using hidden categories directly to mark pages to be redirected, for consistency with the other maintenance flags (status templates).

— Kynikos (talk) 08:55, 6 January 2016 (UTC)

Now, that looks perfect! -- Lahwaacz (talk) 21:15, 6 January 2016 (UTC)

All right, it's implemented then :) I'd leave this discussion open as a reminder for the bot ideas. — Kynikos (talk) 03:59, 7 January 2016 (UTC)

Brevity

Regarding [2].

it's ok to spell this out punctiliously; the short version lost important info, and most people who read this will need to do it only once, no time waste

I believe that a Wiki should always strive for brevity. I don't think that I lost important information. This is text editing not brain surgery, should we also remind readers to turn on their computer?--Larivact (talk) 12:17, 21 August 2017 (UTC)

Brevity is good indeed, but superficiality is not. The most important information that your edit lost is the reasonings that justify steps 2 and 4 and are what give depth to the content: one of the foundations of this wiki is that we don't only explain what to do and how, but also, and maybe even most importantly, why, and this is also true in the contributing guidelines.

Unfortunately it's quite common that those steps aren't followed by users, and when we point it out in comments or talk pages it's useful that the procedure is clearly described to support our remarks.

-- Kynikos (talk) 15:40, 21 August 2017 (UTC)

I agree that reasoning is important. I think that a short list of editing guidelines would be a good idea (if it doesn't already exist somewhere).

• When moving content, do not make any other modifications because they will not be visible in the resulting edit diff.
• When moving content within a page, do it in a single edit to produce a clean edit history.

--Larivact (talk) 14:31, 22 August 2017 (UTC)

We have similar bullets at the first stop for contributors: ArchWiki:Contributing#Do not make complex edits at once

Help:Procedures is referred to later in that. Ok like this? --Indigo (talk) 20:23, 22 August 2017 (UTC)

Merge procedures

I propose to add a new Help:Procedures#Merge section. Merging content is a complex operation and the only mention of Template:Merge in this help article is in Help:Procedures#Remove an entire page so far. The latter covers only one case and does not guide towards the w:Wikipedia:Merging help (linked in the template itself). Two more cases I see to cover in the new section:

1. Regular: merge of a section from article A to a merge target section in article B (or A)
2. Complex: merge of a fork B of an article A, after partly rewritten/restructured.

Obviously, the more complex the improvements/changes to a forked article, the more difficult it is to merge back, while keeping the article history intact and transparent. I will start to jot down ideas in User:Indigo/Sandbox#Draft Help Merge first, draft later.

Are there objections to create it in general, or suggestions to place it elsewhere? --Indigo (talk) 18:49, 27 January 2019 (UTC)

I don't think we should use the same template for merging two separate parts and applying changes specifically meant for one part because these are entirely different things. Perhaps we could write a Python script to apply the edits from a user space article to a main space article automatically individually. --Larivact (talk) 18:57, 27 January 2019 (UTC)

+1 to add merge checklists.

Drafts must be merged as if the edits were completely new, i.e. in accordance with ArchWiki:Contributing#The 3 fundamental rules.

The etckeeper example in User talk:Larivact#Help procedures explains the reason, I appreciate Larivact's work, but edits like [3] and [4] shouldn't be allowed (they already aren't).

Of course a merge script would help; for simple cases where no changes to the original article have been made while the draft was being edited (and the draft started as a 1:1 copy of the source), an admin can already use Special:MergeHistory (mw:Help:Merge history).

-- Kynikos (talk) 03:58, 28 January 2019 (UTC)

Rename a category

1. I think step 3 can be removed because the bot will update the interlanguage link regularly.
2. It should be noted in step 4 that Table of contents and its localized version should not be updated.
   Also, the !/Table of contents/ filter needs to be used in the Wiki Monkey method of step 4 to avoid updating Table of contents and its localized version.

-- Blackteahamburger (talk) 05:50, 18 August 2020 (UTC)

Patrolling

I think it might make sense to clarify the term "Patrolling" in the dedicated section for it (which is also marked as outdated). I already confused it with MediaWiki's built-in patrolling feature which is only accessible to maintainers and users with similar privileges.

On top of that it is not documented how and when to use MediaWiki's built-in patrolling feature. I see a lot of unpatrolled edits in the recent changes, even when one of the administrators edited directly after an edit to fix style issues for example, so they have obviously seen it. Is it encouraged to use it? I tried to mark changes I e.g discussed with others in the IRC channel as patrolled to save the other members of the maintenance team some time, in addition to the edits I inspected and made sure they are alright (Topics I feel confident in, typos/grammar/etc). There is also the "Mark page as patrolled" feature, which I am also not sure about. -- NetSysFire (talk) 00:02, 28 March 2021 (UTC)

You're right, it's not clear, I don't know the other maintainers, but personally I don't use the built-in patrolling feature, as I'm used to reviewing all the daily changes anyway.

I mostly target vandalism though, or violations of the fundamental rules, and can only check the content of the articles that I'm mostly acquainted with.

You're very welcome to organise some kind of a patrolling team that makes use of the feature though, if others are interested, as of course the more eyes review the changes, the better.

-- Kynikos (talk) 05:01, 28 March 2021 (UTC)

Personally, my Special:RecentChanges has a filter that highlights unpatrolled edits. When there are a lot of changes I tend to skip patrolled edits from reviewing. I've never manually marked any changes as patrolled since I've never seen anyone else do that, but I guess I could start doing it.

Since MediaWiki's "patrolling" is only possible for the Maintenance Team, I don't know if it's worth mentioning in Help:Procedures...

-- nl6720 (talk) 18:17, 29 March 2021 (UTC)

Since patrolling and patrolling (the mediawiki feature) are different, the section should be renamed in my opinion. Users should still be encouraged to check the recent edits.

-- NetSysFire (talk) 19:02, 29 March 2021 (UTC)

Another thing that should probably be discussed: Should we mark (changes to) discussion and user pages as patrolled? Since the guidelines are not strict on them (aside from the code of conduct and similar of course), I have been marking them as patrolled if they are not spammy or violate other rules.

-- NetSysFire (talk) 19:16, 29 March 2021 (UTC)

I now have collected some tips about patrolling edits and pages:

• Additions to a talk page can be marked as patrolled if the addition does not violate the code of conduct or is otherwise inappropriate (e.g asking for support on a talk page, talking about gnome on a KDE talk page).
  • This also applies to user talk pages.
• If dealing with a whole page of unpatrolled recent changes, tackle minor edits such as typos, grammar or wiki syntax ones first. They are usually very easy to check.
• Additions to user pages by the user who "owns" them are usually fine to mark as patrolled if they do not violate the code of conduct or are otherwise inappropriate.
  • I would pay special attention to edits from other users unless they are correcting typos.
• What about ArchWiki:Sandbox? There may be low-quality edits which are fine in my opinion since it is a sandbox. As long as the edits do not violate the code of conduct they should be fine to mark as patrolled
• Some new pages, and even some older ones, are not yet marked as patrolled. I suppose they can be marked as such when they are not an utter trainwreck. New pages tend to be stubs though.
• Translations can be hard to mark as patrolled since you do not know what is in them exactly when you do not speak that language. I usually leave them without marking them as patrolled, but when someone adds a load of suspicious links it is safe to say that the edit is not legitimate.

-- NetSysFire (talk) 10:28, 20 April 2021 (UTC)

Note that you can't mark too old edits/pages as patrolled, since the tag is recorded only in the recentchanges database table, which is cleaned after 90 days. -- Lahwaacz (talk) 10:54, 20 April 2021 (UTC)

I am going to clean up the section now. "Report solving" is an entirely separate step in my opinion and I will put it into a separate section.

-- NetSysFire (talk) 15:05, 21 May 2021 (UTC)

FWIW, report solving was about ArchWiki:Reports (see its history). — Lahwaacz (talk) 07:54, 22 May 2021 (UTC)