The Sims Wiki talk:Admin Portal

Community

Community Portal (talk) · Community Discussions forum
Fanon Portal (talk) · Game Guide Portal (talk) · Custom Content Portal (talk) · Development Portal (talk) · Admin Portal (talk) · Main Page talk

User:ILoveSims5

ILoveSims5 (talk · contribs · editcount · block · modify rights · logs · block log) 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. Lost Labyrinth • (c) • (b) 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. Lost Labyrinth • (c) • (b) 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. Lost Labyrinth • (c) • (b) 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 | 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 | 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 | 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. Lost Labyrinth • (c) • (b) 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 | 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 | 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 <adminship/bureaucratship>/<User name>, 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 | 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. Lost Labyrinth • (c) • (b) 21:39, February 25, 2014 (UTC)

Jerichovictor11's fanons

Jerichovictor11 (talk · contribs · editcount · block · modify rights · logs · block log) 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)