Help talk:Procedures

From ArchWiki
Jump to navigation Jump to search

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

Tango-emblem-symbolic-link.pngThis article is being considered for redirection to Talk:B.Tango-emblem-symbolic-link.png

Reason: Talk page of redirect. (Discuss in Talk:A#)
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)


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)