Difference between revisions of "Doom Wiki:Central Processing/2015"

From DoomWiki.org

m (Upgrade Plans)
(siteadmin)
Line 137: Line 137:
  
 
:: 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?    [[User:Ryan W|Ryan W]] 19:57, 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?    [[User:Ryan W|Ryan W]] 19:57, 5 April 2014 (UTC)
 +
 +
:: P.S.  [https://bugzilla.wikimedia.org/show_bug.cgi?id=42303 Nope, not fixed yet.]    [[User:Ryan W|Ryan W]] 02:13, 13 April 2014 (UTC)
  
 
=== ''tboverride-account'' ===
 
=== ''tboverride-account'' ===

Revision as of 21:13, 12 April 2014


Archived discussions

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

  • 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.

--Quasar 14:06, 13 March 2014 (UTC)

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:
<source lang=php>string $foo = '\ . $bar . '\;</source>
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)

<tt>, <code>, 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 <tt> or <code>.

  • <tt>: that's what's being used in most of our articles now. It looks_like_this().
  • <code>: that's what's used in a few articles. It looks_like_this().

As you can see, the biggest apparent difference between the two is that <code> adds a grey background.

I personally support changing all <tt> occurrences to <code>. There are several reasons from my point of view:

  • <code> 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 Hello world program article. As you can see, they use <code> for all code samples inside sentences. On top of that, the big snippets of code also have a grey background, for consistence.
  • <tt> is currently deprecated and does not exist at all in HTML5. Should MediaWiki transition to HTML5, all <tt> 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 <tt>, <code>, <pre> and the source extension look much smaller than the rest of text. Wikipedia noticed the bug and then fixed it by adding these lines to their CSS file:

<source lang="CSS"> /* Fix so tags look the same in Google Chrome. */ tt {

   font-family: monospace, sans-serif;

} </source>

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 <tt>blah</tt> by {{c|blah}} instead of replacing it by <code>blah</code>. 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 <source> tags inside a prettytable. --Gez 15:28, 29 March 2014 (UTC)
That's another possibility, suggested by Quasar. At that moment, I thought it would be overkill (like using a template just for bold text), but maybe it's the best solution.
By the way, I think a grey background for <source> should by added with CSS so we don't have to do dirty tricks. --Kyano 20:37, 29 March 2014 (UTC)
I agree with Gez as previous discussed on IRC that <code> with a gray background is inappropriate for single words in the middle of a sentence. It harms readability. BTW I slightly edited your comment to maintain the discussion formatting, Kyano. I favor the template as a long-term solution and I believe it should simply expand to <span style="font-family: monospace, sans-serif;">{{{1}}}</span> --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 suppressredirect. Cleaned up some other stuff while I was in there - chiefly, trying to setup captcha skip for emailconfirmed group as recommended by the ConfirmEdit documentation on MediaWiki does absolutely nothing because emailconfirmed 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)

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 tboverride, 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:

  • 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.

--Quasar 17:53, 12 April 2014 (UTC)

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)