The Sims Wiki talk:Admin Portal

This is the Admin Portal Talk Page, abbreviated as the APTP. This page is used by administrators to discuss administrative action, responsibilities, and tasks.

While non-administrators are more than welcome to read, browse, and link to discussions on this talk page, they cannot actively take part in discussions. If you wish to contact an administrator, or if you require assistance with anything else that is administrator-related, please start a thread at the administrators' noticeboard.

''These rules have taken effect as of July 31, 2014. Before this date, non-administrators were allowed to participate in discussions on this page, so you may see non-administrators posting here. The proposal and discussion can be found here.''

Issues editing wiki navigation menu
Due to custom css styling on the wiki navigation menu, we are unable to edit the menu. Right now, the style applied to the menu increases the Level 1 menu beyond the maximum width, so that even if no changes are made, the editor warns that the menu is too wide and refuses to let you publish any edits to the menu. I temporarily removed the css style applied to the menu and was then able to successfully make edits to the menu, so that is definitely the culprit here. Knowing that, we have a few options. We could try editing the menu to reduce the width of the level 1 menu, but I don't think that's practical. We could try finding a way to redesign the theme so it doesn't make the menu as wide; it could work, but it would be tedious. We could simply remove the styling from the menu whenever we want to edit the menu, though again it would be tedious. Or we could simply remove the styling from the menu altogether, which would be the simplest solution, but we'd also lose the style that is applied to the menu. --  LostInRiverview talk • blog  •  contribs 14:29, April 5, 2015 (UTC)


 * MediaWiki:Wiki-navigation has a width check when you attempt to save the page. Normally, this width check is supposed to prevent issues with the navbar, such as menus that are too big, so text spills out, or having too many tabs that won't fit. However, this width check is dependent on the web browser and not the actual settings for the wiki. So if your browser happens to supersize the text, tough luck — the width checker will think the tabs won't fit when they do.


 * There are ways to bypass this width check, however, as mentioned at w:Thread:734913. Examples include:


 * Copying the following code into your personal CSS page:

/* Special thanks to User:452 for this! Original taken from http://community.wikia.com/wiki/User:452/global.css?diff=prev&oldid=1343313 */ /* This thing fixes the broken width check in MediaWiki:Wiki-navigation */ .ArticlePreviewInner .WikiHeader li.nav-item a { /* Because the width check is broken. */  margin: 0; padding: 0; }
 * Moving MediaWiki:Wiki-navigation to another title, making the necessary changes, and then moving it back
 * Special:Export the page, make the changes, and then Special:Import it again.
 * Using another program to edit the page, such as AutoWikiBrowser.


 * Keep in mind that removing the width check also increases the possibility of you messing up the navbar (much like drugs that weaken the immune system reduce the chance of organ rejection after a transplant, but increase the risk of infection). It would probably be best to test changes to the navbar on a test wiki before saving the real thing. --I am  k6ka  Talk to me!   See what I have done  15:32, April 5, 2015 (UTC)

Reduce policy page protection?
I think we should consider reducing the protection level on our policy pages, down to semi-protection for editing (while maintaining sysop-only levels for page moves).

Policies are meant to evolve over time, and aren't meant to be treated as hard and constant rules, at least most of the time. Allowing autoconfirmed users to correct issues on policy pages, and make modifications to those pages if relevant, would help to encourage those policies to evolve over time. Additionally, we have enough admins and rollbackers on the wiki to combat any vandalism that might occur. -  LostInRiverview talk • blog  •  contribs 18:12, May 5, 2015 (UTC)
 * I'd be up for this. I don't really see any problems with it. As long as they are autoconfirmed users, and they agree to not vandalise or remove important information from the page, then I see absolutely no problem with it. ~ Beds  (talk - blog ) 19:21, May 5, 2015 (UTC)
 * Support provided that there is a notice added to the top of policy pages that tells users that "Changes made to the policy pages should reflect consensus," much like Wikipedia does. --I am  k6ka  Talk to me!   See what I have done  19:30, May 5, 2015 (UTC)
 * Agree with K6ka's point. Policy can easily be modified to reflect that language. --  LostInRiverview talk • blog  •  contribs 19:56, May 5, 2015 (UTC)
 * Any more input? --  LostInRiverview talk • blog  •  contribs 06:29, June 20, 2015 (UTC)
 * Bump --I am  k6ka  Talk to me!   See what I have done  02:28, July 25, 2015 (UTC)
 * I support this as well. -- Icemandeaf (talk) 02:33, July 25, 2015 (UTC)

Weak oppose, mainly because I am of the opinion that policies are something that should be discussed before changes are written on the slate. I am also of the opinion that our long-standing users are often well informed of the be bold clause of our policy, which already makes our policy more of a loose one than a strict one. However, I am all for allowing registered users to make changes to the policies after all discussions are made. MILK FOR THE UNYUUFEX, FLAT CHEST FOR THE CUTENESS THRONE, SKULLS FOR THE SKULL PROBES (user talk:Mathetesalexandrou) 01:03, July 26, 2015 (UTC)


 * Any controversial edits made to the policy pages that have not been approved by consensus can always be reverted immediately and the user advised to seek discussion to obtain approval from the community. Reducing page protection does not change that fact; even if I decided to amend the policies myself without consensus, I would certainly be reverted. --I am  k6ka  Talk to me!   See what I have done  01:25, July 26, 2015 (UTC)

Topnav menu issues on smaller displays
It appears as though the wiki navigation menu is displayed incorrectly when the wiki is viewed on a lower resolution, such as on a tablet. Namely, the 'Interaction' tab on the navbar is "wrapped" down to the second line, so it collides with the secondary menu text and makes the Interaction menu inaccessible. Any thoughts as to a possible solution? -  LostInRiverview talk • blog  •  contribs 03:07, June 22, 2015 (UTC)
 * Well, technically we've been violating the navigation all along. Under normal circumstances, the current navigation cannot be edited and submitted unless we make a workaround. It was an odd decision since the navigation looked just fine and all the menus fit pretty well, but I guess it turned out we overlooked this case? Aside from that, I don't have any idea for a solution other than to follow the normal navigation width rule by removing some menus.  Nikel  Talk  –  Vote!  11:15, June 30, 2015 (UTC)
 * Nikel, that seemed to be more of a bug (or at least, a very bad update) on Wikia's end. I say this because it was broken on the latest version of Google Chrome, but I tried using an older version of Chrome (and on Firefox) and it apparently worked fine. The page has a width check that's entirely dependent on the browser, and each browser is different. --I am  k6ka  Talk to me!   See what I have done  12:33, June 30, 2015 (UTC)

Discussing a new approach
This might seem a bit out of place considering we have (recently) been quite lucky to be free of the most of the repeat sockpuppeters. I hope that this lasts, but my fear is that it is a momentary lull. And, if we assume that the good times will not last, then we assume that there will come a point when the "usual suspects" will return to their ways. I would like for us to agree on a different approach to handing these issues moving forward. Simply put, I think our attitude at present towards sockpuppets and puppet-masters does more harm to the wiki than it mitigates.

We've been dealing with a relatively constant onslaught of sock puppets, and that has put us in a warzone mentality. We often block users based solely on their username, without any benefit of the doubt or assumption of good faith, without an honest attempt to perform a CheckUser, and often before the user has even made their first edit to the wiki. I have argued in private with others that this it is a mistake to react in this way, as it gives the puppeteers exactly what they are looking for. Consider: do you think that a puppet master would create an account that is an obvious sock, unless they intended to be blocked? The natural response to this question would be, "well, if they're knowingly breaking the rules (which they are), then isn't blocking them exactly what we should be doing?" I think that the answer is "no."

How would not blocking them solve our problem? Well, for starters, I'm not arguing against all blocks, I'm simply arguing against blocks issued only because of multiple account ownership. What would this do? Consider an example:

Let's say that an account named "ILoveTheSims20" is created on The Sims Wiki. Currently, this name rings enough bells to bring about a permanent block, even if ILTS20 doesn't actually make an edit on the wiki. Under this new "doctrine," judgment would be reserved until that user starts to edit. If they make positive edits, then under this idea, they would not be blocked. This is a good thing, since TSW has gained an editor that makes positive contributions. Alternatively, ILTS20 could choose to attack a user or vandalize the wiki, in which case a block dependent on their actions would be justified. Currently, even if we give the benefit of the doubt to a suspected sock in the first place, they're essentially on two-strikes already because we know or strongly suspect a sock; once they do anything to "reveal" themselves, the punishment is swift and permanent. I would argue that we should treat them just as we would any other first-time violator.

So to boil this down, a sock is born and can either 1) become a good member, and stay or, 2) be a bad member, at which point our normal warn/block cycle can take over. I should add that this whole concept hinges on one other idea.

Indefinite blocks should be incredibly rare, and should almost never be without the choice of appeal. I would argue that we should reform our appeals system to prevent abuse, by mandating that a user cannot appeal for a certain length of time after the beginning of a block. This is because an appeal is not usually used to allege a lack of wrongdoing, it's used to request clemency. We could write in something to the effect that users alleging that a block is unjustified may appeal at once (and provide sufficient proof to that point), but users who simply want to ask for a second chance must wait for an assigned period of time before doing so.

By no means do I think what I'm proposing will fix things. But right now I feel as though we need to do something. The warzone mentality I've mentioned before is damaging to the wiki as a whole. We are so apprehensive of new users, and we've grown to doubt even our more established users for fear that they could be colluding with trolls and sock puppeters. We've taken to creating secret wikis, making lists and tracking data, and "sock hunting" against these users. We're allowing these few users to dictate how we administrate the wiki. We're allowing them to orchestrate a game, with us and them as opposing players. Unfortunately I don't think this is a game we can win; they have unlimited extra lives, cheats, and an unending boredom, and they will play the game as long as we continue to play with them. By enacting some reforms and making some changes, I think we can end the game. -  LostInRiverview talk • blog  •  contribs 02:17, August 5, 2015 (UTC)


 * That has been my own personal policy when dealing with "possible" sockpuppets. Unless I had proof that the user was truly a sockpuppet, I wouldn't issue a block. However, it seemed that vandalism would usually occur before such proof surfaced and would result in a block for vandalism instead. This is probably why I don't issue many blocks. Needless to say, I do agree that this war zone mentality needs to end. I admit that it is because I started getting that mindset that I was hesitant when a brand new user asked me to adopt them. While it is true that I did eventually accept that request, it wouldn't have taken a couple of days to verify that the user was indeed genuine had it not been for that way of thinking. How many new users have been pushed away because we assumed they were wolves in sheep's clothing? -- Icemandeaf (talk) 07:01, August 5, 2015 (UTC)


 * I wholeheartedly agree with this proposal. At the moment, our judgmental policy on socks makes us seem like some police state à la Stalin-era USSR. That is most certainly not who we are. We are simply a community of Sims fans ranging from fanatics to casual gamers who come together to compile information and stories surrounding our favourite games. If we want our impression to be just that, we must be more careful when dealing with violations of our by-laws or sockpuppets. As said before, this wiki is not a war zone. This is not a "war on terror". We are not the Bush government. I think I'm going around in circles now, so I'm just going to stop here. — The  Tim   Man  (IH • GC • TSW • AH • Contribs ) 09:02, August 5, 2015 (UTC)
 * I do think we have been a bit harsh in our approach, blocking users who have yet to make an edit just based on an assumption appears unwelcoming as well as having the risk of catching someone who wasn't involved in an accidental block. I would prefer CheckUser results instead of the way things are being done at the moment. As for not blocking potential socks who are making constructive edits, I am opposed to this. I feel that it makes a mockery of our ban system, and I could probably go even further in that if we didn't block socks, people could just make a complete mess on one account, make a new one, and start over, which completely removes the point of blocks and I can't see it doing anything but spiraling into chaos and removing user accountability. This goes back to what I said above, though - these socks shouldn't be blocked instantly, and only if we've got enough evidence for a CheckUser which turns up positive. If a banned user makes a sock and doesn't ever get caught, that's something that is beyond our control and I suppose that raises more questions, especially if they become a respected contributor/admin and are found out then. Regardless, yeah, something about the current situation does need to change.
 * I'd like to make some comments. First of all, the supposed "blocks without any edits" isn't based solely on username alone. These users showed up on chat first, where they were identified as sockpuppets, usually by disrupting the chat room. Since chat isn't logged, and must be logged manually, I can see why it appears like random users are being blocked for no apparent reason or without solid evidence. Secondly, Wikia seems to be pretty variable on CheckUsers, largely depending on whoever decided to respond to the request. Some many do it without question, others may say that our rationale for requesting a CU isn't sufficient. Also note that CheckUser does not see everything, and someone who uses a proxy server can easily evade any CU. I know some sockpuppets that have escaped detection via a CheckUser, which is why I'm unwilling to say that a CheckUser is required before a block is issued. --I am  k6ka  Talk to me!   See what I have done  21:53, August 7, 2015 (UTC)


 * I am of the understanding that these username-based potential sockpuppets have indeed turned out to be sockpuppets: I've caught several myself, and one of them were unblocked but eventually re-permabanned. These kind of situation also invalidates the whole "indefinite blocks should be rare" concept, since all those sockpuppets are one person anyways and these indefinite blocks are technically aimed at the few individuals. Should a user named say Corymach28 pop out, this may provoke suspicion, yes. But unless the user is blatantly vandalizing s**t in the Quacks like a Duck manner I'm sure none of us are going to drop a banhammer on that user, much less a permaban. MILK FOR THE UNYUUFEX, FLAT CHEST FOR THE CUTENESS THRONE, SKULLS FOR THE SKULL PROBES  (user talk:Mathetesalexandrou) 00:29, August 8, 2015 (UTC)
 * The whole reason I brought this up is because I feel we need to re-evaluate the stance we've held up to now - the stance that says that sock puppetry is a sin punishable by total banishment here and forevermore. The argument I'm making is that if we wouldn't jump to issuing permanent blocks, especially in the case of sock puppets, then we wouldn't have so many disgruntled sock puppeteers trying to get onto the wiki. In other words, we created this monster. I understand the perspective that turning a blind eye to new socks seems like we're acquiescing to them, but I don't see the harm in doing this. If it gives the impression that we're "surrendering" or allowing them to break the rule, why does it matter so long as they continue to abide by our other policies? Why should we be so headstrong in enforcing the sockpuppet policy, even when it means causing damage to the wiki due to the resultant backlash from that enforcement and the issues caused by community distrust? I am not advocating for an open door to all sock puppeteers past and present, especially those who have been the most disruptive and deliberate in their attempts to break our rules, not just the sockpuppet policy itself. But when a user who is blocked on the wiki turns around and creates a sock puppet, we ought to be more forgiving of this. I don't mean we should let it happen, but I do not think that it warrants the reaction that we've given it up to now. That reaction creates an adversarial attitude and makes them more likely to continue misbehaving. Whereas, if we take a different approach with these users, there's a better chance that they will choose to observe the block we issue and accept our rules when they are allowed to return. But this cannot happen if we insist on being "tough on crime" to the extent where we won't look at each case on an individual basis, and this definitely cannot happen if we rely so heavily on indefinite and permanent blocks. -  LostInRiverview talk • blog  •  contribs 00:55, August 8, 2015 (UTC)
 * That is a good point: I was for giving ILS5 a chance before we came to a conclusion of "screw it permaban" after another sockpuppetry issue. And yes, I still am of the give people all the chance before landing the banhammer stance. However, I'm not seeing any community distrust from our current approach. So while the unblock and rehabilitation part of the policy could definitely see more usage, but I don't think our current approach is unfair. Nonetheless, I'd like to know if some of our permabans on sockpuppets were in fact only due to them being sockpuppets identified by otherwise acceptable behavior that the original has been doing. I am under the understanding that ILS5's socks were largely blocked for trying to create fanon, and turned out mostly legitimate (asides from the underage issue) until the IP vandalism to the Sims3 template. I'd like to know of similar cases occurred. MILK FOR THE UNYUUFEX, FLAT CHEST FOR THE CUTENESS THRONE, SKULLS FOR THE SKULL PROBES  (user talk:Mathetesalexandrou) 13:59, August 8, 2015 (UTC)

Custom Javascript disabled
For those not already aware, due to a security issue, Wikia has disabled all custom javascript on all Wikia wikis, including The Sims Wiki. Fortunately our wiki does not make especially extensive use of JS, but there are a couple features on TSW that use it. The only issue I've encountered so far is the TSW twitter widget, which is JS-based and no longer functions; I've hidden it from the main page sidebar until JS is re-enabled. Does anyone know of other material on TSW that is JS-based? -  LostInRiverview talk • blog  •  contribs 18:25, August 10, 2015 (UTC)
 * It now appears as though site-wide css was disabled as well. That is much more significant, especially stylistically. Also, add Countdown to the list of things that no longer work with javascript disabled. -  LostInRiverview talk • blog  •  contribs 18:39, August 10, 2015 (UTC)
 * Webchat widget on TSW:IRC no longer works (although more intelligent users can still use http://webchat.freenode.net/ to connect, or use their own IRC client). All user-enabled gadgets and personal JS/CSS still seems to be working. --I am  k6ka  Talk to me!   See what I have done  23:07, August 10, 2015 (UTC)
 * CSS was disabled for a period of time (less than 30 minutes) as well, soon after js was disabled. According to Rappy on the ##Wikia IRC channel, CSS being disabled was an accident and was not intentional. Add to the list of things that are missing: auto-refresh on various pages, including the Recent Changes list. --  LostInRiverview talk • blog  •  contribs 00:01, August 11, 2015 (UTC)
 * Alright, I just checked Community Central. Staff have issued an update, stating that javascript will be re-enabled but it (and all other MediaWiki pages except css pages) will be in read-only mode and will not be able to be edited. This is intended to be a stopgap measure. -  LostInRiverview talk • blog  •  contribs 00:05, August 11, 2015 (UTC)

It's been a while so I'll blow the dust off. I've mentioned in the latest weekly news blog:

Additionally, community (site-wide) Javascript will soon change drastically. Wikia is planning to implement a review process for site-wide Javascript. Any new changes made to the community JS files must be approved by a team of Wikia-selected users. Additionally, it will no longer be possible to import Javascript code from the user namespace; some of our scripts does this. We are aware of these changes and appropriate updates to the JS files will be made to ensure our customized scripts will continue to function.

AFAIK only one tool is imported from the User namespace — the license adder tool. We'll need to move that into the MediaWiki namespace and then make the necessary modifications in order to continue to use the tool. It also means we'll have to deal with a loss of freedom with our JS. --I am  k6ka  Talk to me!   See what I have done  01:46, September 15, 2015 (UTC)

Sims2Player and DarkSuicune2000
For a while now, and  have been WikiHounding each other, showing clear incivility and poor response to criticism from each other. Things such as , an edit war at , , , and most recently,. I reckon it has something to do with Sims2Player not responding well to criticism per their FE nomination here (and I am perfectly aware of this trait), but this hounding and stalking needs to stop. These two users have a history of not getting along with each other, and while I'm inclined to TSW:AGF and say they're only trying to improve the wiki, in practice they clash together and it takes the joy out of editing The Sims Wiki, especially when someone's criticism, including constructive, are taken as a personal attack by another and a negative response results.

Here are the key points I would like to make here:


 * Blocks are to be preventative, not punitive. Blocks should only be issued on the mindset that they will prevent and deter unacceptable behavior. Blocks should never be used as retaliation, to take sides, or to formally punish users.
 * All editors must engage each other with civility and refrain from personal attacks. Editors are expected to assume good faith, drop old debates, and apologize if they make a mistake.
 * Criticism is not an attack. Quote from Wikipedia:Civility#Incivility: [T]o treat constructive criticism as an attack [is in itself] potentially disruptive . Criticism should not be viewed as an attack, rather as an opportunity to improve. Users who disagree with the criticism should respond to it in a civil manner, and make no mention or hint towards it being an attack. However, criticism can be an attack if it is used or worded improperly. "Your cookies are so bad, you must be a failure at life too" is an example of when criticism is an attack. "Your cookies are a bit bland to the taste. I suggest adding some semi-sweet chocolate chips into the dough to make it tastier" is an example of when criticism is not an attack. Criticism should be focused on the content, not the person who wrote the content.
 * It is OK to disagree, but it is not OK to assume bad faith. As mentioned above, constructive criticism is key to the growing up and development process of all aspects of life. It is OK to disagree with criticism, but it is not OK to think criticism is issued as an attack.
 * Administrative actions should, again, be preventative, not punitive. Per, I would like to clarify that any administrative action should only be done to prevent further misconduct, and not simply punish the user. If a child was misbehaving and ate too much junk food, it is not appropriate (or even sensible) to ban them from watching TV, as it does not address the issue at all. On the other hand, if an administrator was abusing rollback, removing their administrative status is a sensible and appropriate action, as rollback is tied to the administrative tools. It is not sensible to ban the administrator from making fanon or chatting with other users as it does not correlate with the issue at hand.

Having said all of this, I propose the following actions be taken:


 * DarkSuicune2000 and Sims2Player should refrain from commenting on each other's fanons, and they should not respond to each other's comments on any other fanon. Since this is where most of the disputes are stemming from, I suggest that they should cut it out entirely. This could be listed at TSW:ER, and I believe this restriction need not last any longer than one month.
 * This restriction also extends to commenting on fanon elsewhere, such as on chat or via a talk page.
 * The two users may continue to communicate with each other, providing that it is civil and well-mannered, on other topics.
 * Sims2Player should be reminded that, although criticism may sometimes feel like a slap in the face, it is not intended to disparage or to anger. They should be reminded about the true meaning of "nothing is perfect," in that things will always garner some form of criticism one way or another. Sims2Player should realize that 1) Criticism is a part of the learning process and that he/she should learn to accept it, 2) It is impossible to please everybody, and 3) Responding to criticism and treating it as an attack is an assumption of bad faith.
 * DarkSuicune2000 should be reminded that criticism is helpful, but it should be worded in an appropriate and civil manner. Things like "You have a good plot, but you write like a bloody twelve-year old" is not okay, but "I think your plot is solid, but there are a number of sentences that could be rewritten in prose; for instance, there are a number of sentence fragments..." is an example of good criticism.

To be clear, I am not proposing:


 * Blocking. Both of these users are not focusing all their energy and attention towards these comments, and are making constructive contributions elsewhere on the wiki. A block should only be used as an absolute last resort when all other methods have failed (And I have confidence in the two parties that a block will never be necessary).
 * User privilege removals. Again, these don't address the issue at hand and will do the opposite of a cool-down. Actions should be preventative, not punitive.

I would like other administrators to comment on this issue and provide feedback or ask questions. Feel free to suggest changes to these proposals.

--I am  k6ka  Talk to me!   See what I have done  18:39, September 27, 2015 (UTC)
 * I strongly support the proposals you've laid out. Although both are quick to deny that a feud exists, I think the evidence here speaks for itself. An issue between two editors is one thing, but it's beginning to spill over and other users are getting involved, further spreading the conflict. It needs to stop now. --  LostInRiverview talk • blog  •  contribs 15:17, September 28, 2015 (UTC)
 * Strong support - This has gone on for quite a while now, and to be quite honest, it's disrupting the peace, especially when their arguments happen on other user's fanons. This has to be handled quickly and quietly as we don't want others getting involved. However, if both users continue to argue back and forth, then I think we should take more of a firmer action upon them both. It just has to stop. ~ Beds  (talk - blog ) 17:50, September 28, 2015 (UTC)
 * Strong support for all of the reason previously stated. It is just about to the point where it is getting out of control. -- Icemandeaf (talk) 18:13, September 28, 2015 (UTC)
 * Strong support - Your proposal is level-headed and sensible to this matter. I believe it would be the best solution to handle it.  Nikel  Talk  –  Vote!  14:12, September 29, 2015 (UTC)

✅ Editing Restrictions have been applied to both users, set to last for a month. At that time, we can re-evaluate their behavior and take additional actions or place the users on ER probation. --  LostInRiverview talk • blog  •  contribs 02:34, September 30, 2015 (UTC)

Editing restriction breach
Recently the editing restrictions set above have been breached. DarkSuicune2000 left comments on three fanons by Sims2Player: Fanon:Flower City, Fanon:Michelle Styles, and Fanon:Sef Nkobe. While the comments are deemed constructive and civil, they are still a breach of editing restriction, which expires on 3:00 October 30, 2015. It is currently 18:56, October 10, 2015 (UTC).

Both users have been notified. Further sanctions may be discussed if the restrictions are breached again. --I am  k6ka  Talk to me!   See what I have done  18:56, October 10, 2015 (UTC)

For administrative and logging purposes, the deleted comments are listed here:

--I am  k6ka  Talk to me!   See what I have done  18:59, October 10, 2015 (UTC)
 * Fanon talk:Michelle Styles/@comment-DarkSuicune2000-20151010184207/@comment-Sims2Player-20151010184325
 * Fanon talk:Michelle Styles/@comment-DarkSuicune2000-20151010184207
 * Fanon talk:Sef Nkobe/@comment-DarkSuicune2000-20151010184351/@comment-Sims2Player-20151010184558
 * Fanon talk:Sef Nkobe/@comment-DarkSuicune2000-20151010184351
 * Fanon talk:Flower City/@comment-DarkSuicune2000-20151010184550

Editing restriction re-evaluation
The expiry time for the restrictions (03:00 30 October 2015) has come and gone. At this time, I'd like to invite other administrators that do not have a conflict of interest to evaluate this situation, and determine whether or not the restrictions need to be in place any longer. Also, if there were any breaches in the restrictions that were not spotted and not logged on this page, please bring it up. --I am  k6ka  Talk to me!   See what I have done  12:51, October 31, 2015 (UTC)
 * I don't know of any breaches aside from the incident already noted above. I think at this point it would be best to place these users on probation. The restrictions placed on them should be lifted, but if they revert to their previous behavior, the ERs will be immediately re-implemented and they will be given warnings. Though, I should stress that in the case where one of the two parties violates the terms, only the person who has actually violated it should be warned. During the ER period, one of the two users breached the restriction, but both users received the same warning for that action, which is unfair to the second user who did not breach the restriction. It is important to remind both users that engaging in the kind of behavior they were engaging in is harmful, distracting and not permitted, whether or not they have been warned against doing so or have been restricted from doing so. --  LiR talk • blog  •  contribs 15:36, October 31, 2015 (UTC)
 * Placing them on probation seems to be a fairly reasonable suggestion. I'm not saying that the behaviour of either of these users has been 100% since the restrictions were placed. However I've noticed that since the beginning of the editing restriction period, both parties have improved significantly. I agree that the restrictions should be lifted, and should either of them revert to their previous behaviour, the editing restriction should be immediately re-implemented on whichever party violated the terms. Indeed it seems unfair for both parties to receive a warning, if only one of them actually violated the terms. I know that in the past away from the keyboard, I have been warned for doing what the opposing player committed, and it is not a pleasant experience. ―  C.Syde  ( talk &#124;  contribs ) 08:49, November 1, 2015 (UTC)
 * To clarify, both users were warned because one of them had responded to a comment made by the other user, which was highlighted in the ER. So technically, both users were at fault, one for posting a comment on the other user's fanon, and the other for responding to said comment. --I am  k6ka  Talk to me!   See what I have done  18:12, November 8, 2015 (UTC)
 * If one has received a warning for violating the restriction, then the one who violated should remain on the restriction while the other can be put on probation, granted that they haven't broken any restrictions. It's only fair. ~ Beds  (talk - blog ) 23:56, November 8, 2015 (UTC)
 * The restriction was violated once, but it appears to have been accidental, and no further breaches of the restriction, as far as I'm aware of, were made. Thus, I don't think an extended restriction is necessary, and both users can go on probation. If they do breach the restriction again, they can always be re-added as needed. --I am  k6ka  Talk to me!   See what I have done  00:02, November 9, 2015 (UTC)

Deletion of Category:Created by TheSimSupply
I find the deletion of Category:Created by TheSimSupply to be a bit bitey. For one thing, the author wasn't even notified about the deletion nomination, and it was nominated for deletion through the regular process, not a speedy deletion. Beds later deleted the category immediately, labelling it "Nonsense", which is intended for pages that are "patent nonsense", something this page was definitely not. Finally, the author seemed to have created the category with the intention of categorizing their own fanon with it. The reverts done by Sims2Player and C.Syde65 seem to give the impression that we forbid fanon categories, which is not true considering that fanon templates are given category names that the author gets to pick and choose. (Say, for example, Category:Revolution templates.)

I would suggest that the community reconsiders its decision to have this de facto ban on fanon categories lifted. See Forum:Permitting user-created fanon categories. --I am  k6ka  Talk to me!   See what I have done  11:34, October 13, 2015 (UTC)
 * I posted a response to the sister thread on the CDF, but I'll reply here as well for the sake of administrative housekeeping regarding this category. I would be in support of undeleting this category, assuming that Beds doesn't choose to undelete it by herself. However, since I do not want to override the decision of another administrator, I shall wait for consensus here rather than undeleting it myself. --  LostInRiverview (Plumbob.png Administrator)  • Contact me here • 14:35, October 13, 2015 (UTC)
 * I can easily delete the category, and I also plan to personally apologise to the user for causing all of this confusion that I caused them. I'll wait until k6 and other administrators are aware of the mistake before I take action. ~ Beds  (talk - blog ) 15:32, October 13, 2015 (UTC)
 * Since the category has been restored, I was wondering if it were wise to undo those edits  made by Sims2Player and myself, that removed the said category from the user's fanons? I too do not wish to override any decisions made by others, which is why I've decided to ask here. Normally I'd consult this community guideline, but this is a difficult interpretation. ―  C.Syde  ( talk  &#124;  contribs ) 09:56, October 24, 2015 (UTC)

Spamming comments on user's own fanon
Recently I've noticed a user has been repeatedly leaving numerous spammy comments on their own fanon articles. In one case, this user left fourteen separate comments (although one of the comments was in reply to comments left by other users). Having so many comments pop up can tend to flood Recent Changes and Wiki Activity, and might be seen as an attempt to advertise for their fanon pages (by making sure their pages consistently appear on RC/WA). Is there anything we'd like to do about this? -  LiR talk •  blog  •  contribs 05:04, November 24, 2015 (UTC)
 * They've also recently flooded the chat room while I was away from keyboard, and when I returned, I found that they'd spammed the chat with this. This is the very first time I've ever seen them in chat. When I discovered all the comments they'd spammed into the chat, I left them a warning (not a formal one) via private chat not to spam the chat room. And then they apologised, and said it was time for them to sleep, and they left.


 * Normally I interpret this user to be a fairly mature and respectable one, but I wouldn't say the same for what I've just seen of them in chat and what you've mentioned above. I personally think a friendly hand written message asking them not to leave spammy comments on their own fanon articles to draw attention to their work would suffice. And then if they continue in this pattern, I'd suggest giving them a handwritten warning. I don't think what they've done recently should be treated with a standardised warning message. Not in the mean time at least. ―  C.Syde  ( talk &#124;  contribs ) 05:48, November 24, 2015 (UTC)


 * Do not forget Hanlon's razor. Chances are, they simply lacked the maturity or didn't think it through properly without actually intending harm. I would suggest monitoring them for a few more days or weeks, and if they persist, then warn them with a hand-written warning. — k6ka  🍁 ( Talk ·  Contributions ) 11:45, November 24, 2015 (UTC)

Deletion of Sapphire Moondust's fanon
Today an unregistered user, claiming to be User:Sapphire Moondust, nominated several of Sapphire Moondust's fanon pages for deletion. K6ka responded to the requests by taking down the deletion templates, stating that the unregistered user would need to contact the administrators and prove in some way that they are indeed Sapphire Moondust. The unregistered user contacted K6ka and requested that the content be deleted, and K6ka repeated that the user would need to prove their identity first. The user then responded negatively, and deleted the content from Sapphire Moondust's fanon pages. C.Syde65 has restored the content again.

I think the deletion of the fanon should be discussed here. I personally am in favor of deletion, but not because of the unregistered user's request. In this case, Sapphire Moondust is globally disabled. We in the past have not, to my knowledge, made a distinction between users that are globally disabled, globally blocked, or locally blocked. Since that is the case, I think we need to treat their fanon as if Sapphire Moondust was indefinitely blocked, and delete it on those grounds. In short, the identity of the unanimous user nominating the articles for deletion, is irrelevant to the question of deletion, in my opinion. --  LiR talk • blog  •  contribs 22:13, January 19, 2016 (UTC)
 * I disagree. The user in question hasn't given any indication as to why they've been globally disabled, and they left the wiki in otherwise good standing. I don't see it as necessary to delete the fanons, considering we have plenty of "vanished" users that still have fanon on the wiki. — k6ka  🍁 ( Talk ·  Contributions ) 22:18, January 19, 2016 (UTC)
 * Considering that Sapphire Moondust has left the wiki without explanation, other than that she left in a manner that suggested that she had no intention in returning, and didn't want other users to talk to her, I suspect that she scheduled her account for closure herself.


 * However I do not think that her fanons should be removed from the wiki, just because her account is globally disabled. I mean people still read her fanons, and we've had several featured fanons by users with globally disabled accounts. Also she never personally asked for her fanons to be removed before leaving this wiki. For those, and other reasons, I see no reason to support the deletion of her fanons. ―  C.Syde  ( talk &#124;  contribs ) 22:30, January 19, 2016 (UTC)


 * I don't think the reason behind the departure is really relevant. The fact is that the user is no longer here and, unless they can get their account re-activated, won't be coming back. Consider as well that Sapphire Moondust is the "owner" of that content, under our policies. Since Sapphire Moondust no longer has access to the Wiki (either through their own action or because of Wikia), they cannot control how that content is used. In a usual case, if an author requests deletion, we will usually oblige them, but since Sapphire Moondust is not able to log in, they cannot make that request and, indeed, don't have any control over their own content at all. That's the reason I'd support deletion... not because of the request itself, but because it removes the issue of the owner not having control, by eliminating the content entirely. --  LiR talk • blog  •  contribs 22:31, January 19, 2016 (UTC)
 * I'd say "archive" is the key word here. The fanon doesn't have to be edited or expanded for people to read and enjoy them. There is no harm in keeping them and it can be retained to serve as inspiration for future authors. If the wiki lost all its administrators and active users, Wikia staff won't close this wiki solely because of that, instead leaving it open as an archive of, well, our old lives, even if nobody edits or maintains it anymore. — k6ka  🍁 ( Talk ·  Contributions ) 22:59, January 19, 2016 (UTC)
 * I really do not see the point of keeping their fanons on the wiki if they have been globally disabled. What truly is the point? They are never going to be updated, and no one has any rights whatsoever to update them as they don't belong to any of us, the only person they belong to is Sapphire Moondust, who is not around to do anything about it. Simple rule; if the user's not around anymore, then their fanons should be deleted. ~ Beds  (talk - blog ) 23:16, January 19, 2016 (UTC)
 * If Sapphire Moondust's fanons should be deleted, should the fanon pages belonging to other fanon authors with globally disabled accounts be deleted as well? Like AsherÉire's for example? ―  C.Syde  ( talk &#124;  contribs ) 23:18, January 19, 2016 (UTC)
 * There's a difference between archival of wiki content and archival of fanon. Wiki contributions are, by definition and by license, community-owned content. An edit I make to an article on the wiki belongs to the wiki; in fact, in editing, I agree to license that content to stand there (either in the article or in the page history) long after I am gone. That's something that is fundamental to building the wiki, or else anyone would feel free to pull any information they contributed when they leave. Fanon, on the other hand, has not been treated as community-owned content. We refer to fanon articles as "property," we have rules against other users editing a user's fanon content, and we allow users to request that their fanon is deleted. To my knowledge, we have never denied a user's request to delete their own fanon, because doing so would in essence force that user to keep content that they own on this wiki in perpetuity. If we are going to treat fanon as property, then this goes against the rights of the owner to manage their property according to their wishes.
 * I have no issue with keeping fanon content when a user leaves, provided that user still has access to their account and to the wiki; in other words, if the user still can exercise control over their content, regardless of whether or not they choose to do so, then I have no issues with keeping the content as an "archive." In this case, however, the user no longer has access, and has no control over what happens to the content that they own. It is unfair to deny them the ability to remove their own content if they so choose, because we allow other users to do so upon request. Therefore it seems to me that we should delete fanon content owned by users who are globally blocked and/or disabled as a matter of course, to prevent these people from having their works hosted outside of their control.
 * The decision of deleting or not deleting goes beyond this specific case. If we choose to keep that material, we are essentially saying that fanon authors don't have control over their content, but the content instead belongs to the community. Now I'm not arguing the point of whether fanon authors or the community should own the content, I'm merely saying that up until now, we've operated under the principle that fanon authors are the owners of their own works. Keeping this content now would go against that principle, and re-define the relationship between fanon authors, their works, and the wiki. --  LiR talk • blog  •  contribs 23:25, January 19, 2016 (UTC)

Use of Facebook and Twitter profiles
I've mentioned in the past that any administrator will be given rights to post on The Sims Wiki's Facebook and Twitter pages if they want them, as a part of their promotion. Since these pages are administered separately from the wiki, it falls on active administrators to continue to pass along moderation rights to new admins as they are promoted. At this time, however, very few of the wiki's active administrators have these posting/moderating rights, and even fewer actually use them. Because the few admins who do have these rights are also inactive generally, it's even more important to make sure that we have active administrators taking over the posting on these pages. The pages have been incredibly silent over the past few months, partly because the people who are supposed to be updating them (like myself) have not been.

Where I'm going with all of this is, if you are an administrator and you have a Facebook account, please contact me on my talk page so I can get you set up as a moderator on The Sims Wiki's Facebook page. Additionally, even if you do not have a Twitter account, let me know via my talk page if you would be interested in receiving access to TSW's Twitter account (you don't have to have a first Twitter account to gain access to another account). Even if you've decided against taking these rights on in the past, please reconsider it. Finally, if you know of any non-administrators who are active on the wiki and are trustworthy, consider recommending them for social media rep positions.

The social networking pages are useful tools for driving readers to certain pages, or to the wiki in general, and are good for interacting with the greater Simming community. It makes very little sense to keep the pages idle for long periods of time. Ideally we should have several people using Facebook and Twitter, keeping posts up-to-date and interacting with users.

--  LiR talk • blog  •  contribs 05:20, April 10, 2016 (UTC)

User:JordanBell445
It seems like the situation with User:JordanBell445 is at risk of getting out-of-hand. The user has been blocked for repeated creation of fanon articles in the canon namespace, and the block has been escalated due to sock puppetry. I really want to avoid a situation where we end up indefinitely blocking another user. This is especially true in this case, since JordanBell has not been acting in bad faith.

I feel that we should continue to block any sock puppet accounts that pop up and keep the current block in-place with the option to appeal the block through the normal procedure, since the block is longer than a week. I think we should agree on a course of action if new sock puppets pop up, rather than reacting by escalating blocks further. --  LiR talk • blog  •  contribs 23:44, July 29, 2016 (UTC)


 * I think the main reason JordanBell may have created the J.sharp3 account was because they didn't realise that their original account's block had expired. But the fact is that they should have checked to see that their first account was unblocked before using those sock-puppet accounts. I agree that the situation with JordanBell is at risk of getting out of hand, but then I do feel - and I'm sure I'm not alone when I feel this way - that if blocks don't discourage them from creating sock-puppets, what will?


 * I blocked the J.sharp3 account indefinitely because they were almost certainly a sock-puppet of JordanBell, but then I changed the block settings after thinking it through and deciding that enabling the auto-block, and disabling talk page access came across as too harsh. Especially given that I hadn't requested a check user to see if these accounts really were operated by the same person. A little while later, when I was on the community central chat, Upstagekinkjou came and asked me why I blocked their IP.


 * I asked them if they were the same user that made the JordanBell and J.sharp3 accounts, because they claimed to be Jacob Sharp who JordanBell is also known as, as evidenced by their masthead, and they admitted that they were the same user. I then asked them if they would log into their JordanBell account, so that I could verify that they were the same user, and they did just that. Again, I feel that the way JordanBell has been treated may come across as being a bit harsh, and that they may truly have lacked sufficient experience to follow our policies through. But then at the same time, it's a difficult interpretation whether they really are incapable of following our policies or if they're just refusing to listen.


 * I was able to get them to confess whether or not they were the same person who created all these accounts, and they admitted that they were. So they don't seem to be remotely unable to follow through with what we ask of them. I think the best option would be to keep their original account blocked for the time being, and indefinitely block any subsequent sock-puppet accounts that they create, but without lengthening the block placed upon their original account any further. ―  C.Syde  ( talk &#124;  contribs ) 00:16, July 30, 2016 (UTC)


 * I think it'd be useful to explain to JordanBell what the policy is on multiple accounts, how he/she broke it, and why it matters in the first place, while still standing strong in keeping JordanBell's block for fanon creation (which I don't think is at issue here). If the multiple accounts policy is clearly explained and JordanBell continues to choose to violate it, then and only then would it be prudent to extend the block on the main account. Up to now we've been enforcing the multiple account policy but, aside from a brief explanation of the policy violation in the notice that C.Syde gave to JordenBell when the block was extended, there has been no real explanation of the situation. In this user's case, I think it's important that we assume good faith, but at the same time assume ignorance towards our rules. If we assume that, then it means we need to be clear about what our rules are and how they're enforced. Ultimately I feel this is the best way to prevent the situation from escalating, or at least making sure that if the situation does escalate, it will be by JordanBell's own explicit actions in violation of a policy that we have made understandable enough for him/her. --  LiR talk • blog  •  contribs 00:52, July 30, 2016 (UTC)


 * It should be noted that the user was given several notices on their talk page about their creation of fanon in the canon namespace, and the user has apparently ignored every single one of them, hence why I took to blocking. — k6ka  <span title="Canadian!" style="color:red">🍁 ( Talk ·  Contributions ) 20:29, August 1, 2016 (UTC)


 * I probably would have taken to blocking myself, but then I've never actually blocked a user for repeatedly creating fanon inside the canon namespace before, and before they were actually blocked for doing so, I was unsure whether blocking them for repeatedly adding fanon to the canon namespace would be something that others would consider fair. ―  C.Syde  ( talk &#124;  contribs ) 06:02, August 2, 2016 (UTC)


 * Blocks are meant to prevent further disruption, not to punish users. The user was being disruptive (intentionally or unintentionally) by creating fanon in the wrong namespace.


 * And as for block evasion, they've created yet another sockpuppet account, and so far all attempts to contact the user have failed. — k6ka  <span title="Canadian!" style="color:red">🍁 ( Talk ·  Contributions ) 13:15, August 4, 2016 (UTC)


 * Yeah, I personally don't see blocks as a punishment, but to prevent further disruption, and as a consequence for the said user's actions. When this said user created their latest sock-puppet account, the first thing they did was enter chat, and tried to contact me via PM, but they only got as far as saying "Hey" before I banned them.


 * I understood that they probably only wanted to discuss their block with me, but I felt that their block evading was more important than their wanting to contact me. Their original account still have access to their talk page, but they haven't shown any signs that they are aware of this. ―  C.Syde  ( talk &#124;  contribs ) 01:32, August 5, 2016 (UTC)

Lucky98 block
I feel that the indefinite block against is too strict. The user's first block was for 31 hours, and the second block escalated all the way to an indefinite block. I feel that an indefinite block in this case is not justified, and a much shorter duration (like a 1-week block) is more in order for this situation. --  LiR talk · blog  ·  contribs 13:52, August 26, 2016 (UTC)


 * They've been here for over a month, and it is also worth noting that they have also been posting their content on other wikis, including some that I am admin on and several that they have founded. They have also vandalized a number of our pages, such as and . I do not expect to see any further constructive edits from this account, especially considering that they already have their own wikis where their content is more suitable being uploaded there, which is why I indeffed them with a preventative measure in mind. — k6ka  <span title="Canadian!" style="color:red">🍁 ( Talk  ·  Contributions ) 14:53, August 26, 2016 (UTC)
 * This user's brand of vandalism is relatively low-key and low-impact. Even if they do vandalize, they cause very little harm and are almost immediately rolled back. I think issuing a block as a preventative measure eliminates the opportunity for substantive change from this individual. And it shouldn't fall to us to block a user based on conduct on other wikis unless that conduct directly affects this wiki. --  LiR talk · blog  ·  contribs 15:17, August 26, 2016 (UTC)
 * You can reduce the length of the block accordingly, although I still stand by what I say. This comes from my experience working on the English Wikipedia where even low-key vandals, if they persist, are eligible to be blocked indefinitely if they don't have any constructive edits. — k6ka  <span title="Canadian!" style="color:red">🍁 ( Talk ·  Contributions ) 15:35, August 26, 2016 (UTC)
 * It seems that the practice to which you refer applies to people who only vandalize, without making or attempting to make any other contributions of positive merit. This in essence implies that the user is not acting in good faith and therefore should be indefinitely blocked since they show absolutely no intent to act in good faith. Lucky98 has apparently acted in bad faith in certain cases, but they have also made other edits that could be interpreted as detrimental yet still assumed to be in good faith. Any such edit would not fall under the definition of vandalism, and hence the account wouldn't be subject to being treated as a "Vandalism-only account".


 * I don't personally have high hopes for this user (though I'd be open to being proven wrong), but I still feel that we ought to assume good faith wherever we can and not be punitive with our blocks. If this user returns to bad faith editing after the end of a temporary block, we should consider further escalation. --  LiR talk · blog  ·  contribs 16:21, August 26, 2016 (UTC)


 * I must admit that I was a little surprised when I discovered that they'd been blocked indefinitely, even if they had vandalised other wikis, since they'd only been blocked one other time, in which the first block they received lasted less than 2 days. I don't have very high hopes for this user either, since they have made some low-key vandalism, as well as creating nonsense fanon articles. Fanon articles that I would have perceived as spam, had I not assumed good faith, and tagged their fanon pages as stubs, whilst giving them time to add proper content in their fanon pages in the near future.


 * Not all their edits seem to have been remotely done in bad faith, although they don't seem to have made any edits that I wouldn't perceive as questionable. At the present time, I feel that an indefinite block in this case was too harsh, but I am open to being convinced that an indefinite block in this situation was truly justifiable. I think they should be given a clear handwritten explanation as to what they are doing wrong and how to fix it. And if they don't improve when their block has expired, I wouldn't be opposed to them receiving an indefinite block then. ―  C.Syde  ( talk &#124;  contribs ) 06:18, August 27, 2016 (UTC)

The time has come to revive this discussion as the user has now been blocked yet again, this time for two weeks, and again for vandalizing pages.

At this point I am tempted to block them indefinitely as a vandalism only account, as such a user on Wikipedia would've been blocked in this fashion by now. So far I do not see any attempts by the user to edit constructively. — k6ka  <span title="Canadian!" style="color:red">🍁 ( Talk ·  Contributions ) 16:48, September 11, 2016 (UTC)


 * As I mentioned before in my previous comment, I would be open to the idea of giving them a clear handwritten explanation as to what they are doing wrong and how to fix it. But somehow, given that they were issued a formal warning recently, and then showed no signs of improvement, hence why they have been blocked yet again, I don't really see how giving them a clear handwritten explanation would help convince them to stop making nonconstructive edits and start editing constructively. Therefore, I do feel that it might be justified to give them an indefinite block after this block has expired, if they haven't shown any signs of improvement when that time comes. ― C.Syde  ( talk  |  contribs ) 21:15, September 11, 2016 (UTC)

Obtaining Vanguard support for portability reforms on the wiki
I would like to contact Vanguard and obtain their help (hopefully hands-on help) in updating our templates, css coding, and other design and layout elements on the wiki, in order to ensure that our wiki is portable to different devices. Right now I feel we are largely failing in this regard, for a multitude of different reasons.

None of us can claim to be experts in css or in the function of our most complex templates (especially infobox templates). As none of us are experts, everything that we've assembled has been borrowed from other sources or added purely through guess-and-check methods This means that our code is probably poorly optimized and inefficient. We're also prevented from making any large-scale changes to these systems because we don't have a full understanding of how they function. The idea is, by building new portable templates and designs from the ground-up, we will have a more streamlined code that is more easily understood by current and future editors/administrators, and able to be adapted and edited more in the future without a fear that we could be breaking functionality.

There hasn't been a huge push on this wiki yet to pursue portability. I think this lack of effort has been to our detriment. By making it harder for people on different devices to read our content, we make TSW less of a destination for the information we provide. Fewer people coming here to seek out information in turn reduces the number of readers who choose to become editors, and thus we also get decreased community interaction and engagement. If we can rebuild the wiki into one that is portable and readable across platforms, we could draw in new readers who could in turn become new editors.

So, I'm proposing that we contact the Vanguard team and see how to move forward with portability. I want to stress that their goal is to design or redesign features on the wiki without impacting function or design for desktop/laptop users. All of us edit TSW from traditional devices and I don't think any of us want to see design or functionality compromised in order to benefit mobile devices. But if there's a way to improve the reading experience for mobile users without a major impact on desktop readers, or if there's even a way to improve experiences across-the-board, then why not do so? Vanguard members are not allowed to implement changes unilaterally, so we don't have to worry about them forcing through unwanted designs without our approval. They can, however, be a source of new ideas and expertise, and allow us to make some changes to our layout and design that have been needed for some time.

If this idea is received well here, I will send in a request for a member of Vanguard to engage the community and get the ball rolling on making substantive changes. --  LiR talk · blog  ·  contribs 18:05, November 27, 2016 (UTC)