Minecraft Wiki talk:Community portal

This is the community's main discussion page. Talk about just anything here!

 Talkpage archives
 * July - Oct 2010
 * Nov - Dec 2010
 * Jan - Feb 2011

Merge pages about dyes
Having separate pages for each dye seems rather unnecessary to me, especially when you consider the short length of these pages and how little information there is to tell about them. Should we just make one big "Dyes" page that lists all available dyes along with recipes?--Quatroking - Garble Garble! 21:45, 13 January 2011 (UTC)
 * I would support this move, as one of the people keeping an eye on the Wool Page. -St. Fenix (User•Talk) 16:46, 15 January 2011 (UTC)
 * I concur. --Gnu32 09:40, 28 January 2011 (UTC)
 * Seconding this, as I standardized the pages (somewhat), they started to all seem like repetitive stubs. I'm up for doing the grunt work if there's an authoritative consensus. --Miner Key 19:03, 29 January 2011 (UTC)
 * I disagree. I feel they need to be kept separate, lest we dive back into the days when mobs were all on one page.
 * while for now, it seems messed up, a lot of the dyes will likely have secondary uses. Obvious candidates are bone meal, ink sac, coco bean and lapis lazuli. If we merge them all to "dye", then all of the dyes will need merging. We will have 15 infoboxes, info about bone meal as a fertiliser to fit in, info about lazuli ore and all potential future uses for all dyes.
 * This is an editing nightmare, and layout-chaos. and even if the unique ones aren't added, that's still 11-ish infoboxes. That is way too many.--Kizzycocoa 11:23, 31 January 2011 (UTC)
 * Separate page with the list of all the dies, but make it so that material that can be used to create dies have a link to the page:
 * Example-
 * Cactus would have a section for one of it's uses, being creating the [green die] which would be highlighted with a link and when click would be moved to the section of the die page where it would show a cactus, and how to turn it into die.-- RockBreaker 10: 03, 04 February 2011 (UTC)
 * Different items need different articles, so concur. - Cilibinarii 13:34, 6 February 2011 (UTC)
 * I agree completely, as long as its done right. TTorres896 02:17, 2 March 2011 (UTC)

Disabling forced preview on authenticated users and allow unregistered editing with forced preview enabled
Basically, this would mean that people who are already registered would only have to authenticate themselves on their preferences page, which is a really quick job and only requires you to register your email address. After this you are free to edit around without being forced to preview your work first. (but please try to do so every once in a while)

Along with that, we'd like to allow unregistered users to edit again, increasing the community, but only under forced preview so the spam is limited.

Please share your opinions on this matter.--Quatroking -  MCWiki Administrator  21:53, 3 March 2011 (UTC)
 * Personally I don't like unregistered users, I see it as if you can't be bothered registering for the site, then you can't be bothered making any good edits. So the only reason left to use unregistered is for spam.
 * Forced preview, well I'm not sure about that. I don't really think it's all that useful as back when I had it, I'd just click show preview when the page loaded, and start editing afterwards, so it was more of an inconvenience, than a thing to force me to actually check my edits.
 * I'd still like to see a "Trusted editors" group, that gives people some extra tools for editing, while not actually making them admin. – ultradude25 ( T at 22:34, 3 March 2011 (UTC)
 * New user groups are not gonna happen. As for unregistered users, I'm all for it. People aren't going to register to fix typos, but they will fix them from an IP. Even that kind of small edit makes the wiki better. Excluding potential editors because they don't want to register is just anti-wiki. As long as the community and administrators are aware, spam/vandalism should not be a major issue. -- Wynthyst [[Image:User Wynthyst sig icon.png ]] talk  23:39, 3 March 2011 (UTC)


 * I personally am annoyed at the forced preview, but I also think that IPs can have good info, but should be encouraged to register. Hence, put a slight roadblock/inconvenience (forced preview) for them, but for registered users it goes away. --JonTheMon 00:49, 4 March 2011 (UTC)


 * Or make them complete a captcha every edit. :P – ultradude25 ( T at 00:53, 4 March 2011 (UTC)


 * All captchas have been broken by bots. I prefer the forced preview. -- Wynthyst [[Image:User Wynthyst sig icon.png ]] talk  05:49, 4 March 2011 (UTC)


 * That was a joke. – ultradude25 ( T at 06:11, 4 March 2011 (UTC)


 * Not unless you used reCAPTCHA, that stops just about every bot and helps out with books, which I say if possible to use reCAPTCHA on top of this plan and then I'm for it... I guess. IKJames 05:54, 4 March 2011 (UTC)


 * LOL Ultra! And as has been documented, reCaptcha has also been broken by bots. The only real protection from bot spam is a vigilant community. I think this one is ready for anon edits. The potential editors we can gain far outweigh the negatives. -- Wynthyst [[Image:User Wynthyst sig icon.png ]] talk  06:15, 4 March 2011 (UTC)


 * Forced preview for me doesn't work as it should. I end up rushing past preview and still submit mistakes. It'll be much better to have it off for auto-confirmed users; the wikicommunity can shoot down any mistakes or whatnot. As for anonymous editors, they're cool for quickly fixing little spelling mistakes (as they tend to do) but it also opens the flood gates for more spam. Per Wyn though, there's enough activity to stay vigilant here. However, might I suggest using http://www.mediawiki.org/wiki/Extension:Approved_Revs for approving anonymous edits first? This way they can immediately submit fixes without hassle, then it's up to us to confirm them, so the mainspace isn't subjected to spam and malicious edits. --Gnu32 08:00, 4 March 2011 (UTC)