Forum:Changing the way merge and split requests are done

From Old School RuneScape Wiki
Jump to: navigation, search
Forums: Redwood Grove > Changing the way merge and split requests are done
Replacement filing cabinet.svg
This page or section is an archive.
Please do not edit the contents of this page.
This thread was archived on 14 March 2021 by Spineweilder.

At least one other person has indicated that the way merges and splits are currently handled might be overkill at least for cases that are «obvious». Those of you who read log messages already know I think a formal process is overkill for most cases.

Thinking about it for a while I realized this has to be a community decision. This will also allow for formalizing new rules too if that is desireable. Although when it comes to rules it seems to me the current rules are okay. Contrary to deletions, the it appears the rules regarding merging and splitting do not require a formal process as of the time of writing, so IMO those are fine.

What is not so fine though is the process in which merge and split requests are handled. The way the system was set up was overly bureucratic for most cases, and didn't even work until recently. To make matters worse, one can't easily close a formal process if someone opens one, this prevents swift action.

Preliminary idea: I'm thinking a better way to handle this is to borrow the 'speedy delete' template and make merge and split versions of it. The merge/split reason can be given as a template parameter. The documentation for the old merge and split templates would then urge users to use the new templates unless the merge/split is non-obvious or controversial.

This will basically result in having a nice way to tag articles for splitting/merging, while also avoiding a formal process that would in 95% of all cases be pointless. I mean even on Wikipedia it is not uncommon for articles to be tagged for long periods of time before anyone does anything about them.

Another thing to consider is whether the old formal merge/split request system should be kept at all. Maybe it is better to just outright delete it?

Who: It is also not obvious who can do a merge/split. When someone opens a formal process it is implicitly mandated that an administrator handle it, however with the proposed 'quick' merge and splits, I think it might be acceptable to allow anyone who feels they can handle it to perform one. Alternatively it can be recommended that only seasoned editors do it (since it may be non-trivial). I have no particular opinion on that atm.

Meta: For the discussion itself, it might be a good idea to allow a week or so of discussion about what is the ideal process, before casting any votes. (Or you can cast one now, knowing you're free to change it later if you so wish.)

Well then, let the fight to the death peaceful discussion begin. :p --The scribe Eek, a goblin! 12:48, 8 February 2021 (UTC)


Comment - I'm not particularly familiar with the recent difficulties of RfM/RfS (although I feel some responsibility for anything going wrong there, as the original creator of the RfM/RfS process many eons ago). Would you be able to provide a bit more context/specificity about cases where the existing system didn't work that well? From my reading of your thread, that would mean examples where obvious requests were left open longer than needed, although I'm wondering if there's more to your concerns. ʞooɔ 13:17, 8 February 2021 (UTC)

I briefly checked out the discussion. And I must say I have no idea what the process was prior to the current one. But I do note however you pointing out the previous process had a problem with requests going unhandled/ignored for a long time. Also judging from the archives over at RSWIKI it is clear that the process do indeed work there. With the recent bugfixes it should work on the oldschool wiki too. Although the archives here are mostly empty. Can I ask you what was the reason requests went unhandled with the old system?
My proposal was inspired by the way Wikipedia handles merges. They simply add a template that adds the article to a maintenance category, and provide a link to the article's talk page if there's a need for further discussion. Wikipedia also allows regular users to perform splits and merges, and only page deletions are subject to formal discussion. This seems like a more efficient way to do things to me, this is part of the reason why I proposed a change.
@Joeytje50: My main concerns with the current system were twofold. First, at least from my limited understanding of the consensus page, discussions are mandated to stay up for at least one week unless exceptions such as vandalism, snowball clause etc. applies. Secondly they are also supposed to be closed by an administrator. Maybe I'm wrong but doesn't this effectively prevent a regular user from doing a merge? Doesn't it also prevent the action to be taken before one week has passed? Of course this only happens the moment a discussion page is created, if it's not, then none of the consensus stuff applies and the merge can in theory be handled by anyone. The root of the problem is the current RFM template encourages users to create a discussion page, basically forcing a bureucratic process. --The scribe Eek, a goblin! 15:16, 8 February 2021 (UTC)
Formally, you're right. Discussions should stay up for at least a week. However, let's say on the day of release, one user creates Isle of Souls dungeon and another creates Isle of Souls Dungeon, both containing content. An hour later, before anyone actually merges the pages by simply being bold and doing it, another user creates a merge request on RS:RFM about those two pages. It doesn't make sense to keep that discussion up for a week just because the consensus rules state a discussion needs to be open for a week. In this example it's very obvious, but depending on the situation, similar common sense may be applied to close a merge request early. If there's no point in discussing the merge of the specific pages, just going ahead with the change would be just fine. The merge request for Equipment I closed yesterday probably wouldn't fall under this UCS exception because it is indeed a page that's linked from the main page, so some time / oppurtunity to discuss the merge is probably a good thing. But in a lot of other cases where the outcome is obvious there's just no need to wait out a week just because someone started a discussion. In those kinds of cases it's fine to request closure of the discussion early, I'd say. Joeytje50 (talk) 15:43, 8 February 2021 (UTC)
That makes a lot of sense. It's still kind of an annoying legal bug when the rules or lack thereof run counter to common sense or common practice (which seems to be not using RFS/RFM on the oldschool wiki).
Should it turn out that there's no support for a simplified merge/split process, I'd probably ask the consensus policy or the RFM/RFS pages themselves be clarified with regards to whether regular users are allowed to do merges/splits, and how the prescence of a merge/split discussion affects what they are able to do or not. I don't think this is much of a problem for staffers, but I'd still say this clarification is much needed for users. --The scribe Eek, a goblin! 20:32, 8 February 2021 (UTC)

Question/Comment - The {{D}} template exists because not everyone can perform the action that is being requested via this template. Considering that you typically do not need admin tools whatsoever in a merge/split action, what is the exact intended purpose and target demographic for a speedy merge/split template? Also, once a formal discussion has been started it does not necessarily have to run its full course (which is what I think you imply with "one can't easily close a formal process if someone opens one"). It may be closed right away if there is no point in waiting out a full decision. In those cases it's probably a good idea to just add {{Closure|RS:BB}} or something similar on the discussion page. Joeytje50 (talk) 13:41, 8 February 2021 (UTC)

Comment - I think I broadly agree with the points raised in the proposal. RfS/RfM is generally bureaucratic and not always necessary. Being bold is often the right path, as it is in many situations on the wiki. However, it is useful if there's any disagreement on the action taken and it's a nice way to de-escalate any potential edit war. It's also useful for establishing a precedent to apply to multiple similar changes in a centralised location. We often lose talk page discussions and they rarely evolve beyond data gathering or simple answers to questions.

As for discussions languishing, it's a relatively simple reason - no one wants to actually do the split/merge because it can be long or difficult. Admins that write long content pages are unfortunately fairly rare, and thus most don't have the skills or experience. Realistically, you're right in saying an admin is not needed to carry out the split or merge. Determining consensus is an administrator role, and it's generally expected that admins implement a discussion, but there are examples of non-admins proposing and implementing merges or splits once consensus has been determined on RSW at least. cqm talk 23:33, 8 February 2021 (UTC)

Comment - I agree with what cqm is saying. For the most part, RfS/RfM is ignored in favor of BB. In the case of conflict or something you anticipate to be contentious it is nice to have a formal process though. It can potentially save a lot of work if the merge or split is likely to be opposed by some people or undone without some kind of consensus. I would support making that a bit more clear on RfM/RfS though if others feel that's the case. Andmcadams (talk) 02:41, 18 February 2021 (UTC)

Oppose - (to the extent that something was proposed here) I agree with Cam, there's no need for a speedy merge/split. I think people should use common sense to determine if it's a possibly controversial change that could use discussion and, if not, then to be bold and do it themselves. Making a speedy merge/split template would just be passing the buck again and the work wouldn't get done. ɳex undique 17:38, 28 February 2021 (UTC)

Closure - Lack of extensive discussion and consensus. -- Recent uploads SpineTalkContribs 01:19, 15 March 2021 (UTC)