Doom Wiki:Central Processing/2015

__NEWSECTIONLINK__

This is the central discussion forum for wiki editing and administration activity on the Doom Wiki. Feel free to ask any questions or pose any concerns you have here, and you should receive a response shortly. Check the archived discussions for older threads.

Archived discussions

 * 2005
 * 2006
 * 2007
 * 2008
 * 2009
 * 2010
 * 2011
 * 2012
 * 2013

Rquotes
I added Template:Rquote from Wikipedia, where it is deprecated and use is discouraged, but I personally like the style of it and think it would be a good way to do quotes on this wiki where we have slightly less formality. Opinions? --Quasar 00:28, 4 January 2014 (UTC)
 * I suppose it'd fit for things like the level descriptions lifted from Hexen 64 (e.g., "In these frozen caverns, relentless ice [etc.]" in Guardian of Ice) and maybe for NPC pages (like Jack Campbell), though they're already using Template:Quote. --Gez 08:07, 10 January 2014 (UTC)
 * I prefer the Template:Quote style for those top-of-the-article quotes. This was an idea for extended quotations from literary sources or people that are within the article text itself. --Quasar 17:57, 13 January 2014 (UTC)

Stubs
I am finding more and more articles that are marked as stub status but contain more or less all the information that can be said on the subject. I am starting to remove stub status from some of them, but it's way more than I can handle. I'd request that if you come across any articles which have been substantially fleshed out but still have an ugly stub header at the top, take the time to remove it. A perfect example and one I just fixed was the Delta Complex map article. All of its sections are filled out with information and I don't know much else that could be added to it but it was still marked as a level stub. --Quasar 19:30, 29 January 2014 (UTC)


 * Did some shoveling. I think "more or less all the information" is often subjective, especially for a non-technical topic like a person.


 * Quasar, given your post above, what do you think of these articles? I created them years ago, then tagged them as stubs after some people complained that they were very sparse.


 * Ledges series
 * E3M2: Doom - The Movie (Serenity)
 * E3M8: Church of the Poisened Minds (Serenity)


 * Ryan W 02:56, 3 February 2014 (UTC)


 * The first looks significantly complete. The other two have empty sections. Those sections should either be filled out with info, or removed if the sections are irrelevant. Until such happens I'd consider them to still be level stubs. --Quasar 17:35, 4 February 2014 (UTC)

Captchas broken again
Somebody sold us out through Mechanical Turk again more than likely. As I don't feel like spending the next year blocking the entire Indian subcontinent, I've switched over to some randomized QuestyCaptcha code I found on the Internet. Let's see if it performs any better. --Quasar 15:27, 6 February 2014 (UTC)


 * A recent series of registrations by users with regex-pattern-matching user names who subsequently make no edits has made me suspicious that the new code, which included a random "Please tell what the current day of the week is in GMT" option (with link to Google) is susceptible to a dictionary attack or possibly even bots with AI coded to be able to answer that particular question. I have modified the code in LocalSettings again to remove that option, so we are currently only using questions that ask for a random character from an MD5 substring that's calculated on a GUID seeded with output from mt_rand. I will continue to tweak and strengthen the code if it proves necessary. --Quasar 17:12, 2 March 2014 (UTC)

Moving pages
I just noticed I can move some pages but not other ones for no reason I can notice. For example, I can move Mancubus fireball clipping but not Blood. Why so? --Kyano 10:12, 3 March 2014 (UTC)


 * Good question. It appears to be a result of FlaggedRevs configuration.  By default, after a page has been reviewed (at any level of quality), only admins can move it.    Ryan W 01:42, 4 March 2014 (UTC)

Incidentally, the move of this page was never properly reversed, so all prior edits look like they pertain to the /2013 subpage. Does anyone know how to fix this without erasing author attribution for any edits? Ryan W 06:54, 13 March 2014 (UTC)


 * I'm afraid that ship has sailed, particularly since this page has been edited repeatedly since. I don't think it's that big a deal though. --Quasar 14:15, 13 March 2014 (UTC)

Images with an incorrect aspect ratio
In the following days, I will fix most if not all of the images in the "Screenshots using an incorrect aspect ratio" category. Speak now or forever hold your peace. --Kyano 22:17, 5 March 2014 (UTC)


 * One thing to watch out for would be any that are actually widescreen shots and are correctly rendered. I know the shot of Eternity on the Eternity Engine page had been mistagged as being incorrect aspect ratio at one point (it is in 16:10 widescreen IIRC). How many shots are we talking about? If I have time, I can help by reviewing them for issues like this. --Quasar 01:38, 6 March 2014 (UTC)


 * (edit conflict) There are 199 images in the category.  It's true that the tagging was probably done based only on the dimensions of each uploaded file.  That said, I see a bunch of my ancient E1/E2 walkthrough snaps in there, which are probably safe to batch up.    Ryan W 01:59, 6 March 2014 (UTC)


 * My original idea was to just resize 640x400 to 640x480 and 320x200 to 320x240 and leave the rest untouched. That should be safe enough. Most of the images in that category with that problem have that size. If there's something wrong it can always be reverted. What do you think? --Kyano 13:11, 6 March 2014 (UTC)


 * Based on discussion ongoing here at File_talk:Tuttifrutti.png I am going to ask that you hold off on this for the time being. It's becoming quite clear that there are a number of exceptional images that are not classifiable only by their logical aspect ratio or dimensions and have been placed into this category incorrectly. --Quasar 16:27, 12 March 2014 (UTC)


 * Quasar, I saw your IRC posts. Nobody said I was an authority on the technical characteristics of rendering :>   but the key thing is that categorization was done haphazardly, a few images at a time, by people with varying degrees of expertise themselves.  So in addition to what you say, there might be hundreds of *un*tagged files needing fixes.


 * Trying to be constructive here... um...


 * For certain uploaders, it may be on the record or really obvious which port was used (e.g. Ducon and myself). For the others, if we could define a reasonably accurate "decision tree" for identifying the common situations you mention, we could re-sort, then talk about mass resizing.    Ryan W 04:06, 13 March 2014 (UTC)

Well here are the guidelines I'd stick to if you want to make progress without damaging any files that shouldn't be resized: --Quasar 14:06, 13 March 2014 (UTC)
 * The dimensions should be 320x200 or 640x400 to be an immediate candidate. It's very likely anything else was rendered by a source port (which doesn't automatically mean they are correct but that they need more careful treatment, see below).
 * If the image is 320x200 or 640x400 but has a correct-looking (non-squashed) HUD, or sprites that look tall instead of broad (ie they do NOT match their appearance if extracted from the IWAD and viewed on a square-pixel display) then its been rendered with inherent aspect ratio correction by a source port. One of the ones we found and I was talking about on IRC was such a pic, at 640x400 size. It was basically rendered like 16:10 widescreen would be correctly rendered (wider FOV, rescaled HUD that looks tall instead of fat).
 * Just to be clear, as this category is already covered by my first suggestion, the "looks fat instead of tall" thing only works for shots that are 16:10. If the pic is already 4:3, like the one linked above, you can't correct it by rescaling - I suspect that one in particular is a Doom 95 shot and it renders its 4:3 modes in a very odd manner. You won't fix these by rescaling them.
 * It's still worth considering, for 320x200 images in particular, that a loss of quality is incurred by rescaling them to 320x240. This particularly hits numbers on the status bar, and port elements like the BOOM HUD, badly. I feel uncomfortable with the idea of introducing tons of scaling artifacts in the name of chasing after proper aspect ratio as an ideal. It's not necessarily the most important thing about the pics we have in some cases, I think.


 * I seem to recall a couple of my shots being redone with professional tools, i.e. cropping the HUD and then pasting it back in, with no apparent artifacts in the final copy. Any media editing is inherently labor-intensive though, as exemplified by the manual check in your second bullet point.  Maybe the next logical step is a bot that reviews new image dimensions and warns the user before they upload 150 more?  :P      Ryan W 17:52, 13 March 2014 (UTC)

Source extension
I guess we need to have a debate on whether we want to keep/use the source extension. It seemed like something that would be very useful on an often highly technical wiki like this during the install process, so it was one I specifically selected for addition. I didn't know it had compatibility problems with wiki markup though. That's a bit discouraging. I have also run into problems with finding any method of imposing a right-hand margin on the code it produces in the past. --Quasar 01:50, 6 March 2014 (UTC)
 * The incompatibility is easy to understand as instead of merely telling MediaWiki the text block should use monospaced font (and respect whitespace), it tells it it is raw code. So interpreting markup elements would generally be undesirable. For a pseudocode example:

string $foo = '\''. $bar. '\'';
 * I don't think we're using a lot of markup in preformatted blocks, though (contrarily to the ZDoom wiki). The edit I reverted just happened to be on one of the few. --Gez 03:02, 6 March 2014 (UTC)


 * Makes sense, thanks for the input. Would you say you're in favor of keeping the extension around though? --Quasar 03:11, 6 March 2014 (UTC)


 * I think another solution should be found. While this wiki doesn't have a lot of source code snippets, the ones that there are should have highlighting. If the problem is that it's not possible to highlight portions of code (for example, bugged code, since most of the code snippets are inside the "Errors and bugs" category), work should be done to implement that feature in the source extension. My two cents. --Kyano 10:21, 15 March 2014 (UTC)

&lt;tt&gt;, &lt;code&gt;, etc.
This issue has been raised these last days due to some edits I've been doing. It turns out there are two ways to represent monospaced words/sentences: using either &lt;tt&gt; or &lt;code&gt;. As you can see, the biggest apparent difference between the two is that &lt;code&gt; adds a grey background.
 * &lt;tt&gt;: that's what's being used in most of our articles now. It looks_like_this.
 * &lt;code&gt;: that's what's used in a few articles. It.

I personally support changing all &lt;tt&gt; occurrences to &lt;code&gt;. There are several reasons from my point of view:
 * &lt;code&gt; adds a grey background, which serves as a visual separator from the rest of the sentence which goes beyond the font (which is monospace for the two).
 * It's what Wikipedia is doing. For example: the article. As you can see, they use &lt;code&gt; for all code samples inside sentences. On top of that, the big snippets of code also have a grey background, for consistence.
 * &lt;tt&gt; is currently deprecated and does not exist at all in HTML5. Should MediaWiki transition to HTML5, all &lt;tt&gt; occurrences will have to be replaced. That will not happen today, but it will end up happening at some point.

If the grey background is a problem, it can be removed at CSS level. But, again, I strongly support keeping it. As I've seen there's a habit in this wiki of avoiding the imposition of style policies, but something should be decided in this regard :)

On a related note, there is a bug in the rendering of both tags in Chrome: the fonts of &lt;tt&gt;, &lt;code&gt;, &lt;pre&gt; and the source extension look much smaller than the rest of text. and then by adding these lines to their CSS file:

Thoughts? :) --Kyano 15:00, 29 March 2014 (UTC)
 * I'd suggest doing what I did on the ZDoom wiki and using a template to wrap these tags. So you replace blah by instead of replacing it by  . This makes it easier to update everything at once if needed. Personally, I don't really like the a background color change in text placed within a paragraph, I find it ugly and distracting, and I think the font change should be enough to serve as visual separator. It's why I still use tt instead of code. (On the other hand, if it's outside of a paragraph, then yeah, give it a different background, which is why I wrapped some  --Quasar 21:31, 29 March 2014 (UTC)

Admin Rights Movement
To continue a discussion that spawned here: let's discuss which rights admins currently don't have that they really should. For a start, suppressredirect. Any right that corresponds to actions that can already be done in a different way (here: move then delete the redirect) has no reason to be denied. --Gez 19:39, 3 April 2014 (UTC)


 * Actually, rereading that page, I don't see anything else matching your last sentence (anyone please speak up if I missed one). Additional rights defined by MediaWiki, or extensions, but currently *unused* might be more interesting.    Ryan W 23:36, 3 April 2014 (UTC)


 * Okay, I reviewed the documentation and am adding subsections accordingly, so it needn't be an all-or-nothing decision.   Ryan W 22:59, 4 April 2014 (UTC)

suppressredirect
Admins now have. Cleaned up some other stuff while I was in there - chiefly, trying to setup captcha skip for group as recommended by the ConfirmEdit documentation on MediaWiki does absolutely nothing because  hasn't been a user group since MW 1.13... I guess nobody ever reads or updates extension documentation. --Quasar 05:25, 4 April 2014 (UTC)

mergehistory
A special page for executing history merges in one step instead of several. Seems straightforward, as Gez says. Ryan W 22:59, 4 April 2014 (UTC)


 * I have given sysops this permission effective as of now. I do expect all use of it to proceed with overly paranoid caution however, as it is an inherently dangerous capability as spelled out on the Wikipedia page you linked; incorrect merges cannot be easily reverted. --Quasar (talk) 15:45, 4 July 2014 (UTC)

siteadmin
A special page for making the entire site temporarily read-only (including admin actions). I proposed this to Quasar long ago as a method for dealing with robo-spam or DoS, in case he or Manc couldn't be found quickly. He disagreed, saying even that wouldn't be urgent enough for such drastic measures. Currently, any admin can disable editing by performing 60,000+ rangeblocks. :>    Ryan W 22:59, 4 April 2014 (UTC)


 * I disagreed that doing it through rangeblocking was necessarily better than shutting off Apache or setting .htaccess to deny all in the backend; but the overriding factor with that is the rangeblocks > /16 being broken in versions of MediaWiki prior to 1.2x (at least I hope they've fixed it by now). If there's a frontend way to do it differently, I don't necessarily have an objection to it. --Quasar 14:33, 5 April 2014 (UTC)


 * I never said it was better, just faster, but you're entitled to disagree that it would be helpful in the first place. To put it another way, if 200 bot accounts suddenly appeared to spam us at 30 edits/minute, and you and Manc were both traveling for the weekend, would there be risk to the servers themselves, or just a big on-wiki mess afterward?    Ryan W 19:57, 5 April 2014 (UTC)


 * P.S. Nope, not fixed yet.    Ryan W 02:13, 13 April 2014 (UTC)

tboverride-account
Admins already have, which allows creation of pages on the title blacklist; this allows the same when creating new user accounts. Very rarely used, no doubt, but if the admin can be trusted with one of these rights, it seems logical to have both. Ryan W 22:59, 4 April 2014 (UTC)


 * How do you create a new account while logged in as an admin? I guess that's my main question. --Quasar 14:35, 5 April 2014 (UTC)
 * Go to Special:UserLogin and click on "create an account". --Gez 17:22, 5 April 2014 (UTC)
 * I can do that as well and I'm not an admin... --Kyano 17:24, 5 April 2014 (UTC)


 * Interesting. What happens when you try to activate it?    Ryan W 19:57, 5 April 2014 (UTC)
 * It works perfectly. --Kyano 20:00, 5 April 2014 (UTC)

Upgrade Plans
Manc and I intend to attempt to upgrade MediaWiki next Saturday, 4/19/2014. The wiki may be locked for editing starting sometime during the day before so that we retain a fully up-to-date set of dumps and backups in case the whole thing goes tits-up. There will be some unavoidable fallout from the procedure: --Quasar 17:53, 12 April 2014 (UTC)
 * Monaco skin is most likely going bye-bye as the rebuild is not compatible with MW 1.18 or above. This is going to leave us in need for a new customized variant of Monobook or Vector as the default skin. Suggest posting your proposals. I'll want to be adopting something that is palette appropriate for Doom, and not sticking with a bright white background everywhere like the defaults have. That's going to require heavy customization of the CSS for whatever default we choose.
 * Along with that loss, we'll lose the very nice sidebar menu. I'll be doing research on what if anything is available as a replacement.
 * The FlaggedRevs extension will likely be going away and all of our revision approval data will be lost, because it won't import into the new version cleanly for whatever reason. We have two options with this - drop FlaggedRevs permanently, or install the newest version of it on the new instance and start from scratch. Also suggest posting your opinions in response to this. FlaggedRevs has been the most controversial aspect of this wiki since its migration, which is something to take into account.
 * All extensions will be updated, and some may go away if they're found not to work. In the same vein, some new ones may be added such as the new Mobile Version plugin which optionally provides an optimized view of the site for handheld devices - these extensions require MW 1.2x and so we've had no chance of using them so far.
 * 1. Monaco replacement. No opinion. I use Monobook exclusively, and the only time I see Monaco is when I'm logged out, prompting me to log back in ASAP to make it disappear. :p 2. FlaggedRevs. I think that, in practice, we haven't really needed it? If we lose it, I don't think it'll be much of a problem. --Gez 18:20, 12 April 2014 (UTC)
 * 1. I only use Monobook. 2. Happy to see FlaggedRevs disappear. 3. Something should be found to replace the sidebar menu. 4. Remember to update the YouTube extension as I asked, please. --Kyano 21:33, 12 April 2014 (UTC)
 * 2. Now that I have examined the matter thoroughly, I suggest we'll try without FlaggedRevs in the upgraded version and consider re-installing it if there are considerable problems with the control of new edits. Time will tell that. --Jartapran 14:07, 14 April 2014 (UTC)
 * I agree. I always oppose to the use of FlaggedRevs, but maybe it's really solving a problem that I'm not seeing just because of the existence of the extension. --Kyano 14:10, 14 April 2014 (UTC)
 * 1. Personally, I like Monaco simply because I like the color scheme--I've gotten used to the dark area at the side and top of the screen. 3. Did FlaggedRevs ever have any effect beyond displaying an annoying message below the article name? JudgeDeadd 15:30, 16 April 2014 (UTC)


 * What, you missed all the whiny forum posts, and my rants about user permissions? Jeez, we put a lot of work into that.


 * The idea is, if you don't have an account or aren't logged in, the "annoying message" is temporarily hiding the most recent edits. That means if you're playing or mapping, and you quickly open the wiki for a hint, you don't get this.    Ryan W 14:01, 17 April 2014 (UTC)

Updates as of 4/13: It may be possible to keep Monaco; I've found some other wikis that are using it on 1.22.5, and I've emailed their bureaucrats to see if they know anything about how to keep it working. In the event they can't help and it does not work, however, I've done some preliminary work in Firefox's inspector on a possible Monobook CSS styling that is similar to our Monaco default - beta preview here. Input is welcome. --Quasar 23:12, 13 April 2014 (UTC)
 * I like that. Please remember it would be good to have the modifications done at the end of the Monobook css file or preferably on a separated css file. Classes can be overriden easily. That would help with eventual theme or mediawiki version updates.
 * On a related note, would it be possible to have a theme for mobile phones such as the one Wikipedia has? --Kyano 09:16, 14 April 2014 (UTC)


 * The technically correct thing to do is actually to clone the monobook skin entirely and overwrite the CSS for that clone, and then offer that as a new skin option on the wiki. I may do that even if we do manage to keep Monaco, as I actually like the look of the modified Monobook. Not sure I'd make it my default, but it would be nice option with some additional tweaking. --Quasar 14:29, 14 April 2014 (UTC)
 * Let's call it Demonobook! :p --Gez 14:47, 14 April 2014 (UTC)
 * Agree. --Kyano 19:10, 14 April 2014 (UTC)

Post-Upgrade
Well it took the better part of three days but we are now running on fully up-to-date software: Report ANYTHING unusual, ugly, detrimental, or dangerous here ASAP. --Quasar (talk) 01:21, 21 April 2014 (UTC)
 * The head revision of dantman/monaco-port does work with 1.18+, but required MAJOR modifications to work out glitches and missing elements. So we still have our default skin. I'll be forking dantman soon on github and we'll be maintaining our own code base for it from now on (edit: Now available here).
 * FlaggedRevs seems to have miraculously survived. Needs thorough testing.
 * EmbedVideo came up as a question mark during the process but seems to be working as well.


 * Many thanks to you and Manc for another grim investment in the long-term stability of the wiki.


 * Needs thorough testing  Um... such as?  (I expect to be back at my computer in about 24 hrs.)    Ryan W (talk) 02:29, 22 April 2014 (UTC)


 * Just watch out for anything strange, in general.
 * Right now the only bad problem I'm aware of, and it's one that existed before the upgrade but seemed to have less impact than it does now, is that File: pages cannot be marked as reviewed unless you make an actual change to them after uploading. I think this is a Flagged Revisions bug to be honest.
 * One problem that's still possibly incompletely solved is missing system messages for some of our extensions. If you see this you'll see text similar to &lt;some-message&gt; or possibly &amp;lt;some-message&amp;gt; depending on the context, where you'd expect to see English language meaningful text. The fix for this is simple - I just have to upload some JSON files that didn't unpack out of the .tar.gz and .zip files properly. Don't try to create the missing system messages under MediaWiki namespace; it's incorrect to do so with the way things work now.
 * --Quasar (talk) 03:41, 22 April 2014 (UTC)


 * That File: bug is not in the bugzilla, and probably should be (at least one of the experts might tell us it's deliberate).   Ryan W (talk) 15:59, 25 April 2014 (UTC)


 * Here. The first thing I did after discovering this was still broken was search for a report and add a comment to it. --Quasar (talk) 19:08, 25 April 2014 (UTC)


 * Hmm, whoops! Glad you did that.    Ryan W (talk) 19:40, 25 April 2014 (UTC)

License upgrade proposal
I am opening a proposal to upgrade the license of this wiki to the latest version of CC-BY-SA, which is 4.0 International. Because the CC-BY-SA 3.0 allows automatic upgrading, it is legally possible for MancuNET, as the publisher of the content, to upgrade this license without need for any legal processes or extensive opt-in/opt-out process. However, I want there to be a general consensus at least before taking such an action. The chief benefits of an upgrade are in the significantly more clear wording of the new version, which makes explicit reference to the simplified version's terminology - Attribution, and ShareAlike - in the legalese version of the license; and there are also additional protections against addition of DRM to the data, similar to those added by GPLv3 over the GPLv2 (regarding WIPO's so-called "technological measures").

This wiki would remain compatible with CC-BY-SA 3.0 resources, as they all allow license upgrading. It would not however be possible for 3.0 licensed wikis to use the content here without either upgrading, or creating and managing a mixed-license environment. That's perhaps the downside with regard to other community wikis, though a possible upshot as far as it concerns theft of our material by Wikia (this is not my overriding concern in proposing the license upgrade, but it is a factor deserving of consideration).

--Quasar (talk) 19:16, 25 April 2014 (UTC)
 * Do the CC license allow the addition of special permissions? We could then have a list of wikis allowed to use DoomWiki content. Though in most cases, it's not really needed I guess; content is either already present in some form for basic information you can find anywhere on the net (e.g., WAD format specifications), or the content is more likely to get a different presentation focused on the other wiki's needs with an interwiki link to here for more general information. At least, it's how I handle things with the ZDoom and SLADE wikis. --Gez (talk) 20:25, 25 April 2014 (UTC)


 * No, and such would be against the spirit of the license, besides requiring the permission of all previous contributors. --Quasar (talk) 20:48, 25 April 2014 (UTC)


 * I waited to respond until I could review the license text. While I don't endorse all of Quasar's theories about third party re-use of our content, I agree that we should upgrade sooner or later.    Ryan W (talk) 21:03, 1 May 2014 (UTC)


 * I support updating to CC-BY-SA 4.0. The list of changes looks pretty uncontroversial. It seems like a sensible move.
 * It sounds like the main purpose here is to deny Wikia the right to use our work. This might work in the short term but I suspect Wikia will upgrade all their wikis to CC-BY-SA 4.0 at some point in the future anyway, so it's not likely to last for long. That said, upgrading to 4.0 is the right move anyway.
 * I would quite like to see us try to compete by just having better content rather than license lawyering, as I think this is a healthier and more productive attitude. But I've been horribly idle in my contributions to the wiki so I'm not really one to talk :) Fraggle (talk) 15:34, 1 July 2014 (UTC)


 * I wouldn't say main. It's the reason I originally looked to see if there was a newer version of CC BY-SA, I can admit that. But upon doing the research and finding out the stuff above about it, I felt it was a good idea regardless of that factor existing. I do agree though - improving this wiki faster than the paid editors/shills that have taken over the other site has to be our main goal (and I've been working overtime on it so far :) --Quasar (talk) 17:56, 1 July 2014 (UTC)

Misuse of Interwiki extension
When I turned this on I figured there would be measured, careful use of it and instead, in the last 24 hours, several interwikis to open independent sites we are trying to establish good relationships with, such as the Homestar Runner Wiki, have been deleted, and a few interwikis which we may have actually had links using, such as the 'c' prefix, have been deleted - leaving me with the inability to now find any of the articles that were using it via the API, since, it doesn't exist now.

I have turned off access to this extension for everyone until there is sufficient discussion about the strategy we are going to take in cleaning it up from this point forward. --Quasar (talk) 04:42, 28 April 2014 (UTC)


 * PS: Some discussion that occurred on IRC can be seen here.

I have hopped on SpiderMastermind and restored the three that are problematic deletions (two wikia generic redirects, and the HR wiki). I'll wait for Gez to catch up with this before re-enabling the extension, but here are the guidelines I personally feel we should follow:
 * Some specific wikia community interwiki? Delete it. These are garbage mostly. If we have one for Wolf3D or Chex Quest, those should be made exceptions.
 * Links to independent wikis, especially ones relevant to gaming: leave them in place. We may have cause to utilize them.
 * The following wikia interwikis need to be left in place for historical reasons: w:, wikia:, c:, community: - there are a lot of old talk page revisions with commentary by Wikia staff who linked to certain things relevant to those discussions, and in some cases these are still valid links and have even recently been useful to me (in particular, tracking down some of the old Monaco documentation that was linked to by Kirkburn). By deleting these interwikis we're sort of modifying what somebody said in the past, which is bad - it's a form of censorship in a way. I have verified we didn't have any links to their help namespaces left however; those were all in mainspace and have been expunged.
 * Links to all the WikiMedia resources obviously should be left alone (wikipedia, wikiquote, wikitionary, metawiki, etc). These are critical.

I would prefer that you err on the side of caution if you're not sure. Post about it here and we can decide what to do in collaboration. For now please focus on clearing out the reams of non-gaming-related wikia subdomains as they're the main thing cluttering up the table. --SpiderMastermind (talk) 07:45, 28 April 2014 (UTC)


 * I have only been deleting irrelevant wikia wikis and dead non-wikia wikis (which were most probably irrelevant too). For instance when I went through A-E, I left things like bulbapedia or diablowiki, which I do not expect to be actually relevant and used here. Good to have a list of protected wikia interwikis, though I'd suggest maybe using a bot to remove use of redundant prefixes since both w: and community: are the same thing (and I'd kinda rather see them as wikia:, wikia:c, and wikia:w personally but it's not very important).

c        	http://$1.wikia.com/ community	http://community.wikia.com/wiki/$1 w        	http://community.wikia.com/wiki/$1 wikia  	http://www.wikia.com/wiki/$1 wikicities	http://www.wikia.com/wiki/$1 wikicities:c	http://$1.wikia.com/ wikicity	http://$1.wikia.com/
 * Not that redundancy, in itself, is necessarily a bad thing. I'd really be tempted to add shorter interwiki prefixes like dengine:, eternity: or zdoom: for dengine_wiki:, eternity_wiki: and zdoom_wiki:.
 * Also there are some wikis that I want to add to the table because I figure they might be useful: vgmpf (useful for the music pages, e.g. vgmpf:At Doom's Gate would lead to http://www.vgmpf.com/Wiki/index.php?title=At_Doom%27s_Gate), modding (http://www.shikadi.net/moddingwiki/Main_Page has useful info on OPL and PC sound), and uesp: (best independent wiki for ZeniMax/Bethesda info). --Gez (talk) 11:56, 28 April 2014 (UTC)


 * Using my QueryBot to find all the uses and then eliminating the duplicates is within the realm of possibility. I'll give it a look-see. The extension is re-enabled for admins now. --Quasar (talk) 13:12, 28 April 2014 (UTC)

Cleanup
I think the cleanup is mostly finished. I got rid of all non-meta wikias and of all dead or non-English wikis I could find. The table is still rather large and full of irrelevant fluff, but at least it's mostly independent fluff. (There's some Curse wikis on it, but they aren't as bad as wikia and they don't have curse.com in their URL). Some questions remain: what to do with nonwiki stuff like skypeme:, acronym:, google:, rfc: or oeis: ? What do we do about irrelevant entries that aren't even wikis, like susning: (someone promoting his books) or ursine: (a company that sells fencing)? wlug: doesn't use the good address for its wiki, but should it be updated or deleted for being irrelevant? --Gez (talk) 17:31, 28 April 2014 (UTC)

Continuing problems
I had to restore as it seems dozens of links are using it. Again it is not ideal for there to be duplicates in the table, but please please PLEASE do not delete any more of these types of interwikis until I have a chance to run a query to find out whether or not they are used anywhere. --Quasar (talk) 01:14, 6 May 2014 (UTC)


 * Apparently that was me. It never would have crossed my mind that anyone would type that, when [[mw: has always been available and is already far more common (similar to how [[community: is never used because [[w: and [[wikia: were retained).  I guess I underestimated the number of quick fix edits needed during the migration .  Sorry, Quasar.  Your query offer should help with future deletions anyway.


 * I just got a fresh dump, and here are the prefixes in use. This includes unmodified system messages, but a link in a template only counts once.


 * Ideally, someone could figure out a regexp search for two left brackets, followed by a string not containing two right brackets, followed by a colon. That would rope in prefixes which were never valid, or were dropped by Wikia before we left.


 * Ryan W (talk) 03:46, 8 May 2014 (UTC)


 * I'd still like to run queries through the API, as dump searches have missed things in the past (I remember there being an estimated ~5 occurrences of mancubuses but a more thorough search later turned up something closer to 10 of them). There's a very simple query that can be run to find all links on the wiki, in all namespaces, that are using a given interwiki. I just have to have time to write the JavaScript, and so far that hasn't happened this week despite my best efforts. Thanks for the table though, it may be useful. BTW I was only guesstimating that there must be dozens of mediawikiwiki links based on the fact that I just kept on running into more and more of them. After the 4th one I found, I decided to restore it figuring there could be a lot more. This was after I fixed the ones I'd already found to use mw: instead. --Quasar (talk) 05:51, 8 May 2014 (UTC)


 * I did have a post here bemoaning the loss of our iwlinks table data which was breaking the API; however, a MW dev (or just expert user) recommended the rebuildLinks.php maintenance script; even though it didn't advertise that it would do so, it appears to have rebuilt this table, so I'm in good shape to try automated queries now --Quasar (talk) 18:52, 8 May 2014 (UTC)

FlaggedRevs File glitch
Due to lack of any progress against the bug in FlaggedRevs that is driving us nuts with File namespace articles, I have disabled the extension from applying to them. You should no longer see any reviewed status or flagging UI for such articles. --Quasar (talk) 15:03, 29 May 2014 (UTC)

New FlaggedRevs glitch or odd behavior
On several recent article edits, a wide range of historical revisions have suddenly become considered unreviewed despite the history plainly stating that they are. I fixed the first one just by reviewing the latest revision. I fixed the second one by going back in time, unaccepting the last revision by Gez, and then re-accepting it, leaving only the newest 2 revisions as unreviewed. Why is this suddenly happening and what in the world could be causing it? Is there a pattern to these edits? Is there ANY possible logical reason for this, or is it yet another glitch in what is quickly becoming the largest waste of our time instead of a helpful tool? --Quasar (talk) 15:57, 29 June 2014 (UTC)


 * This happened again as of today on Zombieman; I was not able to reject the latest two changes alone because the last approved revision was apparently suddenly from early 2013. This time it may have had something to do with the article having a quality review status higher than normal... I am wondering if this is a common thread between all of the problems that have been cropping up. Either way, this is weird and unpredictable and is becoming problematic. If we could at least understand why it's happening and what to do about it, that would be a start. Otherwise, if we don't make some progress, I will be considering uninstalling FlaggedRevs permanently in the near future. --Quasar (talk) 16:54, 30 June 2014 (UTC)


 * I personally have encountered similar problems with this extension in the past but then I blamed it on my lack of understanding of how it works. In my opinion and experience, the behaviour of this extension is erratic and unpredictable and the extension itself is not needed for us. While I agree that a method to temporarily hide potential vandalism is good to have, a buggy and overly overly overly complicated extension is causing more problems than it mitigates. This is: I think that if we decide to keep this functionality, we should find some other simpler extension. --Kyano (talk) 17:08, 30 June 2014 (UTC)


 * The main thing for me at this point is that we barely utilize it above the level of functionality already provided by MediaWiki's built-in patrolling capability, which has none of the accompanying issues. Given that patrolling has been made a more prominent feature in the latest MediaWiki also (at least more so than I can remember it being in the past), the time may just be right to start using it instead. --Quasar (talk) 18:19, 30 June 2014 (UTC)


 * If there is a patrolling system built-in already that allows us to hide edits before they have been approved by a trustable user, we should be using that instead. I don't think we use or we will use the rest of things FlaggedRevs has to offer. --Kyano (talk) 20:23, 30 June 2014 (UTC)


 * Patrolling won't hide revisions. It just marks that someone has reviewed the edit for issues. That's most of the use we're currently getting out of FlaggedRevs by only ever marking things at the lowest review level. The hiding of the unapproved edits is the one benefit of FlaggedRevs, as it means things like spam edits aren't seen by web crawlers, but that's the extent of benefit at the current time. --Quasar (talk) 20:27, 30 June 2014 (UTC)


 * So that's a problem. How do other wikis deal with this? I know Wikipedia itself just pretends there's no such thing, leading to some funny results. Of course, Wikipedia can't do anything like what we would want to do -- their project is massive. On the other hand, I've always been worried that anonymous people may be discouraged to contribute knowing that their edits will be hidden for a specific lapse of time and that they may be completely rejected. --Kyano (talk) 23:16, 30 June 2014 (UTC)


 * Revert vandalism and spam as quickly as possible. That's the only other mechanism available - editor diligence. --Quasar (talk) 04:01, 1 July 2014 (UTC)

Someone just did this and, by combining the mighty powers of FlaggedRevs and QuestyCaptcha, I haven't had the nerve of doing anything about it -- I just don't know what I'm undoing or what I'm going to break.

First, if you click "diff" on the Recent changes page, you're taken to a diff between the blanking and the last revised edit which was like two years ago. As Quasar said, part of the historical revisions of articles were magically invalidated. So I had to go to the history tab to do the correct diff and then undo it. But then when I clicked Save, I was taken to the captcha, with no diff (just the article itself), so I don't know what in hell I'm undoing. It's like editing blindly.

On the other hand, it's obvious that FlaggedRevs has "hidden" this particular method of vandalism, so it's not completely useless -- but for obvious problems like this one, there has to be another way, like an extension or bot. Wikipedia already has similar things we can take a look at. And, well, we have things in place already. Don't we? --Kyano (talk) 00:37, 4 July 2014 (UTC)


 * I'm not aware of any other extensions that do what you're talking about, and bots don't come out of thin air. First, to be running as a constant process, a bot needs a server to live on. Second, a bot needs substantial AI to discern good edits from bad ones. Finally, you need the code for it period. Find a reliable open source vandalism reversion bot first, and then we can talk about where to run it. --Quasar (talk) 15:50, 4 July 2014 (UTC)


 * Well, the extension that does what I say is probably AbuseFilter, since it can recognise edits based on patterns and tag or block them. Forget about the bot, but just for your information, they are usually written by editors of Wikipedia using Pywikibot and run on Toolserver. --Kyano (talk) 16:17, 4 July 2014 (UTC)

Captcha for external links
I have seen that adding new external links to an article triggers a very very pesky captcha, even for me, being an Editor. Is that intended or an oversight? --Kyano (talk) 23:19, 30 June 2014 (UTC)


 * The ability to exempt people from the captcha was based on the user group, which was deprecated in MediaWiki 1.16 and does not work any more AFAIK. It doesn't seem the author of QuestyCaptcha has seen fit to provide an alternative exemption mechanism since then, either that or the documentation for the extension was still out of date last time I checked it. --Quasar (talk) 03:59, 1 July 2014 (UTC)


 * Editors should have the skipcaptcha, movestable, and movefile user rights. I think that's common sense.    Ryan W (talk) 00:17, 4 July 2014 (UTC)


 * I think that what he means is that we have an extension called QuestyCaptcha which cannot be configured via user groups other than . (Correct me if wrong.) --Kyano (talk) 00:20, 4 July 2014 (UTC)


 * I might be more apt to agree if we didn't have autopromotion enabled; if we're going to grant dangerous rights such as movestable to people who earn autopromotion, then we'll have to make the promotion criteria more strict as we discussed earlier but never got around to actually configuring due to the sheer amount of other stuff necessary. --Quasar (talk) 13:26, 4 July 2014 (UTC)


 * I've assigned to the editor and reviewer groups, but the other proposals from Ryan will require due caution. --Quasar (talk) 15:30, 4 July 2014 (UTC)

Tags
Just out of curiosity, I would like to know what are the rules that trigger tags. --Kyano (talk) 00:44, 4 July 2014 (UTC)


 * Most of them are created by AbuseFilter. --Quasar (talk) 15:19, 4 July 2014 (UTC)

July 4 vandalism
After the blanking of two articles of primary import, I think we should discuss whether or not the article blanking abuse filter should be set to disallow instead of tag. How often will anon editors have a legitimate need to blank any article? --Quasar (talk) 15:56, 4 July 2014 (UTC)


 * I say never. --Kyano (talk) 16:18, 4 July 2014 (UTC)