Feed The Beast Wiki:Centralized discussion

Progress bars
So made a pretty neat progress bar thing for the Distillery. You can take a look by adding the relevant CSS from User:Retep998/common.css to your common.css, and then looking at the Alcopops page. I personally think this is a nice improvement. But, we'd like to here everyone's thoughts on this. --  Satanic Santa 🎅F T B Wiki Admin 15:19, 19 April 2016 (UTC)


 * Great work :D ! Looks perfect and gives the wiki a professional impression. --LuminousLizard (Wiki Staff and Editor) de-N / "en-2" (talk) 19:15, 19 April 2016 (UTC)


 * If you can even manage it, that you can make the animation run also from bottom to top. ... => Template:Cg/Hellfire_Forge ... then I would love you ^^ (no homo) --LuminousLizard (Wiki Staff and Editor) de-N / "en-2" (talk) 19:46, 19 April 2016 (UTC)
 * Took me a couple of tries, but here. There should probably be a CSS classes for each direction instead of the generic "progress". -Xbony2 (talk) 21:10, 19 April 2016 (UTC)
 * I prefer if this was a gadget so then it could be disabled, but I'd probably support having it enabled per default. Another note, if you use an older browser, you don't get the animation, but nothing is broken or anything. -Xbony2 (talk) 21:14, 19 April 2016 (UTC)
 * No sorry ... doesn't work correct for me :/ . It moves now from top to bottom, and only a fourth of the way. But it should move from bottom to the top and the full way. --LuminousLizard (Wiki Staff and Editor) de-N / "en-2" (talk) 21:23, 19 April 2016 (UTC)
 * It doesn't suit being a gadget at all, and people can disable it via their own user css anyway if they're that upset by it. I think it's cool.  Chocohead Nag • Edits • Staff 22:24, 19 April 2016 (UTC)
 * Having to muck around with user css is a silly thing to request for us dumdum users. I think it's cool too, but I also think it's too distracting. -Xbony2 (talk) 23:36, 19 April 2016 (UTC)
 * Making it a gadget would require it to have JavaScript, which is not ideal. Also, it really isn't distracting in my opinion. I think it better matches NEI and JEI (probably, haven't actually played 1.8+ yet). --  Satanic Santa 🎅F T B Wiki Admin 23:59, 19 April 2016 (UTC)
 * You're fired!. Gadgets are based on both CSS and JS. -Xbony2 (talk) 00:10, 20 April 2016 (UTC)
 * It now supports horizontal progress bars too. I've also promoted the CSS so everyone can see it without custom user CSS. If anyone wants a way to disable it, speak to to get a gadget for it. 🐇 R e t e p  9 9 8 🐇🐰 Bunny Overlord 🐰 01:45, 20 April 2016 (UTC)
 * I'm a bit embarrassed that you can't figure out how to make a gadget reason 9001 why I should be an administrator not like I figured it out recently or anything.
 * Make MediaWiki:Gadget-Cg-animation.css with the needed CSS.
 * Move User:Xbony2/gadget -> MediaWiki:Gadget-Cg-animation
 * Lastly add  * Cg-animation[default]|Cg-animation.css  to MediaWiki:Gadgets-definition. -Xbony2 (talk) 11:21, 20 April 2016 (UTC)
 * It's not that I can't figure out how to make a gadget (it took me less than a minute to find the relevant mediawiki page describing how to use the extension). It's mostly just you're the only one that seems to care about this being a gadget. But whatever, just for you I made this lovely gadget, and I used a slightly different name while I was at it. 🐇 R e t e p 9 9 8 🐇🐰 Bunny Overlord 🐰 11:36, 20 April 2016 (UTC)

If anyone other than me wants to deal with this, here's a list of all the Cgs that look like they might (I was unsure about a few) look good with progress bars:

Depending

 * Cg/Liquid Transposer => Is a bit difficult because the bubble has a different colour depending on which fluid is produced
 * Cg/Magma Crucible => Is a bit difficult because the bubble has a different colour depending on which fluid is produced
 * Cg/Mana Infusion => Maybe the same with the fluid colour ??? I've never played the mod.

Finished

 * Cg/Blast Furnace/RotaryCraft Done
 * Cg/Blood Altar Has no animation
 * Cg/Botanical Brewery Has no animation
 * Cg/Bottling Plant Done !
 * Cg/Automatic Canning Machine Done !
 * Cg/Automatic Wiremill Done !
 * Cg/Brewing Machine Done !
 * Cg/Bronze Blast Furnace Done !
 * Cg/Canning Machine Done !
 * Cg/Canning Machine/Legacy Done ! Has no animated arrow but power added !
 * Cg/Canning Machine/GregTech Done !
 * Cg/Carpenter Has no animation
 * Cg/Casting Has no animation
 * Cg/Centrifuge/GregTech Done !
 * Cg/Chemical Decomposer Has no animation
 * Cg/Chemical Reactor Done !
 * Cg/Chemical Synthesizer Has no animation
 * Cg/Coke Oven Done !
 * Cg/Compressor Done !
 * Cg/Distillery Done !
 * Cg/Electrolyzer Done !
 * Cg/Extractor Done !
 * Cg/Fermenter/GregTech Progress bar added and doc fixed.
 * Cg/Fluid Canner Done !
 * Cg/Freezer Done !
 * Cg/Fusion Reactor Done !
 * Cg/Grinder Done !
 * Cg/High Oven Done !
 * Cg/Implosion Compressor Done !
 * Cg/Induction Smelter Done !
 * Cg/Industrial Blast Furnace Done !
 * Cg/Industrial Centrifuge Done !
 * Cg/Industrial Electrolyzer Done !
 * Cg/Industrial Grinder Done !
 * Cg/Industrial Sawmill Done !
 * Cg/Infuser Has no animation
 * Cg/Integration Table Done !
 * Cg/Lathe Done !
 * Cg/Macerator Done !
 * Cg/Metal Bender Done !
 * Cg/Metal Former Done !
 * Cg/Ore Washing Plant Done !
 * Cg/Oven Done !
 * Cg/Plate Bending Machine Done !
 * Cg/Plate Cutting Machine Done !
 * Cg/Printing Factory Done !
 * Cg/Pulverizer Done !
 * Cg/QED Done !
 * Cg/Quern Done !
 * Cg/Recycler Done !
 * Cg/Redstone Furnace Done !
 * Cg/Rock Crusher Done !
 * Cg/Rolling Machine Done !
 * Cg/Sawmill Done !
 * Cg/Smeltery Alloying Done !
 * Cg/Solid Canner Done !
 * Cg/Squeezer => The GUI has changed a little. Should I update the old version with the animation, or upgrade the whole template ?
 * We should probably upgrade the whole template if that is the case. -Xbony2 (talk) 11:17, 17 May 2016 (UTC)
 * Updated and progress bar added.
 * Cg/Thermal Centrifuge Done !
 * Cg/Vacuum Freezer Done !
 * Cg/Fermenter/RotaryCraft Done !

--  Satanic Santa 🎅F T B Wiki Admin 05:45, 23 April 2016 (UTC)


 * I take the Cg/Blood Altar and start the list from the bottom and work my way up to the Macerator for the beginning. --LuminousLizard FTB Wiki Staff de-N / "en-2" (talk) 08:32, 23 April 2016 (UTC)
 * Update. --LuminousLizard FTB Wiki Staff de-N / "en-2" (talk) 11:42, 23 April 2016 (UTC)


 * Update and I have created a table for an overview of all currently progress bars. Maybe someone has a good place/page for it. --LuminousLizard FTB Wiki Staff de-N / "en-2" (talk) 11:40, 24 April 2016 (UTC)


 * Since all argue about the job, I'll do the rest. --LuminousLizard FTB Wiki Staff de-N / "en-2" (talk) 10:24, 16 May 2016 (UTC)

Reformed groups proposal
Slam. This is my renewed group proposal, since the current system is a bit of a mess. Comments? Concerns? -Xbony2 (talk) 22:06, 21 June 2016 (UTC)
 * User-only protection is stupid.
 * I don't think I want editors to be able to have bots. Bots can be very, very destructive. Personally I think all of the bots run on the wiki should be open source but that's just me.
 * For DAC, what if their mods are considered complete for the time being? I don't think that should mean we demote them, they are just inactive and have no reason to be active.
 * I'd prefer bureaucrats be the only ones able to manage wikipoints and achievements and things like that. Same with the deleted revision stuff.
 * --  Satanic Santa 🎅F T B Wiki Admin 22:18, 21 June 2016 (UTC)
 * User-only protection gone then.
 * There's already closed sourced bots in place, so making that a requirement is a bit tacky. I guess editors shouldn't have bots.
 * If you haven't done anything in a large time span, you don't really need the user rights or the title. You can call your work done and retire.
 * This is how it is right now and on other wikis. Considering anyone who's an administrator should be hella trustworthy, I don't think it's much of an issue. Although to be honest I think only Curse should have the rights to muck with wikipoints and achievements.
 * (Replying to Choco after a movie break) -Xbony2 (talk) 22:53, 21 June 2016 (UTC)
 * There have actually been a few occasions where Peter and I have had to muck around with wikipoints and achievements due to bugs in the extensions. I don't really want to bother the Gamepedia folks for shit like that. --  Satanic Santa 🎅F T B Wiki Admin 00:00, 23 June 2016 (UTC)
 * If it did work properly, there's no reason why you would need to touch it. Hopefully some day Gamepedia will remove those rights once everything is sorted out. -Xbony2 (talk) 11:07, 23 June 2016 (UTC)
 * If you ever wanted to add an achievement though or change the wiki points calculations it would be much better if the admins/bureaucrats can do it rather than having to wait for a Curse/Gamepedia person to get around to it.  Chocohead Nag • Edits • Staff 15:49, 23 June 2016 (UTC)
 * Yes. I don't trust administrations though- not the administrators here, course', in the category of trustworthiness they're fine, but the administrations of other Gamepedia wikis not so much. I'm pretty sure there's been at least one person who pretty explicitly abused this ability, and there's probably been others. Again, if wikipoints and achievements worked as they should, there would be no need for these rights (#BlameCurse) -Xbony2 (talk) 22:15, 23 June 2016 (UTC)
 * Rubbish, to have features you have utterly no control over would be silly. Anyway, comparing other wikis is a poor idea as we've literally just got Retep and Santa, who are barely on the wiki to start with, compared to other wikis with much larger admin bases (look how good ours is with our efficiency). Your proposal is dependant on the admins being trustworthy, as you frequently reinforced below, to say they are suddenly not is unhelpful to your cause that this proposal is what we want.  Chocohead Nag • Edits • Staff
 * I'm saying some of the administrators on other wikis have abused wikipoints/achievements. I trust Retep and Santa (and future admins of this wiki, assuming I'm around to vote for them) not to give themselves a million wikipoints, but other administrators on other wikis? No way Jose. Becoming administrator on other Gamepedias isn't too tough- all you need is a couple of contributions and a well-written WikiClaim. Simply- admins here are trustworthy, but admins elsewhere... ???
 * Ultimately, Gamepedia has the master keys to give the rights to adjust wikipoints/achievements. Some people have abused this, although most admins have done good things- like us, triggering broken achievements, like whichever-Minecraft-Wiki-that-it-was that added cool custom achievements, etc. If they take those rights away some time, I won't put up a fight. Of course, there's no point in removing wikipoint/achievement rights here, because that's not going to stop abuse elsewhere and it's just going to stager our efforts here. -Xbony2 (talk) 01:07, 24 June 2016 (UTC)
 * We must just be so much better at being a wiki than those ones I suppose.  Chocohead Nag • Edits • Staff 14:55, 24 June 2016 (UTC)
 * obviously -Xbony2 (talk) 00:16, 25 June 2016 (UTC)
 * Four levels of bots is unnecessary, limit them to just Staff and Admins then there's no need for anything other than just Bot. Whether it's open source or not is entirely irrelevant as it's more about whether it's destroying stuff or not.
 * Official translator sounds pointless as it is too limited for only Staff to gain a single extra permission, and not even a major one at that.
 * Editor protection seems a little extreme, there are very few if any pages that would need such a thing.
 * Staff minimum should be able to see deleted revisions of pages, you can't take old but useful information if it's being hidden.
 * Translating tiles is never mentioned (but editing and adding is), what level permissions would that require?
 * I agree with Santa's points too, especially Bureaucrats dealing with matters like Cloudflare.
 *  Chocohead Nag • Edits • Staff 22:30, 21 June 2016 (UTC)
 * It looks like editor bots are going to go poof. Cursebot is here to stay though, since that's global across Gamepedia.
 * Official translator is kind of useless, yes.
 * I like editor protection- I think staff protection is extreme. It allows for important pages to be protected, like Module:OreDict, while still allowing people like KnightMiner to fix it.
 * This is my fault; it's hard to word this properly. Staff can still see what was of deleted pages, as they can now. We can't see deleted diffs/revisions, ex on wikt:Special:Contributions/69.178.195.196. Notice how the date is crossed out and the diff doesn't have a link. Only admins (there, and here) can see it. I don't think diffs should be deleted though, unless they contain personal information, like Eloraam's address or something, which is why only admins should be able to see it.
 * Translating tiles is the same as editing them at the moment (staff only). There's no difference rights-wise; our extension doesn't disambiguate discriminate.
 * Repeat what I said earlier- admins should be hella trustworthy to become admins, so I don't think there's much point in restricting their power to a heavy level. If you don't trust an admin with Cloudflare, don't vote them for admin! (you should totally vote for me though, #bonynottrump2016). -Xbony2 (talk) 01:09, 22 June 2016 (UTC)
 * And derp, Cloudflare rights aren't even a thing any more, so I'm going to remove them from my list. -Xbony2 (talk) 01:13, 22 June 2016 (UTC)


 * What about staff and admim bots?
 * Why did you ever make it then? :P
 * Editors can be made with just a few edits and a member of staff that wants to upgrade them, there's not much point for a page to be protected to such a low level.
 * Then we'll have to make Santa fix it so they can.
 * Ditch Bureaucrats then, if the admins are so trustworthy there's no need for an extra level considering the power they already hold (and you refuse to remove from them).
 *  Chocohead Nag • Edits • Staff 10:32, 22 June 2016 (UTC)
 * Since I'd like it so each user only needs to be in one group; "Bot" (staff bot) and "Admin Bot" are here to stay. I think one group becoming two groups isn't too much.
 * I dunno. It's more of a title, which is silly. Staff is going to be a "big tent" group now, I guess.
 * It's not really a low level. People promoted to editor are done so because they're somewhat trusted. I'd vouch and say editors are ten, no, twenty times more likely to not vandalize and not touch templates/modules that they don't understand.
 * Maybe. I think it's fine staying staff-only though, potentially all of the translations will be imported via bot. Although with descriptions, maybe it would be better to have it be editor+.
 * I tried last proposal. Everyone disagreed with me. Bureaucrats are here to stay. -Xbony2 (talk) 11:08, 22 June 2016 (UTC)
 * What rights, besides changing groups, should bureaucrats have that administrators shouldn't? -Xbony2 (talk) 11:19, 22 June 2016 (UTC)


 * Admin Bot isn't needed either, there's not anything else they'd need to do compared to normal bots.
 * It works better as a big tent than making up roles and pretending it isn't.
 * There's not a demand for protecting pages down to that level though, which it is low as people who may have very little experience actually editing are being allowed to modify "protected" pages. What you're protecting them from is unspecified and seems non-existent. Even for templates/modules they can suggest changes in the talk page if they want to, and besides, if they don't understand it having the ability to edit it isn't going to help as anything they wanted changing would end up on the talk page anyway.
 * Descriptions effectively come as translations, there's no break between them at all (all the GT descriptions Retep added are just en-US translations). I don't think limiting who can translate tiles but still allowing the 2nd lowest level users to translate pages is logical.
 * Maybe you should of tried harder, a lot of the admin level permissions are reliant on being just as trust worthy as someone who is a Bureaucrat, it is not necessary with how the rest of the proposal is working unless admins have fewer permissions. If people have issues with that then they can argue it here anyway, this is a somewhat new proposal so what happened before isn't important if it's not changed to be fully relevant to what we're actually discussing now.
 * Abuse filters as they can affect every edit, achievements, connectstats, wikipoints, as that is bureaucratic stuff, as is the inter-wiki table. It should form a clear divide between admin rights for actually editing pages and bureaucratic rights for dealing with the backend.
 *  Chocohead Nag • Edits • Staff 11:29, 22 June 2016 (UTC)
 * Meh. You never know though. I was thinking making a command to mark up a modified lua navbox via bot would be quite useful, which would require bot-admin rights. There are other possible, although quite rare, reasons an admin bot could be useful, like if the wiki changes URLs. Relying on Curse to fix things like that for us would be a bit lame.
 * yeah
 * It's not that editors don't know what they're doing. It's that some editors do know. I think of editor-protection as staff-protection, plus a few users that can be trusted to not destroy everything, like KnightMiner modifying the OreDict module. Talk page changes are messy at best, and I'd rather not have them for as many pages as I can get away with.
 * I think translating tiles/descriptions should be an editor+ right. Translations of tiles are hard to revert, technical, and debatably experimental.
 * Retep and Santa stomped on it after I applied for bureaucrat, skipping admin. That's one of the reasons I lost that vote. I'd like to see those groups be one, but I don't think that's a term that other staff can agree to.
 * Keeping interwikis as admin+. Revoking other rights. -Xbony2 (talk) 12:15, 22 June 2016 (UTC)


 * Choco: What xbony said about translation undoing.
 * Shouldn't the goal be to make it easier to revert and translate then rather than just hide them for staff to sometimes use but not much because it's effort?  Chocohead Nag • Edits • Staff 15:49, 23 June 2016 (UTC)
 * Probably, but until it is ready for usage it should probably remain editor+ only. -Xbony2 (talk) 21:27, 23 June 2016 (UTC)
 * I suppose, but it shouldn't just be forgotten as the effort that went into making it work/exist in the first place will ultimately be wasted otherwise.  Chocohead Nag • Edits • Staff 22:47, 23 June 2016 (UTC)
 * feel free to nag on santa on that -Xbony2 (talk) 01:08, 24 June 2016 (UTC)
 * I'll remind him that you sent me too.  Chocohead Nag • Edits • Staff 14:55, 24 June 2016 (UTC)
 * Xbony: If you want people to be able to edit protected pages, nominate them for staff. Don't invent arbitrary protection levels so they can edit protected pages. --  Satanic Santa 🎅F T B Wiki Admin 00:10, 23 June 2016 (UTC)
 * That's like saying I have to accept a repair man as a new family member for them to be able to enter my house and fix my (um, leaking) shit. It's silly; staff is (or at least should be) a commitment, and not everybody wants one of those. -Xbony2 (talk) 11:12, 23 June 2016 (UTC)
 * Going with your simile, they can go into your house and suggest a fix but can't actually carry it out. If it's the first time they're ever trying modifying template/modules, what they want to do might not be what they end up trying. So it is better to ask what you want and having someone who knows what they're doing do it, so in the future you'll have a better idea to suggest a fix.  Chocohead Nag • Edits • Staff 15:49, 23 June 2016 (UTC)
 * This goes beyond templates/modules. Maybe some of those remain staff-only, I get it. But potentially this can be applied to high traffic pages, like Getting Started (Main) and List of Mod Author Patreon accounts, and perhaps important mod pages. Vandalism against those sort of pages is only going to grow in the future (for sure- especially when 1.9/1.10 goes mainstream; I fully intend to make sure this wiki has as much info as possible on that version, so we're going to get more clicks, which means more vandalism), but we still want pages like those to be accessible past the small number of staff that would edit them. -Xbony2 (talk) 19:03, 23 June 2016 (UTC)
 * Our vandalism is nearly only creating missing pages with stupid content, we've never had it on things like Getting Started. I think you're prioritising things based of what you expect to happen, in a different place to where it has and actually will.  Chocohead Nag • Edits • Staff 19:11, 23 June 2016 (UTC)
 * For the record, page protection can already be restricted to auto confirmed users, which prevents edits from random IPs and totally new accounts. If you have any specific examples of where that sort of protection wouldn't have stopped vandalism on a page you want non-staff editors to be able to edit, by all means. 🐇 R e t e p 9 9 8 🐇🐰 Bunny Overlord 🐰 19:20, 23 June 2016 (UTC)
 * The Getting Started page was vandalized once actually :P auto confirmed didn't work so well there.
 * Obviously my one example doesn't make much of a point. My point is as this wiki grows, which it's been doing (and there's no way it'll stop ;)), vandalism of high traffic pages may increase and may need protection. In these cases, autoconfirmed protection might be not enough, but staff protection might be overkill. -Xbony2 (talk) 22:08, 23 June 2016 (UTC)
 * I still don't see a situation like that forming, spammers aren't typically going to bother to autoconfirm themselves just to get banned. Our main source of 90%+ of the spam is IPs, which cannot edit autoconfirm protected pages. Maybe if we become much bigger it could be something to consider, but at the moment what we get spam wise just doesn't warrant bothering.  Chocohead Nag • Edits • Staff 22:47, 23 June 2016 (UTC)

look, an outdent^
 * Ewwwww, where'd the nice indent go?  Chocohead Nag • Edits • Staff 14:55, 24 June 2016 (UTC)

I still think it could be useful. To reiterate, it's like staff protection, but with a few extra folks who can be trusted to improve a page or not touch it if they don't know how to. It can also be used in the rare situation where autoconfirmed might not be enough, but staff is far too much. But since ya'll disagree, I'll probably strike it. -Xbony2 (talk) 01:26, 24 June 2016 (UTC)


 * Rare situation is the emphasis here.  Chocohead Nag • Edits • Staff 14:55, 24 June 2016 (UTC)

oh god, don't do this

The point is that it is a situation. Needing protection in general is a rare situation :P -Xbony2 (talk) 00:19, 25 June 2016 (UTC)


 * Well it's not a situation because there's no examples of pages that currently need it. It might be in the future.  Chocohead Nag • Edits • Staff 19:29, 25 June 2016 (UTC)

Well, it is partially to prepare for our future, and for when our future is not our future but our present. I think List of Mod Author Patreon accounts would be a good page to have editor protection. At the moment, and it has staff protection, since it's kind of an official FTB page (it's linked to at the top of forums and on other sites and stuff), but it won't hurt if editors could add to it. -Xbony2 (talk) 00:00, 26 June 2016 (UTC)
 * what's wrong with auto confirmed protection? --  Satanic Santa 🎅F T B Wiki Admin 05:18, 26 June 2016 (UTC)
 * It's more or less the no-protection protection. It's good to stop random IPs from editing pages, but it isn't perfect. -Xbony2 (talk) 12:37, 26 June 2016 (UTC)
 * That's all we'd really have to worry about, uncomfirmed users are much more likely to be throwaway accounts for spamming than confirmed ones, and IPs are the most likely to spam anyway.  Chocohead Nag • Edits • Staff 12:46, 26 June 2016 (UTC)
 * I could argue all day, but I don't see this going anywhere. What's next? -Xbony2 (talk) 14:30, 26 June 2016 (UTC)
 * Nagging Santa about translating tiles I suppose.  Chocohead Nag • Edits • Staff 14:46, 26 June 2016 (UTC)
 * There should be a separate right, and a group for that right, for being able to import tilesheet and oredict entries. This group should then be assigned to the bots of staff users who understand how to work with the tilesheet and oredict system and can be trusted to not muck it up. 🐇 R e t e p 9 9 8 🐇🐰 Bunny Overlord 🐰 13:15, 28 June 2016 (UTC)
 * Why? If a staff member doesn't know how to use them, they don't use them. Chocohead hasn't broken or created any tilesheets yet, since he doesn't know how to or doesn't want to. Same with a fair number of other staff. There's no point in separating those powers from staff.
 * I'm going to take away mass OreDict importing from editors, though. -Xbony2 (talk) 13:35, 28 June 2016 (UTC)
 * The point is to only give it to the bots of staff, so that you don't accidentally import tiles or oredict stuff on your normal non-bot account. 🐇 R e t e p 9 9 8 🐇🐰 Bunny Overlord 🐰 13:39, 28 June 2016 (UTC)
 * That's an alright idea, actually. -Xbony2 (talk) 13:46, 28 June 2016 (UTC)
 * So now, only bots can import tilesheets/mass import oredict. The regular OreDict entry manager is open to editors+, and the tile manager is open to staff+. I'm downgrading the later, since that would allow translations/descriptions, and to fix names and whatnot. -Xbony2 (talk) 13:53, 28 June 2016 (UTC)
 * I knew you'd change your mind. :P  Chocohead Nag • Edits • Staff 13:56, 28 June 2016 (UTC)
 * Change my mind? It's still editor+ -Xbony2 (talk) 14:00, 28 June 2016 (UTC)
 * done -Xbony2 (talk) 13:55, 28 June 2016 (UTC)
 * I can easily create a new right group for tiletranslators, which would allow access to TileTranslator, but not TileManager. Is this something we'd want? OH! And what about SheetManager? --  Satanic Santa 🎅F T B Wiki Admin 17:50, 28 June 2016 (UTC)
 * It would be a good idea to create that right for possible future usage, although for now it's staying editor+. I don't see a point in changing SheetManager from what it is per default. -Xbony2 (talk) 22:17, 28 June 2016 (UTC)

OK! RIP indentation. I've made a few final changes. I've defined a staff vote a 7-day event, as it is right now. I've also changed DAC to needing a 3-day vote; this is no clever guys can make a twenty person team to document a minor mod with two items, and so the ghost of RealSketch can't make a mod and nominate himself. What else needs to be done? -Xbony2 (talk) 21:51, 2 July 2016 (UTC)
 * I disapprove of this. Originally I wanted to phase out the staff rank entirely, now you're just adding more ranks. This is against the wiki spirit. Bots are just bots, they should not have staff rights. Anyone should be able to own a bot once audited. Admin bots are bots with extended privs, eg. deletion. There should only be semi-protection (against new users), temp protection (only admins can edit, limited time period) and full protection (only admins can edit) and other minor protection policies (eg. move protection, template protection). DACs are stupid just make it so that they don't have to go through the standard new user procedure to get to editor and call it a day. Sysop situation here is also very disappointing. -- J.
 * Seriously, you should sign your messages properly. I though you were Jadedcat for a second.
 * Compared to how it was, this is more or less an improvement. It gives more rights to non-staff. -Xbony2 (talk) 22:09, 3 July 2016 (UTC)
 * the issue is that if feels more closed off if there is more "levels" of users. people don't actually go looking at the user rights page now do they. they mostly see the tags people choose to add to their sigs or on their profile. -- properly
 * Where's the issue? There's not really more levels- it's the same. I really wanted to merge admin/bureaucrat, but that was rejected. -Xbony2 (talk) 14:52, 4 July 2016 (UTC)

New editor retention, an invitation
As former wiki lead, I invite everyone to participate in the discussion on the issue of editor retention: Admin's noticeboard -- Jin. (so xbony2 doesn't think i'm jc)

Sidebar covering content
"When I snap my firefox window to half the screen, text from different parts of the wiki overlaps the actual content." -guy from the survey. See. This is particularly bothersome if on mobile in desktop view (used since we all know the mobile view sucks). -Xbony2 (talk) 14:40, 11 July 2016 (UTC)

you'll probably want to reposition the sidebar for narrower frames. i've experienced ads overlapping content but I can't seem to reproduce it. --  Jin bo  bo  04:04, 12 July 2016 (UTC)
 * That didn't fix it. --  Satanic Santa 🎅F T B Wiki Admin 07:12, 12 July 2016 (UTC)


 * Bleh. CSS Specificity. Fixed it. Keep the divs. I've noticed that the navigation bar and the logo are disappearing now. While digging around I did actually find a rule that is identical to my old one except it met the same fate and got overridden by some rule with higher specificity. This is dumb. --  Jin bo  bo  22:31, 12 July 2016 (UTC)


 * btw accidentally hovered over the share link. it's ugly as hell.
 * Indeed it is. --  Satanic Santa 🎅F T B Wiki Admin 00:39, 13 July 2016 (UTC)

Fixed this in the global stylesheet. --  Satanic Santa 🎅F T B Wiki Admin 00:39, 13 July 2016 (UTC)

Group overhaul proposal
Under this system we would have five primary groups, anonymous (0), user (1), editor (2), admin (3), bureaucrat (4), curse (5). I bet would love it since it gets rid of staff.

https://docs.google.com/spreadsheets/d/16-kgsjweghlZVEXkbSOoI8Z8G-qy8PUynlPpj9ctZII/edit?usp=sharing

Thoughts? 🐇 R e t e p 9 9 8 🐇🐰 Bunny Overlord 🐰 22:05, 15 July 2016 (UTC)
 * After a quick run through...
 * should be dropped to 0 as IPs should be allowed to mark their edits as minor
 * should probably be moved up to at least 3, as editors don't require a vote (or even much experience at all it seems) and so might not necessarily be trustworthy
 * looks to normally only go on bots
 * should be moved up to at least 3 too, as it's designed as user spam protection
 * might want dropping down to 2, otherwise translation admins are actually admins too. Unless that's what we're going for, then it's good.
 * definitely needs dropping to 2, otherwise pages can be deleted by editors but then not restored.
 * There might be other things (and I'm sure there are more rights on Special:ListGroupRights than your spreadsheet), but that was what jumped out.  Chocohead Nag • Edits • Staff 22:43, 15 July 2016 (UTC)
 * Personally I think if we do go through with this reform, editors should need a vote, but just a quick 3 day vote. For admin I'm thinking 7 days at least. Bureaucrat at least 14 days. We can also decide on a different support to against ratio for each group, so editors just need a plurality of support while bureaucrats need overwhelming support. 🐇 R e t e p 9 9 8 🐇🐰 Bunny Overlord 🐰 22:59, 15 July 2016 (UTC)
 * I definitely agree that editors will require a vote if we do this proposal. I don't know if the waiting period is particularly important. The ratio thing definitely needs to be defined. --  Satanic Santa 🎅F T B Wiki Admin 23:03, 15 July 2016 (UTC)
 * I'm also thinking that under this reform the DAC program would simply give out the editor right to those people. 🐇 R e t e p 9 9 8 🐇🐰 Bunny Overlord 🐰 23:05, 15 July 2016 (UTC)
 * yeah that sounds good, that's basically how it is now but with different groups. --  Satanic Santa 🎅F T B Wiki Admin 23:56, 15 July 2016 (UTC)

Coolio. It's great as the groups are role based, which give clear criteria for requesting it. undelete usually goes with delete so that sounds good. I think ipblock-exempt for 2 is fine. it's more of a utility right (regular users getting blocked by ip blocks) and I don't expect it to kick in often, so your call. i agree that noratelimit should go to 3. you shouldn't ever hit the rate limit under regular use, unless the oredict and tilesheet extensions messes it up. --  Jin bo  bo  03:27, 16 July 2016 (UTC)

addendum: when I say groups are role based. that means rights are assigned based on what they need to do their job (for example: giving banhammer to staff is a dumb idea). editors should edit, admins should administrate and bureaucrats should turn everything into a bureaucratic nightmare (read: bureaucrats should assign user groups, among other tasks). --  Jin bo  bo  03:37, 16 July 2016 (UTC)