Difference between revisions of "User:Aichon/Archive 2013"

From The Urban Dead Wiki

Jump to: navigation, search
(Archiving)
m (fix link)
Line 207: Line 207:
 
:::Dude, you're never going to veto ''somebody you nominated'' anyway, so it's completely irrelevant. All you nominating somebody does is say that you're content that they're a good enough candidate and aren't going to veto them. If you change your mind in the process of the bid then the fact that you originally nominated them is completely irrelevant. If you were never going to change your mind anyway then it doesn't matter because you wouldn't have vetoed anyway. This is in no way a big deal and crats should feel free to do whatever they want.--{{User:Yonnua Koponen/signature}} 20:43, 19 March 2013 (UTC)
 
:::Dude, you're never going to veto ''somebody you nominated'' anyway, so it's completely irrelevant. All you nominating somebody does is say that you're content that they're a good enough candidate and aren't going to veto them. If you change your mind in the process of the bid then the fact that you originally nominated them is completely irrelevant. If you were never going to change your mind anyway then it doesn't matter because you wouldn't have vetoed anyway. This is in no way a big deal and crats should feel free to do whatever they want.--{{User:Yonnua Koponen/signature}} 20:43, 19 March 2013 (UTC)
 
::::I'm with you on the irrelevancy topic, which was more or less what I concluded in the wall of text above. The followup topic is whether or not nominating is the best choice to take. I.e. Is the fact that it's known by many to be irrelevant sufficient to outweigh the concerns that the 'crat will ''appear'' more partial by having stated their opinion so publicly? {{User:Aichon/Signature}} 21:34, 19 March 2013 (UTC)
 
::::I'm with you on the irrelevancy topic, which was more or less what I concluded in the wall of text above. The followup topic is whether or not nominating is the best choice to take. I.e. Is the fact that it's known by many to be irrelevant sufficient to outweigh the concerns that the 'crat will ''appear'' more partial by having stated their opinion so publicly? {{User:Aichon/Signature}} 21:34, 19 March 2013 (UTC)
:I'm still processing most of that, but I think I'm of the belief that full disclosure occurred when you posted the nomination, because that indicated that you had a biased stance. To take a counterpoint example, in [[UDWiki:Administration/Promotions/Peralta|Peralta's bid]] last year, you revealed after the bid had been withdrawn that you were in favor of Peralta's elevation to sysophood (in the post "The Good, The Bad, The Ugly"). While I don't doubt that your personal opinion in that case had no bearing on how you would have processed it had the nomination not been withdrawn, I think it could be argued that by not revealing your personal preference you were not giving the community full disclosure. So I guess I'm saying that I think you did the right thing in nominating me, because if you hadn't, your strong bias would have gone undiscovered until the end (or not at all). I don't know; it's really late at night.
+
:I'm still processing most of that, but I think I'm of the belief that full disclosure occurred when you posted the nomination, because that indicated that you had a biased stance. To take a counterpoint example, in [[UDWiki:Administration/Sysop Archives/Peralta/2012-11-19 Promotion|Peralta's bid]] last year, you revealed after the bid had been withdrawn that you were in favor of Peralta's elevation to sysophood (in the post "The Good, The Bad, The Ugly"). While I don't doubt that your personal opinion in that case had no bearing on how you would have processed it had the nomination not been withdrawn, I think it could be argued that by not revealing your personal preference you were not giving the community full disclosure. So I guess I'm saying that I think you did the right thing in nominating me, because if you hadn't, your strong bias would have gone undiscovered until the end (or not at all). I don't know; it's really late at night.
 
:That aside, I do think I would prefer if SZ processed the bid, to avoid a kerfuffle among the community. I would still expect you to add your input, as I think you can still make a good judgement call about which way the community is pointing, if not necessarily about how you yourself are pointing. I guess that's what I vote for when I vote for a bureaucrat; someone who can be a successful barometer of the community, while minimizing the influences of his own biases. {{User:Bob Moncrief/Sig}} 06:58, 19 March 2013 (UTC)
 
:That aside, I do think I would prefer if SZ processed the bid, to avoid a kerfuffle among the community. I would still expect you to add your input, as I think you can still make a good judgement call about which way the community is pointing, if not necessarily about how you yourself are pointing. I guess that's what I vote for when I vote for a bureaucrat; someone who can be a successful barometer of the community, while minimizing the influences of his own biases. {{User:Bob Moncrief/Sig}} 06:58, 19 March 2013 (UTC)
 
::Well, disclosure was unnecessary there since there was no reason for there to be a perception of wrongdoing on my part (i.e. no conflicts of interest). Unless you want to make an argument that transparency is ''always'' necessary, disclosure for its own sake is not always desirable. Besides which, even if you do think that disclosure is good for its own sake, I could have done it in a different way that didn't lead to a conflict of interest, such as by letting someone else nominate you and then merely vouch for you afterwards.  That would have meant no conflict of interest while still having full disclosure. Would that have been a better way to handle things? I think so, though I don't (yet) regret having done what I did. {{User:Aichon/Signature}} 07:38, 19 March 2013 (UTC)
 
::Well, disclosure was unnecessary there since there was no reason for there to be a perception of wrongdoing on my part (i.e. no conflicts of interest). Unless you want to make an argument that transparency is ''always'' necessary, disclosure for its own sake is not always desirable. Besides which, even if you do think that disclosure is good for its own sake, I could have done it in a different way that didn't lead to a conflict of interest, such as by letting someone else nominate you and then merely vouch for you afterwards.  That would have meant no conflict of interest while still having full disclosure. Would that have been a better way to handle things? I think so, though I don't (yet) regret having done what I did. {{User:Aichon/Signature}} 07:38, 19 March 2013 (UTC)
Line 657: Line 657:
  
 
== Date format ==
 
== Date format ==
DD-MM-YYYY being mistaken for MM-DD-YYYY could easily as well happen for YYYY-MM-DD and YYYY-DD-MM. Besides, there is only country in the world stupid enough for not maintaining an orderly format. --[[User:MisterGame|<span style= "color: darkblue; background-color: white">'''Thadeous Oakley''']]</span> [[User_Talk:MisterGame|<span style= "color: gold; background-color: white">'''''Talk''''']]</span>  20:51, 5 June 2013 (BST)
+
DD-MM-YYYY being mistaken for MM-DD-YYYY could easily as well happen for YYYY-MM-DD and YYYY-DD-MM. Besides, there is only country in the world stupid enough for not maintaining an orderly format. --[[User:MisterGame|<span style= "color: darkb
:That's not exactly true. There are no known cultures on earth that make use of the YYYY-DD-MM format, whereas YYYY-MM-DD is intuitive, sensible, and in common use in a number of nations and cultures, meaning that ambiguity is essentially as unlikely as it can possibly be in this context, and that the one being mistaken for the other could not happen very easily at all. In contrast, you and I are both aware of how ambiguous DD-MM-YYYY and MM-DD-YYYY can be when dealing with people from around the world, since there are billions of people on one side and hundreds of millions on the other. And while I do agree that the US' MM-DD-YYYY format is "stupid", I'd also fault those who use DD-MM-YYYY for "not maintaining an orderly format", since it doesn't order itself chronologically when lexicographically sorted, which would seem to be an obvious trait that would be desired. Long story short, ISO >>>>> everything else. {{User:Aichon/Signature}} 21:27, 5 June 2013 (BST)
+
::Also, Belize is as stupid as we are, apparently. They use MM-DD-YYYY too as their main format. :P {{User:Aichon/Signature}} 21:32, 5 June 2013 (BST)
+
:May I cut in?
+
:Scratch this in case you feel that it should be left out for any reasons.
+
:Well,if there's an automated signature imprinting the exact date and time (such as  the above:5 June 2013 (BST)),then either ways the format would become clearer by comparison.
+
:Even so,I'd have t concur that keeping a standard format may help everyone making things simple,clean and clear for all eventually.
+
:It may work with having the month alphabetically written. That solves showing dates such as 2012:6:8 or 8:6:2012.
+
:Also,when in Rome-do as the Romans do.
+
:[[User:Concerned&#39;Citizen|Concerned&#39;Citizen]] 07:27, 6 June 2013 (BST)
+
::There was some context to this conversation that you're unaware of. We were talking about the [[UDWiki:Administration/Sysop_Check|Sysop Check]] page, and since it uses future dates, we can't use auto-generated timestamps like we can with signatures. {{User:Aichon/Signature}} 15:51, 6 June 2013 (BST)
+
:As a point of fact the stupidiest(logic wise) date order is actually day, month, year. It's ass backwards when you need to know the year to know the length of days in a month and you need to know the month to know the length of days in a month. Logically it follows that [[wikipedia:Big-endian|Year, Month, Date]] is appropriate and forgiving movement of year to the end for common practice reasons(since you're basically supposed to know the year regardless) months limit days and has informational priority. So really it's all about how China and Japan calculate time. Anyone defending anything else is arguing for idiocy and at least middle-endian doesn't completely abandon logic when vocalization makes it the vocal big-endian.(You say November 5th not November 5th, 2013 when talking in the current year). Also, in addendum, the 'more people use it' argument loses ground when you know that India uses both month day and day month with one being the governmental method of practice since they were a colony and the other being the one popular in it's culture and media. --<small>[[User:Karek#K|Karek]]<sup><font face="Monotype Corsiva">[[User:Karek/ProjDev#Buildings_Update_Danger_Maps|maps 2.0?!]]</font></sup></small> 08:01, 6 June 2013 (BST)
+
 
+
::Additionally now it can sort dates right with the exception of year followed by month Abbrevs but you all should still follow [[wikipedia:ISO_8601|ISO 8601]] because it's just right. --<small>[[User:Karek#K|Karek]]<sup><font face="Monotype Corsiva">[[User:Karek/ProjDev#Buildings_Update_Danger_Maps|maps 2.0?!]]</font></sup></small> 08:42, 6 June 2013 (BST)
+
:::I didn't know it could do that. Neat fix. Learn something new every day. :) {{User:Aichon/Signature}} 15:51, 6 June 2013 (BST)
+
 
+
 
+
== Editting User Pages ==
+
I was looking around at all the pages that call on the 5000 or so danger report templates, and I noticed that a lot of them were userpages.
+
Since we're experiencing so much lag these days when the danger reports get updated, I was wondering if I could delete or disable the superfluous ones? Putting nowiki tags on them, with a little explanation that we disabled it because of performance issues and because they were unused. Problem is: they still are other peoples' user pages and I'm not sure what the wikipoliticians and wikilawyers would say about this, so any advice? {{User:Peralta/Signature}} 14:51, 18 June 2013 (BST)
+
:The lag isn't from them. The lag is from the Danger Center needing to re-grab all 5000 templates every single time a single one of them changes, since the cache for the page needs to be recreated. Right now, updating a danger report might kick off, say, 5000 updates for the Danger Center and another 10 updates for the other pages mentioning that danger report, giving us a total of 5010 updates to do. Quite obviously, removing the 10 won't have a significant impact on performance. {{User:Aichon/Signature}} 15:11, 18 June 2013 (BST)
+
::Quite a lot of the pages I'm talking about are like [[User:Kelenius/Dakerstown Status Map|this one]], and call on about 50 everytime a single one of them changes. If we look at the "What links here" of the first one in the topleft corner, [[Special:WhatLinksHere/User:DangerReport/Palprey_Road_Police_Department]], one which is among the lesser used ones and lesser known ones, we see that several of those pages call on dozens of templates, including used, unused and personal test status maps, as well as specific building status maps (in this case the [[PD Status Map]]. That could amount to quite a lot of pages, each calling on a couple dozen templates, just for one danger report update, no? {{User:Peralta/Signature}} 15:18, 18 June 2013 (BST)
+
:::[[wikipedia:Help:Job_queue#Updating_links_tables_when_a_template_changes|In this case it would make no difference because it's a by page thing and not a by call thing]]. --<small>[[User:Karek#K|Karek]]<sup><font face="Monotype Corsiva">[[User:Karek/ProjDev#Buildings_Update_Danger_Maps|maps 2.0?!]]</font></sup></small> 16:50, 18 June 2013 (BST)
+
::::I still don't really understand? The lag increased when we added the danger center, and it occurs more when updating the danger reports than when you look at the center itself. AFAIK the amount of times a danger report is called upon has a direct influence on that lag, ergo reducing the amount of maps that call upon a danger report should reduce the overall lag. Right? {{User:Peralta/Signature}} 16:59, 18 June 2013 (BST)
+
:::::What Karek is saying (and what I was typing up before I saw that he had already linked exactly what I was going to say) is that the Danger Center is a gigantic job, whereas the other pages are not. The reason that matters, is because the wiki is configured to process one job in the queue per page load. As such, those smaller pages are not even getting processed at the same time as the Danger Center and are thus in no way contributing to the unresponsiveness that people are suffering. To draw an imperfect analogy, the job queue is like a relay race where every time the baton is passed a page gets loaded for a user. In this race, some runners (jobs) are slower than others. Quite obviously, you can improve the speed of the faster runners all you want, but you'll still be waiting the exact same amount of time for the slower ones to complete their laps and pass the baton. So, more or less, those smaller pages aren't contributing to the problem at all, since the unresponsiveness they create is separate from what people are complaining about and is small enough that most of us have never noticed it at all. {{User:Aichon/Signature}} 18:39, 18 June 2013 (BST)
+
::::::<del>Technical gobbledegook-> Yeah, sorta this. Basically everytime you load a page the job queue processes 1 job. Everytime you have a template on a page it loads a function and then on repeat calls of the template it just references the already loaded function. Different templates do have different costs but that's based on the size of the initial template, not so much the number of times it's called(which has a much smaller impact). Everytime you call a unique template the server has to go and make a new database connection and call that template's page content to then queue it up for the preprocessor/job queue. Batch processing it with the job queue means instead of having a half hour of horrific lag(where you have thousands of database connections and nothing can load) you queue up the change and then half multiple hours of much more negligbile lag(where you just double the normal page loads).</del> Super simple version is instead of having 5000 pages load when you edit danger reports it makes it so that for the next 5000 pages loaded you're basically loading 2 pages. --<small>[[User:Karek#K|Karek]]<sup><font face="Monotype Corsiva">[[User:Karek/ProjDev#Buildings_Update_Danger_Maps|maps 2.0?!]]</font></sup></small> 18:49, 18 June 2013 (BST)
+
:::::::It sounds like you may have accidentally said the opposite of what you meant. Just to double check, as you said above, the queue adds jobs on a ''per-page'' basis, which means that the Danger Center is processed as a single job, just as each of those other pages is also processed as a single job (though clearly the Danger Center is a larger job). When a user visits a page, the wiki does the job at the front of the queue before it delivers the page to the user. When a danger report gets updated, each page that transcludes that danger report will receive a corresponding job to update the page. For those smaller pages, because they each have their own job, they get spread out over a number of page loads and cause no noticeable delay. For the Danger Center, it too is done as a single job attached to a single page load, but because it's a much larger job it creates an extremely noticeable delay (i.e. it does the 5000+ db operations you're talking about). I think that's what you meant to say, but please correct me if I'm mistaken. {{User:Aichon/Signature}} 19:55, 18 June 2013 (BST)
+
::::::::A lot of this is going to be process descriptive but not exact to how the code runs. It functions like a php include that contains a class with only a single method that's being batch processed. What happens is essentially when you update a template it checks to  see how many rows return in the table(see picture below) of transclusions. It then adds those pages(where the template is transcluded) to the jobs queue if there are more than a certain number.<br /><br /> The jobs queue then runs a preprocessor on each of those individual pages. The preprocessor runs through the page content sequentially until it finds text matching what it sees as a template call. It then runs that call through a check against all other held templates/functions already preprocessed, if it returns that none are already stored it queues up a database call to the page(usually a template) being transcluded. It searches for include only tags then for noinclude tags to determine content and then [[Wikipedia:Template_limits#What_is_this_about.3F|converts the uneliminated text]] into [http://www.w3schools.com/xml/xml_tree.asp XML Trees] and stores this as a callable variable to be referenced when the same template is called later in the text. That means it only calls the template from the database once per page instead of however many times the template is included in the page.<br /><br />Once the preprocessor sets limits on the generated text size for the final result and stops converting template content after a certain point. There are a number of reasons for this but the biggest one I can imagine would relate to the topic of [http://research.microsoft.com/pubs/64525/tr-2006-45.pdf this white paper] microsoft released a few years back(pages are stored in blobs) about large file vs blob performance. The end result all then gets thrown through the parser when the page is called which converts wikitext like to it's output state.<br /><br />My understanding is thus that when a page does not hit the rows returned in the 'Pages Included On' check it runs the preprocessor in reverse, thus processing all of the pages then and there making x calls where x is the amount of pages it's included on. When it determines that this would be too much strain for the server based on the limits set it instead queues them up for batch processing so that the calls are processed at a set interval and not all at once. --<small>[[User:Karek#K|Karek]]<sup><font face="Monotype Corsiva">[[User:Karek/ProjDev#Buildings_Update_Danger_Maps|maps 2.0?!]]</font></sup></small> 03:07, 19 June 2013 (BST)
+
:::::::::I love the technical description (honestly, I do), but that's actually tangential to what I was asking. You already explained the details below, and I thought it was well understood that that's what the function of the job queue is, since it's basically just "baking" elements for later use. What I was talking about was specifically the un-struck line you left, since the problem we're having is that it's ''not'' being broken up into 5000 jobs, which is what it sounds like you were suggesting is happening. That's why I said you sounded like you were saying the opposite of what you meant. ;) {{User:Aichon/Signature}} 05:34, 19 June 2013 (BST)
+
::::::::::I was insanely oversimplifying, the default value is [http://www.mediawiki.org/wiki/Manual:$wgUpdateRowsPerJob 500 operations] and each job itself is 500 operations. So with a current job queue of 6 that's roughly 3000 transclusions. Basically it is just the numbers are obscured, additionally [[user:Kevan|Kevan]] might have changed it but it's unlikely. --<small>[[User:Karek#K|Karek]]<sup><font face="Monotype Corsiva">[[User:Karek/ProjDev#Buildings_Update_Danger_Maps|maps 2.0?!]]</font></sup></small> 06:16, 19 June 2013 (BST)
+
+
:::::[http://upload.wikimedia.org/wikipedia/commons/5/57/MediaWiki_1.20_%2844edaa2%29_database_schema.png This] may help some. The Job Queue, from my understanding, basically functions like the preprocessor for templates so that the stored wiki text can be served faster on significantly large template calls to minimize load time. Templates are thrown into the job queue based on how many pages need to be preprocessed and it converts them into wiki-text/html there. Because job queue processing isn't done through a cron or based on server load it's happenning while other things are being done on the server, so lag will increase be it 1 template call on a page or 10 as it's running the same script either way. As far as impact on performance, because there's no additional complexity to the call(you should only have to queue up the template's content once regardless) it's of neglible impact of processing speed. You get a bigger impact from an increase in unique templates as 0-1 is where you're having to open a new file stream or make a new databse connection(which is likely the cause of the lag). [http://musialek.org/?p=94 Preprocessor ref]. This is also one of many reasons templated signatures suck, they slow down the wiki for everyone, particularly more so the more pages they're on. --<small>[[User:Karek#K|Karek]]<sup><font face="Monotype Corsiva">[[User:Karek/ProjDev#Buildings_Update_Danger_Maps|maps 2.0?!]]</font></sup></small> 18:43, 18 June 2013 (BST)
+
 
+
Too bad, I really hoped to optimize this whole thing... Then again: the danger reports ''are'' updated regularly these days, even more with BB4, and that was always one of the goals :) Maybe I'll go on a little wiki-patrol later today and just list a ton of stuff that can be deleted or otherwise archived to clean the whole wiki a bit out. {{User:Peralta/Signature}} 12:54, 19 June 2013 (BST)
+
:If you want to optimize these pages you could make the core templates use non-wikicode code, here's a list [[wikipedia:m:Help:HTML_in_wikitext|m:Help:HTML_in_wikitext]], it'll reduce the work done when the parser runs. --<small>[[User:Karek#K|Karek]]<sup><font face="Monotype Corsiva">[[User:Karek/ProjDev#Buildings_Update_Danger_Maps|maps 2.0?!]]</font></sup></small> 22:12, 19 June 2013 (BST)
+
 
+
 
+
== Mob Locator Map Style Practice ==
+
Hi Aichon,
+
you should update the comment on http://wiki.urbandead.com/index.php?title=Militant_Order_of_Barhah/Locator&action=edit&section=3 to reflect the actual practice which is used to colour the map.
+
greetings [[User:Ja7|Ja7]] 13:09, 25 June 2013 (BST)
+
:Sorry, I got it wrong. See my edits to MOB Locator. {{unsigned|Ja7|13:12, 25 June 2013}}
+
::Yup, looks like you got it figured out, though I really need to update the Locator since it's several suburbs out of date at the moment. {{User:Aichon/Signature}} 15:46, 25 June 2013 (BST)
+
 
+
 
+
== A/SA questions ==
+
I'm planning to start moving the A/PM archives into A/SA format, and I had a couple questions.
+
#What do we do about awkward redlinking of archives for those who were never sysops? [[UDWiki:Administration/Sysop Archives/Akule/2008-04-01 Promotion|Example]] - "Akule" is redlinked in the breadcrumbs.
+
#I'm planning to convert the A/PM navtemplates so they can be kept in one location, and am adding [[:Category:Promotions_Candidacies|a key]] to make them more detailed. Would something like that (or which already exists for A/BP) be useful for A/RE and A/M as well? (Not to be included on each page, but be in one location for cross-referencing.)
+
 
+
Thanks! {{User:Bob Moncrief/Sig}} 16:40, 18 August 2013 (BST)
+
:There's nothing saying we can't make pages for the non-sysops too, and with your changes to put it all in tables, it seems like the concerns we have about it taking up too much space have been alleviated pretty well. I'm thinking give them their own page, and kill two birds (the red-link and the fact that the table will get bulky as we add data) with one stone.
+
 
+
:As for the key, I kinda feel like the improved categorization is designed to remove the need for keys and color-coding sort of stuff, though the categories could definitely be better-linked from A/SA in order to make them more useful. {{User:Aichon/Signature}} 21:50, 18 August 2013 (BST)
+
::Ok! I can make pages for them easily. I'm gonna stick with making the key for now, mostly as a way for me to keep track of which ones I've moved so far; it can always be easily de-keyed later. {{User:Bob Moncrief/Sig}} 01:08, 19 August 2013 (BST)
+
 
+
 
+
== IRC ==
+
Can you jump on when you've got a minute, please? --{{User:RenegadeRomero/Sig}} 20:50, 20 August 2013 (BST)
+
:Done. {{User:Aichon/Signature}} 20:58, 20 August 2013 (BST)
+
 
+
 
+
== A/D ==
+
As a note, Revenant's revelation would be what would normally be a checkuser policy allowance. In this case he actually would probably be one of the better authorities on this since he can potentially compare it to one of the various RG boards. Odds are this is another Nubis type situtation in which case you guys should lock the account in question and send an email via the wiki, if possible, letting him know what has happened, why, and how he can contact one of you guys to resolve it. --<small>[[User:Karek#K|Karek]]<sup><font face="Monotype Corsiva">[[User:Karek/ProjDev#Buildings_Update_Danger_Maps|maps 2.0?!]]</font></sup></small> 04:48, 26 August 2013 (BST)
+

Revision as of 02:58, 20 September 2013

Aichon:Talk Archive 2013
Aichon
ˈīˌkän :Talk Archive 2013
Personal tools
project wonderful
column-okay