The Sims Wiki talk:Community Portal

 Community Portal Talk Page This is the general discussion page for The Sims Wiki! Feel free to discuss anything you want regarding the wiki here or at the forums. Any questions regarding the gameplay features or modding for The Sims series should be taken to our Questions forum. Policy proposals should be made here.



If a link to a particular discussion has brought you to the top of this page, instead of to the actual discussion, then that link may be broken. Please check the link and make sure that the section name is correct, and that the section in question hasn't been archived.
 * Broken Links

 Contents

 Noticeboard

Archives 1 2 3 4 6 7 8 9 10 11 12 13 14 15 16 17
 * Fanon wiki merge (archive 5)
 * Articles about unannounced titles
 * Achievements discussion
 * Fanon Namespace discussion

New user adoption
I've been thinking of bringing back New User Adoption, which would allow an experienced editor (can be anyone really) to "adopt" a new user who requests it and they can rely on that user to help them out. BobNewbie originally came up with the concept but it didn't really go too far. I am planning to adjust some of the "guidelines" for this feature as some of them were just drafts from planning (plus a minimum of 700 edits seems too much for someone to be eligible to adopt someone) but we'll come to that a little bit later. For now, I'm wondering what others think of this. 22:42, February 28, 2012 (UTC)
 * I agree. It might encourage "newbies" to edit more and feel more helped and less "lost" when the wiki is full of more experienced users. I also feel it would be an opportunity for the community to get to know itself more. -- RoseGui [[File:Thanks rose.png]] ( talk here ) 22:46, February 28, 2012 (UTC)
 * I agree as well. I aren't that sure how we'll go around it though, since tbh most people who sign up make a few edits and leave.
 * We can definitely add something to the welcome message regarding it which might build some kind of interest amongst new users. I'll probably start planning the new "guidelines" within the next few days as a draft and see how that goes. 13:05, February 29, 2012 (UTC)
 * A very good idea for the new user to become a great professional editor. It can be possible if they will sign up for this, since most (or maybe some) might edit a few and just leave without coming back or they may decline because they are experienced editors from other wikis and/or Wikias. Just saying.  ThomasWikia Main 09:52, March 5, 2012 (UTC)

Game 'generation' portals
Hey all. I'd like to bring up a topic that has been discussed by several people over a series of years. The topic revolves around the idea that we group games together based on their 'generation', and that we create Generation portals that link to games and specific things in each generation (similar to how we have a separate page for TS1, TS2 and TS3 tutorials). The specification of a certain generation would depend on the release date and game engine in the game, but would generally be:


 * Generation one (2000-2004)
 * Began with: The Sims in February 2000
 * Notable additions: Main series games, The Sims Online, The Sims console versions (Bustin' out, Urbz)
 * Final release: The Urbz: Sims in the City in November 2004


 * Generation two (2004-2008)
 * Began with: The Sims 2 in September 2004
 * Notable additions: Full-3D viewing, customizable neighborhoods, introduction of 'Stuff Packs'
 * Final release: The Sims 2: Mansion and Garden Stuff in November 2008


 * Generation three (2009-present)
 * Began with: The Sims 3 in June 2009
 * Notable additions: Seamless neighborhoods, release on smartphones, frequent patches and introduction of new features.
 * Final release: Present generation

What does everyone think of this? --  LostInRiverview talk · blog 22:34, March 6, 2012 (UTC)

I personally think "do not need:" Unless someone was completely new to the game, they should be able to identify the game generation that is associated with the each article. Mind you, we've also got the icons up there to notify readers about what generation(s) the article is relevant to. MILK FOR THE UNYUUFEX, FLAT CHEST FOR THE CUTENESS THRONE, SKULLS FOR THE SKULL PROBES (user talk:Mathetesalexandrou) 03:28, March 7, 2012 (UTC)
 * Good idea, and I'm glad we are finally getting some discussion on this after its been in limbo for so long. IIRC RR made some drafts of the portals a while ago, I'm not sure where they might be though.
 * I think it would be a good way for newcomers AND experienced players to get to the information they want as fast as possible. 21:43, March 7, 2012 (UTC)

Restricting the Fanon namespace
Hi everyone. I've been noticing a lot of problems with anons creating and editing fanon pages. Whether it be an anon vandalizing another fanon page, or an anon vandalizing an admin's user page after having their fanon deleted, I think something should be done about this. I know that it is possible to lock namespaces from being edited by anons (such as with the MediaWiki namespace). Do you think it should be done here? —Random Ranaun (Talk to me! ) 17:56, March 8, 2012 (UTC)
 * Rather than locking an entire namespace, I think it would be better if we adjusted our fanon policies a little. A proposal was made some time ago and I'd rather go along with what LiR proposed back in August. That way, it may give less of an opportunity for an anon to vandalise an admin's userpage as a response to their fanon being immediately deleted. As for vandalising other fanon articles...I've only seen it happen on a few occasions in the past and I'd go along with how we'd deal with any other form of vandalism. Then again, I was, and still am, absent so I'm not sure how much of it has happened lately.


 * tl;dr? Go along with this rather than locking the fanon namespace. 18:43, March 8, 2012 (UTC)
 * Yeah, what he said :p --  LostInRiverview talk · blog 22:11, March 8, 2012 (UTC)
 * If we could actually manage to get discussion going on a policy for once, the one LiR made god knows when would be good. Otherwise this would be the way to go, since anons aren't allowed to make fanon anyway. Imo if they really want to they can just create an account.
 * Isn't it a little soon for a consensus? I think we should discuss this a bit further. —Random Ranaun (Talk to me! ) 00:25, March 11, 2012 (UTC)
 * Yeah, I would have left it open for a bit more. That said, discussion can happen while consensus is being gathered.

Consensus
We are now seeking consensus based on these two options:


 * Option A - Protect the fanon namespace completely from anonymous editors.
 * Option B - Amend the policy based upon this proposal.
 * Other - Other/none of the above (please state in your response what you would prefer).

The discussion will last for one week. . 23:42, March 10, 2012 (UTC)

Option B - This would be a much more generous solution to actually give anonymous users the chance to write their fanon and keep it rather than locking them out of the namespace completely. 23:42, March 10, 2012 (UTC)

Option A - If they want to make fanon so much, they can just make a account. As it is, 95% of fanon now is made by registered users, so it wouldn't change much, and might even get more users registering this way.

Option B - We are having a surge in Fanon creation, and accepting anons (and gradually inducing them into making accounts) will be much welcome. Hopefully they'd participate in voting for featured fanons... Getting more active members are an start. (And LiR's got a point there, as do GG: it's simply unfair to willing anons, and making a Fanon page means that they might have some experience. However, it should be emphasized that anons should be directed towards making an account.) MILK FOR THE UNYUUFEX, FLAT CHEST FOR THE CUTENESS THRONE, SKULLS FOR THE SKULL PROBES  (user talk:Mathetesalexandrou) 02:40, March 11, 2012 (UTC)

Option A - Registering is free, so there is no reason for not register to create fanon. If we protect the fanon namespace, that will be easier for us to manage the fanon and prevent this unnecessary situation: no more deleting fanon by anon, no more angry anon because their fanon deleted on someone talk page (like what happened to mine...), or angry anon because their fanon deleted on someone registered user fanon (like what happen yesterday and andronikos take care of it... lol), and the important one is will be prevent blocking anon that angry because their fanon deleted then vandalizing someone page. Wiryawan310 03:49, March 11, 2012 (UTC)

Option A - Per Wogan and Wir. If they really want to make fanon, all they have to do is register. It'll make our jobs much easier. —Random Ranaun (Talk to me! ) 04:10, March 12, 2012 (UTC)

Option B -I don't think it's fair to delete a person's fanon simply because they didn't register in advance, since they may not be aware of the policy we have in place. I think giving the anons notice once they've created fanon that they need to register is much better than just deleting it entirely. And I think locking the fanon namespace altogether to anons is fraught with problems, one of which being that it might actually violate Wikia's rules. Aside from that, I think it sends a completely wrong message; where we should be open and inviting, we're instead hostile to those who haven't registered, blocking them from trying to make a contribution when we should be allowing that contribution (with the stipulation that they register) and trying to recruit that user. --  LostInRiverview talk · blog 04:44, March 12, 2012 (UTC)

Post-Consensus
The vote came out 3-3 for the options listed, so obviously a decision one way or the other wasn't reached. Perhaps, before we go into another consensus-gathering period, we can determine whether or not we want to keep the Fanon Namespace operating as-is. If we can determine that a change is definitely wanted, then we can move forward on actually making that happen.

So, in the spirit of this wiki, I'm calling a vote!


 * Question
 * Should The Sims Wiki make some change to how it currently handles unregistered user contributions in the Fanon Namespace?

A response of Yes indicates support for some change to the status quo, a vote of No indicates support for the current arrangement as-is. Seeing as the last vote lasted a week but all responses were logged within two days, I'm going to shorten the countdown to five days, with the possibility of lengthening if interest exists for its lengthening.

Countdown:. Please leave your response below. -  LostInRiverview talk · blog 02:37, March 18, 2012 (UTC)

Yes - Obviously the increase in traffic on the page and the fact that our administrators are having a hard time dealing with angry anons and accumulating anon contributions means that something should be done, or at least investigated. --  LostInRiverview talk · blog 02:38, March 18, 2012 (UTC)

Yes - I stand by what I previously said. It's less likely to make anons angry and it doesn't cut them off from the namespace completely. 11:24, March 18, 2012 (UTC)

I'm sorry if I'm a bit confused since I wasn't following since the beginning of the discussion, but which one is the current policy of the fanon? Is it the one which the Fanon namespace has not been locked yet? If so, then I choose: Yes - Refraining anons from creating fanons will eventually make them have to register. Registered users are easier to be communicated with and backtracked, so we can lend helping hands easier to them. Besides, if they can't make fanons, they might end up in player stories instead.  Nikel  Talk  11:38, March 20, 2012 (UTC)

Yes - Per the above, stops anonymous editors from feeling as locked out as they are now.

Yes - The fanon namespace is getting difficult to deal with. -- RoseGui ( talk here )  12:27, March 24, 2012 (UTC)

Alright, so it's evident that we want some change to how unregistered contributors are handled in the Fanon namespace. Going to open this up for discussion on ideas we could use.

Katy Perry
I just got some info from external site that this exchange page is official from katy perry herself. She uploaded her self sim and I believe its really her because after I download and look carefully that sim is 100% same like katy perry sim used on trailer. Since EA has launched The Sims 3 Showtime Katy Perry Edition, I think we need to create a page for Katy perry sim. what do you think guys?

Note: She also upload a cat named kitty purry but it already removed. I still have the copy of the cat...

Wiryawan310 15:05, March 9, 2012 (UTC)
 * I say we should hold off on creating a Katy Perry page unless EA offers an official Katy Perry downloadable Sim or unless she appears in the Katy Perry Edition as an NPC (similar to Christina Aguilera or Drew Carey). It would be hard to prove that a particular exchange page was owned by a particular person, unless that person themselves announced it, in which case I'd say we need more definitive proof than an external site just saying so. --  LostInRiverview talk · blog 20:23, March 9, 2012 (UTC)

Consensus on 'Consensus'
It occurs to me that we've had a number of, for lack of a better word, 'votes' on issues that are meant to be determined by community consensus. Examples include the vote on closing down Wikia Chat, opening up Requests for Administration/Bureaucrat, and the current (at the time of writing) vote on whether or not to lock the Fanon namespace to anonymous editors.

There are a number of issues with this, at least in my opinion, the first of which is that Wiki Policy states that " [v] oting as a means to determine consensus for a decision should be avoided unless absolutely necessary." In other words, a vote should only occur if it would be impossible or very difficult to determine consensus otherwise, such as through the general discussion that we currently engage in.

Additional problems I see with voting come from when the options available are unclear, change midway through voting, or don't offer a 'status quo' solution. For example, in the vote about whether to lock the Fanon namespace, the two 'stated' options are to either lock it or to implement a grace period for anonymous editors putting content there - there is no option available to keep it the way it is. Preferably, through the discussion process an idea would come forward about what we want; in the example of the Fanon namespace, the discussion might yield support for locking the namespace, in which case the vote should be between whether to lock the namespace or not, not between locking and a third option. Just as easily, the discussion could lean towards a grace period solution, in which case the vote held should be between a grace period option or the status quo.

Finally, there's the issue of what consensus actually is. My belief has always been that consensus is very different than a majority vote. If you have a vote and 10 people participate, with 6 supporting option A and 4 supporting option B, that means that option A, the 'winning' choice received the support of only 60%, while it was opposed by 40%. To me, having 40% of anybody opposed to something doesn't indicate the widespread support needed to implement something. This issue, incidentally, also compounds the 'lack of status quo' problem I mentioned above, as without a status quo to fall back on, if the vote is too close to declare consensus, we really get stuck in a holding pattern that benefits no one.

So, I think that we should make a concerted and unified effort to set some guidelines on what consensus means on The Sims Wiki, and how we're going to handle community-decided issues in the future. To that end, I have written up the following ideas from my personal point of view.


 * 1) Consensus is not a majority vote - it should be clear that there is no significant opposition to something before it is done, or if opposition occurs, that the supporters are open to compromise to make the ultimate decision reflect the wishes of as many people as possible.
 * 2) Votes should only be held when an informal drive to determine consensus has failed and where a definitive decision is necessary. If the community fails to come to a consensus on a solution, but the problem being fixed is not major, there is no reason to force a vote. This would not apply to Requests for bureaucratship, which have specific rules regarding approval.
 * 3) Discussions should be left 'open' long enough for a variety of solutions to come forward, and users should remain open to changing their opinions, preferences and ideas as discussion progresses, eventually culminating in one or two possible compromise solutions that can then be more clearly consented to.

I would love to have some discussion about the nature of consensus, and about my points above specifically. Note that this is not itself a drive for consensus, nor is it a vote. --  LostInRiverview talk · blog 00:16, March 17, 2012 (UTC)
 * I'm alright with the way its being done now, but I'd like to get something written in stone with regards to what defines consensus, e.g. the amount of people who support/oppose it. Usually, I think that around 70% approval is the way to go.
 * The way that I see it, we have a discussion on something for a day or so, and then just skip to a vote. I think it goes this way as discussion can be very active, but will dry out very quickly, and nothing will come out of the discussion - e.g. this discussion to eliminate player stories from a couple of months ago. Simply put, if we could make it so discussion doesn't die as quickly as it begins, we'd be able to collect consensus through another means.
 * On another related note, I think it would be a good idea if we had an option to keep things the way they are in consensus/votes by default.
 * I'm not really sure what consensus is, as far as a set in stone number. I think it depends on the individual circumstances to a degree. While certainly unanimous support for something would be consensus, that rarely happens so making it a requirement would be detrimental. At the same time, 50% or 60% or possibly even 70% support might simply not be that magic point where one could confidently say that the community supported a particular measure. So, to boil it down, I don't know :p --  LostInRiverview talk · blog 00:35, March 17, 2012 (UTC)
 * Added Also I think you're correct in that discussion tends to dry up rather quickly. But just as much, I've noticed that votes often start before that discussion really ended, as if the admin starting the vote wanted to capture that 'action' before it dried up. I'd say that as soon as a vote starts, we usually get some attention back in the subject, so maybe what we should do is state that votes can't begin until the discussion has dried up or until a couple weeks have passed? --  LostInRiverview talk · blog 00:38, March 17, 2012 (UTC)
 * I'd rather it would be that a change would happen with the majority of the community agreeing to it via a "vote" or "consensus". The only reason that I personally feel a "vote" is more effective than a "discussion" is because a "discussion" has the tendency to die pretty quickly whereas a timed "vote" doesn't. I don't think adding something like "discussion should last for a couple of weeks" as a requirement would help much, if at all, because the fact that it dies down is probably more related to the nature of someone having no view on the actual proposal - they just want to either vote for or against it. In my view, a discussion is just...that but about the proposal in general, not about choosing whether to implement it or not.


 * Obviously with a majority vote, the positives and negatives of the proposal should be taken into account when voting. Maybe it can be brought up in the discussion for others to see which can help to prevent "significant opposition" to a proposal but other than that, I'd rather go with a majority vote - it just seems more effective most of the time...or in other words, keep everything how it is now and change almost nothing. 19:37, March 17, 2012 (UTC)
 * Frankly, then, we're at an impasse. I do not believe that a majority is sufficient to make a decision (see here). In fact, even using the term 'vote' interchangeably with 'consensus' dirties the idea of what consensus really is - a general agreement on a course of action, as opposed to what it isn't - a majority vote, or indeed any vote at all. Certainly just because the answer to the problem of dying discussions hasn't become apparent doesn't mean that the status quo is the best solution, so I'd encourage everyone (including myself) to be open minded in searching and discussing possible solutions, rather than sticking with the status quo simply because it's the most convenient and appears to be the most suitable of our options. --  LostInRiverview talk · blog 20:35, March 17, 2012 (UTC)
 * I agree with Georgie, a majority vote seems to be more effective at the time being as I don't think there is any other option - discussions get slow, many people seem to share their views with others but many don't as well. So, votes are quicker and more effective, but what I suggest is: whenever a vote occurs and something comes up (a solution), after a significant amount of time since the vote ended, we should begin a discussion concerning the solution that was decided in the vote to see if the community is actually satisfied with it or not. -- RoseGui [[File:Thanks rose.png]] ( talk here ) 21:44, March 17, 2012 (UTC)
 * I like RoseGui's suggestion. Even if something wasn't everyone's cup of tea, it at least allows them to evaluate the change and they can voice their opinions whether they've changed or not. 21:55, March 17, 2012 (UTC)
 * If we are to stick with voting, then I insist and repeat that a majority simply is not good enough when dealing with major changes. When we've done 'consensus drives' in the past (the example I will link to, the Fanon Namespace creation final consensus, visible here) was, in my opinion, an ideal application of what we more-or-less perform now. That is, over a period of time an option, in this example case the creation of the Fanon namespace, was determined then the community was asked to formally show their support or opposition to it. Taking the results of the formal consensus-gathering, I as an administrator at the time determined that consensus for the creation of the Fanon namespace did exist, despite well-articulated objection from some users. The final margin of support/opposition in that decision is somewhat irrelevant, as what mattered - whether the community by-in-large accepted and consented to the idea - was ultimately decided.
 * I would like to quote what I said at the time: "However, measuring consensus is not the same as voting, and consensus cannot be provided by a simple majority vote, but through stronger support from the community. Consensus is not like a vote total; it can't be quantified and analyzed deeply, since everyone will have different opinions and different strength of support or opposition (or neutrality) towards an idea." Two people who at the time opposed the creation of the Fanon Namespace - RoseGui and Eduardog3000 - seemed to agree with what had happened despite being on the "losing" side. The decision on the Fanon namespace is ultimately the meter stick by which I, either consciously or unconsciously, measure all other decisions and processes. That is my personal judgment, not necessarily that of anyone else.
 * Thinking back to that vote, though, I'd like to hypothesize what might have been the case if I or another admin at the time had 'ruled' a consensus drive to have been successful if only a narrow majority supported the outcome. I know I personally was concerned that even the margin that had been given in that consensus was too narrow to justify creation, so had I been presented with the hypothetical 'slim majority' I can certainly say that I would not have agreed that community consent had been given, even despite my own bias in favor of a particular outcome. So, I'm concerned that if the hypothetical slim majority decision were to occur nowadays, that we would see a different outcome that might very wrongly ignore serious concerns and doubts by a minority - but a sizable minority - of the wiki simply because they couldn't get 51% support. That to me is unpalatable and unacceptable, and very much a reason to make a change to the present system, or at the very least a reason to ensure that a simple majority cannot be construed to indicate community consensus. --  LostInRiverview talk · blog 23:30, March 17, 2012 (UTC)
 * IMO, the reason why a discussion dries up so quickly is because people have no more interest or anything to say merely because that's not really the subject they have a knack for. People in general might only stop by and think, "That's not really a bad idea, why not? Whatever." The thing is, what's discussed doesn't really impact to their knowledge.
 * What GG said makes sense, but what LiR said wasn't wrong too. Voting is not always needed or major, and it might not be that necessary after all. If we are discussing about a particular subject that general people might not really have any idea about the impact, voting might no longer be possible. Instead, we could ask community opinions about what they think about the idea and what they suggest, and then we consider about it, instead of asking whether they should choose option A or B, and no other solutions could possibly appear. I think it's the community opinion and consideration what matters and is important, not how many votes people have chosen for certain options.  Nikel  Talk  12:42, March 20, 2012 (UTC)
 * I think I understand LiR's point but I am concerned that consensus slows down discussions or something. In my opinion, vote should be used when things, that do not affect the wiki to a large extent, like a logo, newsletter logo, etc., but when the change in discussion could have a huge impact, maybe we should go with a consensus. I would also like re-state that we always have the chance to open a discussion where everybody can give their points about on things that were already discussed but need fixes or that somebody is concerned about, and maybe that's what we should do more regularly. What do you all think? Thank you for reading. -- RoseGui [[File:Thanks rose.png]] ( talk here ) 17:17, March 20, 2012 (UTC)

(Resetting indent) I would say that if something isn't major enough to require consensus, than it probably isn't major enough to require any sort of formal action. Changing a logo, making aesthetic changes, etc is something that used to be done without community consensus or voting, and for the most part that was uncontroversial. Perhaps part of the issue is burnout - we're voting on a lot of things, things which have a limited impact or things which in the past were just decided by the editors themselves. So I think maybe what we do is say that if something isn't important enough to warrant an actual discussion and consensus, that we just go ahead and make the changes that are being suggested. If users have a concern or problem with those changes, then they can bring up their problems and then have a discussion. In short, be bold. --  LostInRiverview talk · blog 18:06, March 20, 2012 (UTC)

The Fannies (again)
When the fanon namespace was created, LiR shared an idea (can't remember if it was via IRC or not) about the "Fannies" - an award "ceremony" dedicated to fanon with various nomination categories, such as "Best overall fanon", "Best fan fiction", "Best fanon Sim" etc.

As this wasn't formally mentioned on-wiki, I thought that it would be a nice idea to set it up on a yearly basis (like the Oscars, the Golden Globes etc.) and as the Community Director, I don't see an issue with this and I'd like to know what everyone else thinks of it.

I'd also like to note that this isn't a vote; this is merely asking for opinions on something. 18:14, March 21, 2012 (UTC)
 * I find it a great idea, although I suspect that the big preexisting ones will probably have most share of wins. Fannies IMO if we are to have one should be based on time (that is, those that are completed vs those in progress, for one) MILK FOR THE UNYUUFEX, FLAT CHEST FOR THE CUTENESS THRONE, SKULLS FOR THE SKULL PROBES  (user talk:Mathetesalexandrou) 18:52, March 21, 2012 (UTC)
 * After much digging through archives I found a discussion from around this time last year on this same topic. It seems it was generally supported, and since I support it as well, I say we try it out. Granted, we could have the problem we always seem to get of barely anyone voting, to which I have no solution for :/ Other than that imo the one from a year ago has a few too many categories, I'd prefer it to be something like The Sims Wiki Awards in terms of organisation, and maybe running some sort of external poll to protect privacy and all that stuff.
 * Yeah I was thinking we could go that route. Using an external poll system like Surveymonkey is more secure and eliminates the flaws of Wikia's native poll system, which could be scammed by dynamic IPs etc. 18:49, March 22, 2012 (UTC)
 * I can tell I'm prolific when ideas that I didn't even suggest are being attributed to me :p In fact, I couldn't find anything said by me in that discussion. On a serious note though, I like the idea of doing it externally. Who will serve as judge(s) though? --  LostInRiverview talk · blog 20:32, March 22, 2012 (UTC)
 * This reminds me to Bob's fannies templates.  Nikel  Talk  01:18, March 23, 2012 (UTC)
 * @Nikel - IIRC he made them last year, when another discussion on this was taking place. I don't really like the colour scheme myself, maybe something like the standard gold featured templates.
 * @LiR - As for who to serve as judges, I'm thinking we have some sort of nomination period on-wiki, without any voting, and then all the nominees are put in a poll like the TSW awards.
 * I like the idea for the Fannies and I agree with almost everything above this comment, but I think that we could work on another name (because "Fannies" reminds me of another similar word that shouldn't be mentioned in a place like this). 12:11, March 24, 2012 (UTC)
 * I agree with the suggestion. It would help the fanon namespace to get more interactive. (: And also, I agree with Wogan on making the templates gold. -- RoseGui [[File:Thanks rose.png]] ( talk here ) 12:21, March 24, 2012 (UTC)