Blog:In defense of merged wikis

This blog focuses on misinformation regarding the merged wikis idea and disregarded issues with creating additional ones. Primarily, a point by point reply as to why ‎‎this blog is not just a different opinion, but the key source of misinformation and bad logic on the matter.

First, some points to lay out. This is based on the idea as originally detailed by me, and does not consider people who may have overspoken about something that is not complete.
 * 1) Any merged wiki process would be done with not just QP central approval, but the consent of the actual acting majority within given wikis. It would not be done without their consent and the idea will fade naturally if it is proven unpopular. At most at this time, it is controversial with a verbose minority who don't like it more or less because it's different and they don't know how to do it.
 * 2) The idea *must* be executed as a proof of concept. It would be tried on small wikis with few stakes where the senior staff of Qualitipedia, experienced users in general and other contributors will help design and refine the idea's execution. If it is not technically feasible, the idea is dropped. If it is, it can be planned to execute on a slightly larger wiki pair, with their permission after receiving evidence of how the process would work. Multiple experienced users have already expressed favor for trying, including the co-leader of Qualitipedia and an admin across several key wikis.

Now, as to why the blog linked above is so frankly poor on the topic and in general.


 * 1) is the worst because it is utterly wrong. The wikis were founded as a binary. They have always been a binary, 'good' and 'bad'. The times they weren't binary, they failed, because a fence-sitter third wiki doesn't get traffic and is proven to be a waste of time, therefore we only have one neutral wiki that was made on a whim that continues to prove the point by struggling to get people to care. This is the most egregious case of telling people what things are while making up facts to favor the argument.
 * 2) is not a valid point, given the process above that would encourage people to give it a try. If we only ever cared for people's familiarity, Wikipedia would be using the Nostalgic skin and Windows would be back on 3.1. On the other hand people had to become familiar to the very idea of electronics, so...
 * 3) is superstitious and shows a lack of knowledge on the topic. I don't think these wikis mind too much, being hosted on Miraheze servers and more significant resource draws than Qualitipedia could be combined. It obviously doesn't bother the underlying software since the WikiMedia Foundation with Wikipedia and several more gigantic projects get on fine. MediaWiki will not have lagging issues. If it hypothetically would, we'd hear about it from the sysadmins.
 * 4) purports the nonsense that there were three wikis in the first place (there aren't) and the one case that does apply (Okay Movies Wiki) could be imported manually by a competent admin in a few hours alone. On the larger wikis an automated process would be required, but is possible. This is the point of performing a proof of concept to see how to do it properly. Yes, setup would take work. The work is intended to better the resulting pages in quality, though if you don't see a problem with that I guess the discussion would be pointless.
 * 5) entirely downplays the subject, so here's some more problems:
 * 6) * Mirroring template setup consistently across 12 wikis
 * 7) * Managing global staff titles and network blocks across 12 wikis and managing staff titles/blocks locally among 2-3 wikis each time
 * 8) * Miraheze hosting many MediaWiki installations for topics that could easily be bundled (which is the actual technical waste of resources in this situation; Mediawiki is designed to be stuffed in pages with ideally as few sessions as possible to do its job).
 * 9) * The ongoing issue of page placement is larger than it gets credit for; at minimum pages can be dubbed as 'generally good', 'generally bad', 'average' (no strong opinions) and 'controversial' (clearly strong opinions that you can't just call 'neutral'). Qualitipedia's historic problem is having content thrown into one extreme or the other with a half-assed 'average' category to mark the difference (this wouldn't be the case if there was that third wiki for each already as claimed previously, but oh well). Rather than go into the technical mess above, we could do what proper wikis in other community circles do; operate on one wiki and make the content properly fit the situation. If it's canned by critics but loved by audience, make that clear from the start without taking a partisan stance by throwing it on one wiki or the other, or a 'neutral' wiki that downplays the obvious controversy, or slamming it on yet another 'controversial' wiki that multiplies the problem.
 * 10) is silly when you can actually look up a movie, find it on the same wiki and see what its cut is without looking, not finding it and having to go to an entirely different wiki to see where it is and why. Categories, templates, other not terribly advanced MediaWiki concepts can be used to organize pages; that's why they exist and should be used properly. Qualitipedia has always done poorly at doing this, but that's because Qualitipedia's editors and administrators historically haven't used them properly; that's an education problem, not a software issue or necessarily an issue of the idea.
 * 11) is best to address by proof of concept; I'll simply cite 'lack of imagination' in considering how to execute it properly. I don't see a proper argument here. Pages can have subpages if the content is worthy of being singled out, and sometimes things have different receptions within a wider work. You could now find it all at once with the idea and see what got what reception uniquely if it was notable.

The United States has not switched because it's literally behind the rest of the world except third world countries in some very basic things and its people are thick-skulled regarding change because it can't be changed through bot processes, templates, categories, and more that dynamically changes values to what you want them to do. The two are impossible to compare and have far more advanced context than you give credit for, and frankly Bluba, you are not technically qualified to discern the differences. This is an interesting read into common oppositions, but most of it is nay-saying for weak reasons that disregard a competent approach.

DarkMatterMan4500 would give things a chance and is rather flexible and receptive to new ideas. You do him a disservice by using his quote to sound decisive within a poofy blog of air. I defer to proper consensus and people's goodwill to see the idea get a shot, and if it doesn't work it'll because it's been proven with fact, not what some of these points were made of.