The Sims Wiki

The Sims Wiki talk:Community Portal

This is an old revision of this page, as edited by imported>LostInRiverview at 00:38, 17 March 2012 (→‎Consensus on 'Consensus'). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
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.
Broken Links
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.
Contents
Noticeboard
  • Most recently archived on August 23, 2012 -- LiR speak ~ read 00:38, August 23, 2012 (UTC)
  • Notices for community discussions are placed here as necessary. Any user may add their notice. Please sign your notices! -- LostInRiverview talk · blog 08:55, May 29, 2011 (UTC)



Archives Archives
1 2 3 4 6 7 8 9 10 11 12 13 14 15 16 17

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. Lost Labyrinth   • (c) • (b) 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  (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. ―ฬђ talk 05:35, February 29, 2012 (UTC)
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. Lost Labyrinth   • (c) • (b) 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|Talk
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. ―ฬђ talk 04:43, March 7, 2012 (UTC)
I think it would be a good way for newcomers AND experienced players to get to the information they want as fast as possible. DanPin • talk • contribs 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. Lost Labyrinth   • (c) • (b) 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. ―ฬђ talk 04:03, March 9, 2012 (UTC)
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. ―ฬђ talk 01:21, March 11, 2012 (UTC)

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. . Lost Labyrinth   • (c) • (b) 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. Lost Labyrinth   • (c) • (b) 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. ―ฬђ talk 01:19, March 11, 2012 (UTC)

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)

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. ―ฬђ talk 00:31, March 17, 2012 (UTC)
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)
Retrieved from "https://www.thesimswiki.com/wiki/The_Sims_Wiki_talk:Community_Portal?oldid=493717"
Return to the project page "Community Portal".