The Sims Wiki talk:Admin Portal

User:ILoveSims5
has no history of constructive edits outside of her own userspace, and has a history of repeatedly vandalizing infobox templates after being warned and blocked for that. Given that, I propose that we go straight to a permanent block the next time she vandalizes. Dharden (talk) 04:18, January 30, 2014 (UTC)
 * Seeing that her edits have been in the area of templates, we may temporarily lock the page (not the best practice IMO), extend her ban length, or give her an editing restriction in template namespace. It might need to take a little while until she could get a permanent ban.  Nikel  Talk  –  Vote!  05:53, January 30, 2014 (UTC)
 * I'd be more in favor of giving her blocks of increasing length. She's already had a 1-day block, so the next logical step would be a 3-day block. That's what I'd personally do, but I wouldn't oppose an indefinite block either. --  LostInRiverview talk ~ blog 06:03, January 30, 2014 (UTC)
 * Normally I'd put my faith into believing that there is some hope and that this user would change their approach to editing the wiki. This isn't one of those situations. The lack of any constructive contributions and persistence to vandalise despite being warned several times speaks for itself and I for one wouldn't mind a permanent block here. 14:16, January 30, 2014 (UTC)
 * That's pretty much the reasoning I was using. I'd support escalating blocks or a restriction on editing templates if this user had made some good-faith edits or had shown some sign of being reachable, but she hasn't. Dharden (talk) 04:06, January 31, 2014 (UTC)

Interpretation of RfA rules in relation to a current request
I have specifically asked for input from TSW's currently-active bureaucrats (other users are welcome to input as well) regarding an issue with the current RfA nomination. We're coming to the end of the initial five day discussion period and, while it's clear based on the input there that a consensus is not present to support promotion, I'm not sure whether the RfA should be dismissed or whether discussion should continue (with the possibility that it may eventually move to a vote).

My indecisiveness comes from the wording and meaning of the RfA nomination rules, the relevant bits of which I will paste here, with important points bolded:


 * Stage 2 - Discussion
 * After the five day period of discussion has elapsed, it shall be determined whether a consensus has been reached. Consensus can only be reached in favor of a nominee, not in opposition to them. If the discussion shows consensus for a nominee, the nomination is successful and the user is promoted. If the discussion clearly shows a lack of consensus, the nomination will be ended and the nominee will not be promoted.
 * In cases where a consensus is not clear after the initial discussion period, discussion will continue until there is a two-day long period, or longer, in which nothing is added to the discussion.
 * If this occurs and a clear consensus exists, the nomination is successful and the user is promoted.
 * If this occurs and a consensus in support is not clear, the nomination will proceed to Stage 3.

The issue here is in the definition of 'consensus'. TSW doesn't have a formal definition set up for this term, as far as I'm aware, but a quick web search of the term gives a dictionary definition of "general agreement."

So, to rephrase the rules into simpler terms, if a nomination shows a general agreement for promotion, promotion takes place. If a nomination shows a lack of general agreement about promotion, it fails. If it's not clear whether or not there is general agreement, discussion continues and may result in a vote.

Based on the current status of Joey.eyeball's RfA, a general agreement about promotion clearly does not exist. So, by the meaning of these words and the interpretation of the rules as written, this RfA should be closed down due to lack of consensus. However, I am curious as to whether it was truly our (as the community's) intent to set it up this way. The reason I'm curious is because of the next point - "In cases where a consensus is not clear." If going by the straightforward definition of consensus, I can see very very few circumstances where a consensus wouldn't be clear in one direction or the other. In reality, you either have a general agreement about something or you don't, but very rarely would you be in a position where you don't know just by looking at it whether or not you have that general agreement.

I believe that up to now we have assumed a different meaning for these terms. I think that we have generally worked under the idea that, unless consensus was clearly against a nomination, we would at least allow it to proceed to a vote, then use the strict rules under Stage 3 to determine the outcome. If that's the case, then in the near future we should seek to clean up the language to state as such. But, that still leaves the matter of the current RfA.

At the present time, and if acting in-line with the rules as written, I would close down Joey's RfA without proceeding to a vote. However, I am not comfortable with taking this action given what I see as a discontinuity between the rules as written and what I perceive to be the intent of the rule as it was originally written. I can't even say for sure whether I would support making the rule mean what I believe it does, but that's a discussion for the community and not really the present matter of concern.

So, let's figure this out. --  LostInRiverview talk ~ blog 02:50, February 4, 2014 (UTC)


 * Gnarr.... On one hand, it explicitly says that consensus cannot be reached against a nominee. On the other, there seems to be an implicit assumption that it can be. Gnarr.... As for the current RfA, the difference seems to be not on whether to support a promotion, but whether it should be done now or later. Dharden (talk) 03:15, February 4, 2014 (UTC)
 * RfAs need two-thirds support to pass and we have roughly the opposite of this here, so I'd just close it as unsuccessful and forgo the vote, though it does seem to be a close call here if we take into account that the nomination clearly supports the nominee. This isn't usually an issue for self-nominations but here the circumstances are rather different.


 * The issue at hand seems to be that how the nominations rules are written can be confusing. The way I see it is that if the discussion is favourable towards the promotion then the user is promoted while if it's unfavourable then they aren't while we move to a vote if the outcome is undecidedly split to the point where it would be impossible to determine consensus.


 * Confusing choice of words or a fatal flaw with the RfA system? I don't know. Maybe this is worth a more in-depth discussion but this is just my two pence on the matter. 15:10, February 4, 2014 (UTC)
 * I think the biggest problem here may be a discrepancy between what the rule says and what we its meaning to be. Take, for instance, the points Lab has just raised - in a vote, it takes 2/3rds support to pass, but he also says that it passes if discussions is favorable towards promotion - which could in theory happen even if the nominee would otherwise receive only a majority support (>50% but <66.7%) but not meet the vote threshold we've established. So perhaps the stricter wording in the interpretation I've laid out above is better? Perhaps if we had wanted the nominee to receive only a majority support, we would have stated so in the discussion rules? Perhaps the consensus rule isn't incorrect after all, but our prior interpretation of it was?
 * As Lab has said already, this is probably a topic for the greater community to chew over, so I'll be starting a thread in Community Discussions soon. In the meantime, I am suggesting that we close down the request. --  LostInRiverview talk ~ blog 15:20, February 4, 2014 (UTC)
 * Now that the discussion is brought up, it does appear that the term "consensus" has a confusing meaning. Even more confusing is what the term "lack of consensus" means. In the discussion, we state our reasoning whether we support a nominee to be an admin or not. Although in a discussion it says that our statement is what really matters in making a conclusion, it's only like "agree / disagree" or "yes / no" as we simplify it in voting. In that way, the possible outcome would be either support or opposition, and there doesn't seem to be a way that makes it "unclear".


 * In Mate's RfA, the discussion tends to not support (not now, weak support, not ready) instead straight oppose. Is this what it means by "unclear"? It doesn't shut the possibility that some random user nominates oneself, and I could see that the general input would be straight oppose. Is it what it means by "clear"?


 * So what does "lack of consensus" mean? Does it mean lack of support, or lack of community input? In Mate's RfA where voting is implemented, it seems to be both. But I feel like the voting is implemented because the community input is inclined to be lacking, and that's when the term "unclear" would make sense too.  Nikel  Talk  –  Vote!  05:14, February 5, 2014 (UTC)
 * Nikel, that's really the heart of what we're talking about... when we say something 'lacks consensus', do we mean that it is being opposed, or do we mean that it simply doesn't have resounding support? If going by dictionary definition, then something which has 50% of people agreeing and 50% disagreeing lacks consensus, even though half of them are in support. If going by what seems to be past precedent, in a 50/50 scenario we'd probably resort to a vote, despite the fact that this scenario clearly represents a "lack of consensus," since consensus means general agreement and a 50/50 split hardly represents agreement about anything. So the question here is whether we want to go by what is written, or whether we should re-write the rule to allow votes in close discussions instead of simply "unclear" ones. --  LostInRiverview talk ~ blog 05:23, February 5, 2014 (UTC)
 * I've made a thread that stems off of this discussion in a way of tackling this issue. 13:40, February 5, 2014 (UTC)

User:Ilovemondler
I suspect that this may be ILoveSims5 attempting ban evasion. Dharden (talk) 02:36, February 17, 2014 (UTC)
 * Judging from her alias, her being in Friends wiki, and her biodata, it's highly likely that she's a sock. We could charge her for attempting ban evasion after ignoring the second chance for her to get unbanned from LiR.  Nikel  Talk  –  Vote!  02:44, February 17, 2014 (UTC)
 * Will send in a CheckUser request to Wikia. If the CheckUser confirms that this account is a sockpuppet of ILoveSims5, we can block this one. K6ka (talk &#124; contribs) 02:48, February 17, 2014 (UTC)
 * How is the check going? I'm not sure if the staff is willing to accept the request for a user with not-so-disruptive behavior. I think her biodata clearly resembles the blocked user, though her behavior doesn't.  Nikel  Talk  –  Vote!  03:23, February 18, 2014 (UTC)
 * The evidence that this is a sock is pretty overwhelming. Even if we get denied for a CheckUser, I say we should block the account. --  LostInRiverview talk ~ blog 03:27, February 18, 2014 (UTC)
 * Received a response from Wikia, confirmed that this is a sockpuppet. Blocking now. K6ka (talk &#124; contribs) 12:08, February 18, 2014 (UTC)

Establishing a new precedent regarding indefinite blocks
As detailed in Lab's blog about Wikia user email, it has been revealed that users will no longer be able to use the email feature to contact other users privately. While this feature isn't used on Wikia or The Sims Wiki nearly as extensively as on Wikipedia, there is one notable exception - user "appeal" emails for indefinite (aka infinite or permanent) blocks from the wiki.

There is no broad guideline set down regarding how users would be blocked indefinitely; some blocks are meant to be permanent, while others are simply indefinite, meaning that they could possibly be ended at some point in the future. The main avenue for reaching an end to an indefinite block was to utilize the email feature, but since that is no longer possible, we might have to determine a new course of action.

What I'm suggesting is that we come to some sort of agreement on how we'll handle indefinite blocks. That is, how we will handle blocks of an indeterminate length. The precedent we apply should be more standardized than it has been in the past, for the sake of fairness. But, because of the changes to the email system, this precedent must also be changed so it can still allow indefinitely blocked users to somehow contact wiki admins. The obvious solution, and really the only one left open to us, is to allow these users to edit their own talk pages. So, I would suggest that, if we indefinitely block a user from now on, we allow them to edit their talk page. In cases where this privilege is abused by the blocked user, it would be with the understanding that the privilege and, therefore, the ability to be unblocked will never be extended again. Perhaps we should also consider adding an 'infinite' block length into the standard lengths; this would allow us to differentiate between 'indefinite' blocks, which can be appealed and possibly terminated, and 'infinite' or 'permanent' blocks which cannot.

Thoughts? --  LostInRiverview talk ~ blog 23:21, February 19, 2014 (UTC)


 * That's what I have in mind when I block users. (Wikipedia-reference up ahead!) The Wikipedia blocking policy generally recommends that sysops allow blocked users to edit their talk pages so they can discuss the block with other admins. Talk page access is only revoked if the blocked editor abuses the privilege (such as using the talk page to insult, harass, make inappropriate unblock requests, or to continue vandalizing). ∴ I am in support of this proposal. K6ka (talk &#124; contribs) 23:28, February 19, 2014 (UTC)
 * I feel we should be doing this anyway. I'm alright with auto-revoking (for the lack of a better term) talk page access for sockpuppet accounts (but let the main account use their talk page unless the abuse is long-term and extensive - it's situational really) and maybe obvious spambots too (most of them are hit-and-run anyway).


 * I'm not sure if we really need both an "indefinite" and an "infinite" block duration listing as if an indef-blocked user is abusing their talk page then we can simply revoke their access and then that's the end of it. I'm not opposed to the idea however.


 * Finally, and slightly derivative of the main topic, are we okay with IRC (seeing as they can't access Chat) being another form of communication with regards to blocked users? I know permabans on-wiki are usually naturally extended to IRC but I'd be okay with these users coming onto IRC to discuss their block and whatnot provided they're not messing around; if they are then we can simply ban them. 13:26, February 24, 2014 (UTC)
 * Requesting on IRC works for me. Though regardless of whether they request on their talk page or IRC, any unblocking of an indefinitely-blocked account should probably be discussed by the admins here. --  LostInRiverview talk ~ blog 19:15, February 24, 2014 (UTC)
 * I'm OK with letting people request unblocking on IRC, but any unblocking of an indefinitely-blocked account should definitely be discussed by the admins here, so that all will have a chance to contribute to it. Dharden (talk) 20:12, February 24, 2014 (UTC)
 * Should we go through the Block list and grant talk page access for users that have had them revoked? K6ka (talk &#124; contribs) 02:15, February 25, 2014 (UTC)
 * I would say yes, except in those cases where they had been extended talk page rights in the past but abused them (there are a few cases of this, they should appear in the block logs). Honestly, I don't think many users would exercise that second chance, but for the sake of fairness I think we should. --  LostInRiverview talk ~ blog 04:14, February 25, 2014 (UTC)

┌─────────────────┘

Threadcromancy, but I'm just gonna be bold and change the block settings for the blocked users - once I can find time, that is. K6ka (talk &#124; contribs) 11:58, March 21, 2014 (UTC)

Handling RfA and RfB pages for users who apply/are nominated multiple times
One of the results of the rights requests reform of last year was the implementation of holding discussions for individual user RfAs and RfBs on sub-pages of the main RfA and RfB page. So, for example, the discussion of promoting K6ka to administrator took place on the "The Sims Wiki:Requests for administratorship/K6ka" sub-page. This procedure works well if a promotion is successful.

However, it is likely inevitable that we will have a user whose first RfA or RfB ended without promotion later apply or be nominated again. If this happened, we would run into a problem, since the first (unsuccessful) would be named TSW:Requests for /, meaning we would need to come up with a unique name to give to the second and subsequent requests. To head off this eventual problem, I've moved all the archived RfA and RfB pages, such that the name of the page now includes the month and year when the page was created. So, for example, K6Ka's successful RfA now is archived at The Sims Wiki:Requests for administratorship/K6ka (January 2014). When new RfA or RfB request pages are created, they should follow this same format as well. --  LostInRiverview talk ~ blog 19:18, February 22, 2014 (UTC)

Shyflower3
Shyflower3 certainly passes the duck test for sockpuppetry. Sock master is Shyflower2, which is a sockpuppet of Holdit, which is a sockpuppet of Scarygirla. Shyflower3 was on chat today and produced violent RP messages. K6ka (talk &#124; contribs) 21:31, February 25, 2014 (UTC)
 * Already banhammered. Just as an aside, you don't have to bring it up here immediately if you see a sock, especially an obvious one. If the evidence is overwhelming, like it was here, then feel free to deal with them yourself. 21:39, February 25, 2014 (UTC)

Administrator Fake
What would happen if a non-administrator added the administrator and / or bureaucrat userbox to their userpage?  C.Syde  ( talk &#124;  contribs ) 06:14, March 16, 2014 (UTC)
 * Those are admin-only userboxes. If a user were to add one, it would be removed and they would receive a warning. --  LostInRiverview talk ~ blog 12:25, March 16, 2014 (UTC)

Jerichovictor11's fanons
has recently been blocked for being underage, and the block expires on November 2015. The problem is, he has a lot of fanons that are low in quality, and putting fanon maintenance templates (i.e. Fanon-cleanup and Fanon-stub) is pointless since the author can't do anything with it anyway. I delete fanon stubs that have been left unedited for considerable amount of time, but I don't really think these fanons should wait for 20 months until it can be improved by the author. Should we keep them by tagging the Fanon-stub templates or delete them outright?  Nikel  Talk  –  Vote!  14:58, March 22, 2014 (UTC)
 * I agree with deletion. --  LostInRiverview talk ~ blog 15:01, March 22, 2014 (UTC)
 * The policy says to delete it anyway. All his fanon has been nuked by technology. 21:11, March 22, 2014 (UTC)
 * Ah, good 'ol adminbots. Should the images he uploaded go as well? If he comes back and wants them back, we could always restore them. K6ka (talk &#124; contribs) 21:15, March 22, 2014 (UTC)
 * Thanks for taking care of them, Lab. The unused files would be piled up in Special:UnusedFiles. Eventually they might be deleted anyway, but I guess he could ask us to restore them.  Nikel  Talk  –  Vote!  16:55, March 25, 2014 (UTC)

Removing a comment from my fanon page
I accidentally logged out while posting a comment on my own fanon page. If it's possible, could an administrator please remove the comment. I've re-posted it under my own userpage. I know it's nothing to be bugged about, but it would be nice to have this comment removed.  C.Syde  ( talk &#124;  contribs ) 05:08, April 2, 2014 (UTC)


 * Done. K6ka (talk &#124; contribs) 10:57, April 2, 2014 (UTC)


 * That's better. Thanks! :)  C.Syde  ( talk &#124;  contribs ) 02:33, April 3, 2014 (UTC)

ILoveSims5
Relocated from Forum:Unblock system

Hey, I noticed that Nikel potentially blocked the IP address for ILoveSims5. If it turns out that this is indeed her IP address, does this mean she will be unable to return to the Sims wiki without requesting an unblock? I was just wondering.  C.Syde  ( talk &#124;  contribs ) 05:01, April 12, 2014 (UTC)
 * By now, I expect her to respond her ban in any of her accounts. She has failed to do that 6 times. If she doesn't communicate with us, nothing will stop her from making even more socks. I allowed her to leave a message in her own IP address talk page, but didn't tell her that. I guess I forgot.  Nikel  Talk  –  Vote!  10:29, April 12, 2014 (UTC)
 * Autoblock was supposedly enabled on all her socks, and all the blocks supposedly disabled account creation. The block settings are carried on into the autoblock, which usually lasts for 24 hours and can autoblock other IP addresses (hence the term "Collateral Damage" when a shared IP is autoblock, in which the MediaWiki software recklessly blocks thousands of innocent users). Call me crazy, but I have no clue how ILoveSims5 is getting around her block. --k6ka (talk &#124; contribs) 11:38, April 12, 2014 (UTC)


 * Okay, looked up the IP address here. It is a static IP address, run by Verizon Online LLC. We should be able to block it safely, though if the IP changes owners, then we'll need to unblock it as soon as we find out. --k6ka (talk &#124; contribs) 11:56, April 12, 2014 (UTC)

Mass article spammer (IP)
Well, it looks like our old friend (well, not old, but "New") has learned the art of clever IP hopping - a dangerous enemy.

IPs 108.40.164.174, 108.40.195.112, and 108.40.198.230 were blocked for vandalism, with the content being the same. 108.40.198.230 also vandalized Wikipedia today - 1, 2, 3, 4, etc. The IP addresses appear to change owners, meaning that, if we block an IP, the next day the vandal is issued a new IP address and now we have an innocent user blocked. Especially with the new edit filter LiR set up; the effectiveness diminishes as the vandal hops around IPs while we block innocent users in a desperate attempt to stop it - similar to trying to fire a cannon at a guy who's running at top speed.

If my limited knowledge in IP addresses is correct, all these IPs are in the same range, so we need to rangeblock the whole darn thing, autoblock disabled, anonymous users only. The IP range is owned by Verizon, for reference. --k6ka (talk &#124; contribs) 22:47, April 14, 2014 (UTC)
 * Oh, if you were wondering about my block - yeah, i accidentally tripped the filter and it blocked me. I'm a clumsy admin. --k6ka (talk &#124; contribs) 22:47, April 14, 2014 (UTC)
 * I did have the range blocked initially prior to the filter coming up, but it doesn't seem to be helping much. I've put the range block back up for 3 months...for now. 23:05, April 14, 2014 (UTC)


 * (For the record, Lab set up the filter, not I.) --  LostInRiverview talk ~ blog 23:27, April 14, 2014 (UTC)