Feed The Beast Wiki:Centralized discussion

Progress bars

So Retep998 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. -- SatanicSanta🎅^{FTB 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). -- SatanicSanta🎅^{FTB 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 Xbony2 to get a gadget for it. 🐇Retep998🐇^{🐰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. 🐇Retep998🐇^{🐰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 !

-- SatanicSanta🎅^{FTB 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)

Picture	Name of the file	Size for left/right	Size for up/down
	ThermalExpansion Arrow Progress Left.png	48	32
	GUI Smelting Progress.png	48	34
	GUI GregTech Distillery Progress.png	40	36
	Forestry Squeezer GUI Progress.png	86	36
	GregTech Printer GUI Progress.png	40	36
	RotaryCraft GUI Progress.png	48	34
	GregTech4 IndustrialBlastFurnace GUI Progress.png	40	22
	IC2 Bottler GUI Progress.png	34	26
	GregTech4 FusionReactor GUI Progress.png	50	34
	ExtraUtilities QED GUI Progress.png	44	30
	GregTech4 IndustrialCentrifuge GUI Progress Down.png	20	20
	IC2 Canner GUI Progress.png	46	30
	GregTech4 IndustrialCentrifuge GUI Progress Left.png	20	20
	GregTech4 IndustrialCentrifuge GUI Progress Right.png	20	20
	GregTech4 IndustrialCentrifuge GUI Progress Up.png	20	20
	FallingMeteors Freezer GUI Progress Arrow.png	48	34
	FallingMeteors Freezer GUI Progress Snowflakes.png	28	28
	Railcraft RollingMachine GUI Progress.png	50	24
	RailCraft CokeOven GUI Progress.png	44	32
	GregTech Canner GUI Progress.png	40	36
	GregTech Wiremill GUI Progress.png	40	36
	GregTech Sawmill GUI Progress.png	40	22
	IC2 Compressor GUI Progress.png	48	34
	GregTech4 VacuumFreezer GUI Progress.png	40	22
	IC2 Electrolyzer GUI Progress.png	48	34
	GregTech BronzeBlastFurnace GUI Progress.png	40	22
	GregTech Centrifuge GUI Progress.png	40	36
	GregTech4 ChemicalReactor GUI Progress.png	20	60
	GregTech4 Electrolyzer GUI Progress.png	60	20
	Railcraft Crusher GUI Progress.png	58	106
File:Witchery Destillery GUI Progress Arrow.png	Witchery Destillery GUI Progress Arrow.png	76	70
File:Witchery Destillery GUI Progress Bubbles.png	Witchery Destillery GUI Progress Bubbles.png	26	58
	ThermalExpansion Saw Progress.png	32	33
	ThermalExpansion Power Progress.png	33	30
	GUI Smelting Flames.png	28	28
	PamsHarvestcraft Quern GUI Progress.png	48	34
	IC2 Recycler GUI Progress.png	48	34
	IC2 OreWashingPlant GUI Progress.png	40	38
	IC2 Machines Power.png	28	28
	IC2 Macerator GUI Progress.png	48	34
	ThermalExpansion Pulverizer Progress.png	30	30
	GregTech MetalBender Progress.png	40	36
	GregTech CuttingMaschine GUI Progress.png	40	36
	IC2 MetalFormer GUI Progress2.png	66	26
	GUI Thermal Centrifuge Progress.png	10	60
	BloodMagic HellfireForge GUI Progress.png	36	180

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.

-- SatanicSanta🎅^{FTB 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. -- SatanicSanta🎅^{FTB 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. -- SatanicSanta🎅^{FTB 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. 🐇Retep998🐇^{🐰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? -- SatanicSanta🎅^{FTB 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. 🐇Retep998🐇^{🐰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. 🐇Retep998🐇^{🐰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? -- SatanicSanta🎅^{FTB 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 -- Preceding unsigned comment was added by Jinbobo (talk • contribs)

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 [1]. 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)

@media screen and (max-width: 768px){

div#content { margin-left: 11em; }
div#mw-navigation div#mw-panel div.portal { width: 9em; font-size: 66%; }

}

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. --

Jinbobo

04:04, 12 July 2016 (UTC)

That didn't fix it. -- SatanicSanta🎅^{FTB 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. --

Jinbobo

22:31, 12 July 2016 (UTC)

btw accidentally hovered over the share link. it's ugly as hell. -- Preceding unsigned comment was added by Jinbobo (talk • contribs)

Indeed it is. -- SatanicSanta🎅^{FTB Wiki Admin} 00:39, 13 July 2016 (UTC)

I took a look at some other popular wikis (habbo, mc, wow, etc), and it seems like they either remove it, or leave it looking this terrible. I guess we should decide on one of these options, or investigate whether it's actually possible to make it not look like crap -- SatanicSanta🎅^{FTB Wiki Admin} 03:11, 20 July 2016 (UTC)

Is there a way to disable the share popup too for anon. because I'm pretty dang sure that anon won't ever want to share their edits. --

Jinbobo

04:14, 20 July 2016 (UTC)

Fixed this in the global stylesheet. -- SatanicSanta🎅^{FTB Wiki Admin} 00:39, 13 July 2016 (UTC)

Group overhaul proposal

Under this system we would have five primary groups. Groups determine your rights, as laid out in this lovely spreadsheet:

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

Each rank up has all the rights and privileges of the previous rank. To get to the next group, you must first be in the previous group and undergo a vote. All users may participate in votes, although only the votes of editor+ will be counted. When the vote duration is over, the ratio of support votes to against votes will be calculated. If the ratio is greater than 2 (or some other number we decide on) then the vote passes.

• 0. Anonymous. People who aren't logged in. They can do basic edits and read the wiki but need to log in to do anything more.
• 1. Users. Anyone who logs in. Able to do stuff, but not given access to any powerful tools which are annoying or difficult to undo.
  • Autoconfirmed user. Automatically granted by Mediawiki to users when they satisfy the requirements whatever they are.
• 2. Editors. Requires a vote (at least 3 days). Given access to a variety of tools to enable all sorts of editing. Anything that is a normal day to day operation on the wiki should be doable by an editor.
• 3. Admins. Requires a vote (at least 7 days). People that can be trusted with various technical things. Able to use the powerful tools that are difficult to undo, and do stuff like edit the CSS/JS, edit templates that are heavily used, and so on.
• 4. Bureaucrats. Requires a vote (at least 14 days). Handles all the bureaucratic nightmare stuff. Trusted with tools that are highly abusable and rarely needed, such as assigning user rights, managing achievements, dealing with wikipoints, taking care of the abuse filters, and so on.
• 5. Curse. Has all the power because they're Gamepedia.
• bot. Any editor may apply to have a bot, with a vote (at least 3 days). Bot edits are hidden.

In addition to your group, users may additionally have roles. A role does not confer any additional rights, but does confer responsibilities.

• Translators. Must be at least editor. Requires a vote where existing translators in that language have greater voting power (at least 3 days). Basically just translators whose ability to translate to that language has been verified and rubber stamped.
• Developer appointed curator. Must be at least editor. Someone who is responsible for maintaining a specific mod's documentation. Needs to be appointed by the mod author. If not already an editor, then the mod author's nomination counts as an extra support vote towards the user's editor vote.
• Translation admins. Must be at least administrator. Responsible for marking up pages for translation (all admins can do this, but only translation admins are responsible for it).
• Any other role we decide to come up with, or even on request. Want to be responsible for public relations? Go for it. Want to be responsible for posting bunny pictures to new users talk pages? Why not.

Thoughts

Thoughts? I bet NickTheRed37 would love it since it gets rid of staff. 🐇Retep998🐇^{🐰Bunny Overlord🐰} 22:05, 15 July 2016 (UTC)

After a quick run through...

• minoredit should be dropped to 0 as IPs should be allowed to mark their edits as minor
• ipblock-exempt 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
• nominornewtalk looks to normally only go on bots
• noratelimit should be moved up to at least 3 too, as it's designed as user spam protection
• pagetranslation 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.
• undelete 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. 🐇Retep998🐇^{🐰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. -- SatanicSanta🎅^{FTB 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. 🐇Retep998🐇^{🐰Bunny Overlord🐰} 23:05, 15 July 2016 (UTC)

yeah that sounds good, that's basically how it is now but with different groups. -- SatanicSanta🎅^{FTB 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. --

Jinbobo

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). --

Jinbobo

03:37, 16 July 2016 (UTC)

What would this translate to on the forums? I think the way the ranks are presented on the forums are 1. inaccurate, and 2. implicitly exclusionary, so perhaps we should change that too. -- SatanicSanta🎅^{FTB Wiki Admin} 07:59, 17 July 2016 (UTC)

Sysops lumped together with bureaucrats for one wiki admin rank on the forums. I don't know whether I want a rank for editors, but if there is one it should be a separate wiki editor rank. 🐇Retep998🐇^{🐰Bunny Overlord🐰} 14:07, 17 July 2016 (UTC)

and the translator rank? -- SatanicSanta🎅^{FTB Wiki Admin} 18:39, 17 July 2016 (UTC)

---

• Staff is more than a few rights. It's a commitment; it's like a job. By being staff, you're expected to take care of the wiki- to contribute to it, to monitor newcomers, to find ways to improve the wiki, etc. Staff are what make the wiki work. Yes, they form a sort of government. Maybe an unfair government. Maybe staff have too much power, but I don't think the answer is removing them. I don't think a "government" of a dozen or so staff members is less fair than a "government" of a few elitist administrators with all the power. Although we should try to give more rights to regular users wherever possible, I think staff has a place here, and I think removing staff would make this wiki less democratic and less energetic, not more. -Xbony2 (talk) 00:42, 18 July 2016 (UTC)

  I suppose you're thinking about it the wrong way. Why are you assuming that regular editors can't do the exact same things? Are you claiming that you're superior in some way by being staff? Editing wikis shouldn't be a job. The entire sustainability model of wikis is based on the community receiving and returning. Right now the community is receiving a lot (you say the wiki is going up), but isn't giving back. I see that as a problem (editor retention has always been a problem, even with staff, believe it or not. no staff that came before me is still staff. I also had to deal with staff inactivity during my term, there was a time when I actually had to recruit staff on the forums. retep doesn't count as he started as a dac).

  In practice, "staff" is still here, it's just renamed to editors. Your claim that the "staff" label implies some sort of commitment, means you are implicitly shooing away people who can't spend as much time as you can. Editors shouldn't need to worry about time being a problem (your preliminary survey results agree that most people don't edit because of a lack of time commitment, so you're actually arguing against yourself). The task of organizing of wiki should fall naturally on active editors and administrators. The majority of edits should be made by the majority of editors making a bit of edits, not by a small subset of active editors making a lot of edits.

  All I have been arguing for is to take down barriers, and you seem to be focused too much on yourself and your current role (go back and look at your initial rejection of my comments). So I ask you to please, take a step back and think about it again. Of course, changing the groups aren't just going to fix everything. It is going to take deep community interaction to fully have them involved in this again. --

  Jinbobo

  01:44, 18 July 2016 (UTC)

  Not that it matters whether I don't count since I joined the wiki after you became staff anyway, although by only 3 days... You also became administrator a few weeks before I became staff, and you became bureaucrat only a few months before I became administrator. 🐇Retep998🐇^{🐰Bunny Overlord🐰} 03:05, 18 July 2016 (UTC)

  Regular editors can do that. They haven't really been doing that, but that's not the point I'm trying to make.

  Establishing staff as a commitment may push people away from being staff, but from editing in general? I doubt it. "The majority of edits should be made by the majority of editors making a bit of edits, not by a small subset of active editors making a lot of edits"- I agree with this, at least sort of. The way you word it makes it sound as if the few active editors making a lot of edits are the problem, but really it's there being a lack of a large group of users editing. I guess that's you were trying to say. To be honest, I think the few active editors here don't really make a lot of edits, it's just that they look like they make a lot edits because they are the majority of edits.

  Maybe I come off as self-centered, and maybe I am, but I'd like to make it clear I'm wiki-centered more than anything else. I want to make this wiki fucking great. Although it seems like things aren't going my way, I won't storm off in protest like you and other staff have done in the past. It would only damage the wiki- I don't trust the staff-not-staff-editors (whatever they're going to be referred to) to maintain this wiki without me; they haven't been very good at that. -Xbony2 (talk) 14:56, 18 July 2016 (UTC)

  "I don't trust the staff-not-staff-editors (whatever they're going to be referred to) to maintain this wiki without me" are you joking? This is a wiki, not your masterpiece. --

  Jinbobo

  21:43, 18 July 2016 (UTC)

  When I'm on vacation, I always check the wiki. The reason why I do is because the other staff are very slow to react to new contributions, if they do at all. I'm usually the guy who hands out the IP award because I'm usually the guy who does the patrolling. And I know for sure non-translation staff don't look over translations, even when there's glaring issues like templates being incorrectly translated. This is a wiki, but it's also my baby. -Xbony2 (talk) 22:47, 18 July 2016 (UTC)

  Sorry my language got a bit heated there. But what I'm trying to say is that while it is your baby, you can't expect the wiki to go exactly how you want it to be. I also put a lot of time into this wiki, but I've accepted that you can't force an entire community to do everything your way, that would be selfish. I guess what I really want you to do is keep in mind people who wish to contribute or use the wiki (or don't know they can, have little time etc). Think about your objection to visual editor (you say it messes up translation tags), or heck, any objection in general. Is it more geared towards your needs (messing up translation tags means more work for you)? Or is it made with the community in mind (visual editor provides a lower barrier to contribution)? --

  Jinbobo

  02:28, 19 July 2016 (UTC)

  I'd just like to say that I know for a fact at least Peter and I look at just about every edit. If you happen to be the one who patrols them first, that doesn't mean you're the only one who looks at them. When I leave an edit unpatrolled, it means I'm unsure about the information that was changed (often this is the case for mods like Botania which I have not used in over a year), or I don't have the time/ability to verify (often this is the case for recipe changes when I'm on mobile, because GitHub mobile is a PITA). Point is, just because an edit was not marked as patrolled does not mean other staff did not look at it. It might, but it might also mean that we left it unpatrolled to keep it in the list of unpatrolled edits so someone can confirm its information at some point. And I think it's kind of sad that you don't trust fellow staff with patrolling edits on the wiki :( -- SatanicSanta🎅^{FTB Wiki Admin} 05:46, 19 July 2016 (UTC)

  I don't look at every edit, only edits that interest me, so talk pages and GregTech stuff. Also I sometimes look at Santa's edits because they're a common source of mistakes for me to laugh at. 🐇Retep998🐇^{🐰Bunny Overlord🐰} 05:54, 19 July 2016 (UTC)

  I swear I remember you saying the other day on IRC "I look at every edit" -- SatanicSanta🎅^{FTB Wiki Admin} 06:00, 19 July 2016 (UTC)

  I'm not expecting it to go exactly how I want it to be :P I'm pushing for it of course; anybody would push for what they think is better. I want this wiki to have exactly more than a million articles, but that hasn't worked out so well :P (seriously, if we had all of the mods documented, we'd probably be there by now).

  The translation issues with it is a bit more than my objection apparently ;)

  

  Pages made with the VisualEditor have glaring issues. I don't think I've ever seen a page made by the VisualEditor without issues- they always lack important core templates/tags that we require in pages, and the spacing of templates (if there are templates) is always off. And there's not a lack of other issues. It would be great to improve VisualEditor to make it more fit, but some of the issues it has cannot easily be resolved. It isn't the ultimate solution to the wikitext barrier, and that can be easily proved by noticing that all of the major editors here (and largely elsewhere) use the wikitext editor instead of it.

  I think porting my toolbar to VE would help. TemplateData would help. Both would help. The thing I don't like about TemplateData is that creating documentation through it is very difficult (I hate JSON... why the hell is it even a standard thing? Why can't we all agree that it sucks and use YAML for everything?) and it takes about twice as long to create (or more). I don't think it's really worth it, considering VE points to the regular documentation anyway if TemplateData is not there, plus I'd guess a large amount of the users who use VE don't know what templates do in the first place. -Xbony2 (talk) 12:36, 19 July 2016 (UTC)

• ┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
• I'm not saying you shouldn't push for your own views, but from what I can tell, your objections are mostly made with yourself in mind. You keep saying that people don't know how to use templates then why not make them painfully easy instead of saying it's not worth doing? --
  Jinbobo
  17:58, 19 July 2016 (UTC)

  Right. But, how do we do that, Mr. Quantum Computer Scientist? -Xbony2 (talk) 20:34, 19 July 2016 (UTC)

  By creating a stable quantum computation model so that we have enough computing power to create artificial super intelligence programmed to edit wikis and replace your job you don't seriously expect me to give you a possible solution that you're aren't already against? come up with your own or accept other people's solutions.

  I would also argue translation was never a priority, it should not interfere with usual wiki operation. If translation is one reason not to fully support VisualEditor, I would argue for the suspension of the translation project. I revived that project, but I think I made the wrong decision there. We shall see once we have your survey (where you buried the important questions under translation related ones haha) data back . --

  Jinbobo

  04:20, 20 July 2016 (UTC)

  The survey is naturally biased against translations since it in itself is English-only. I don't want to close the translation projects, even if it is providing for a niche community, it is one of our largest attractions. Anyway, translation markup is a pain in the ass. One of my "secret projects" that I would of started on a bit more recently if it weren't for the current reforms (I'm a fan of incremental change) is called T3- the idea is to create a final iteration of the translation interface. The first two "versions" of the translation interface had their issues- the first being that it was difficult and tedious to translate through, and impossible to maintain translations. The second interface, using the Translate extension, has the issues of markup and a limited amount of pages being translatable. I'd like to combine the ease of translation and maintenance of the Translate extension, with the ease of having no markup and having all pages translatable by simply having a language bar of the original interface. I think this would be possible through JavaScript and modules. -Xbony2 (talk) 12:02, 20 July 2016 (UTC)

  Go on, that's interesting. If you do plan to work something out, I would argue that it is feasible to suspend the translation efforts temporarily, by that I mean do a full rollout and support of VE and TD without regard to what that would do to tl tags and then rollout your new translation interface. I really don't know how big of an attraction translated pages on this wiki is, during my time there isn't much interest in the community. I only revived it because I started as a translator. I should also say that you should take input from the community (instead of making it a secret :P) before you do whatever you are planning to do.

  We used to have an analytics plugin and I presume there is a replacement for that? You can probably use that to supplement your survey data? Also how can translations be niche and also be our biggest attraction (is this claim backed with data)? I still argue very strongly that translations really should not be an obstacle to rolling out new features and changes (in fact, I suspended the translation project during the initial transition). --

  Jinbobo

  17:22, 20 July 2016 (UTC)

  I've slowed on marking pages up, but I won't be telling translators to slow down or stop translating, since the translations can be moved over. VE is already "rolled out"- it's on per default (on all Gamepedias, actually). TemplateData doesn't really have much effect on translations. T3 is (semi-)secret because I'm not ready to work on it yet, because of the already existing reforms/refactors (groups, mass tile translations, etc).

  We have an analytics extension, but it's admin+ and doesn't contain a lot of information related to languages anyway (country visited from != language used), and much of that data is currently is missing (Gamepedia hasn't been counting number of views, and by extension number of views for specific pages or number of views from other countries and whatnot). Non-English content is a niche community in that they are a small part of Minecraft, as indicated by a few factors-

  1. One being Dinnerbone here- about 64% of the community uses English while playing Minecraft (if we combine the Englishes), with German and Russian being around 4% each, and other languages being a lot smaller. I have some doubt in the numbers he provides though- zh_CN isn't even mentioned, although Chinese communities are quite large- Japanese is listed as having 2.68% usage, but the Official Japanese Minecraft Wiki has 37,689 edits compared to the Official Chinese Minecraft Wiki with more than twice the same amount of edits. You can point at a lot more numbers to show the Japanese community and many of the other communities shown there as larger are smaller than the Chinese community, but I don't feel the need to. Maybe whatever server Minecraft sends their data to is blocked in China, or maybe the majority of Chinese users pirate the game, I really don't know, but I am more than sure they are underrepresented for some reason or another.
  2. Back to the Minecraft Wikis- if you compare the numbers of the wikis, the English wiki crushes the others. English dominates.
  3. Look around at youtube and other sites- English dominates once again :P I could do a lot more research, but I'm lazy and you probably see the point.

  So, as you can see English usage is far greater when compared to other languages. That's why I call language-specific documentation a niche community. I would expect that modded, a more specific subset of that community, is even smaller percentage wise, although I don't have data to back that, but it does make sense since mods have weaker translation support, making it harder to get into.

  But yes, I called it one of our biggest attractions anyway. The reason for that is that a very large number of recent contributions to this wiki is translations, and almost all of the recent staff are translators, things I don't mind taking a bit of credit for. The reason the activity for that is because there aren't many other non-English modded wikis, so potential users interested in creating/translating modded information are likely to flock to this international wiki where we support their niche. We're basically the only large multilingual modded wiki there is, so the other options are to join existing language wikis if they exist (which they do for some languages [Russian and Chinese come to mind], but they often don't) or to create a new wiki, the later being something quite difficult to do. -Xbony2 (talk) 01:10, 21 July 2016 (UTC)

  By rollout I just mean full support (actually start improving the editing experience with VE, instead of just leaving it there) and no more excuses like "but it messes up translations", that's all. And yes, I'm just asking you to take outside input once you've actually formulated T3, nothing to comment on when there's nothing there :P That's dumb, make them collect pageviews. And I think origin country of traffic is strongly correlated to language preferred, while it isn't an accurate metric, it's a place to start. I am well aware of why we provide the opportunity to translate our pages, you need not lecture me on that. But being the only wiki that provides these accommodation won't mean that any such traffic will flock to us, neither does it mean you need to maintain such status. Other wikis may as well had this conversation already and decided that language support is not worth doing so citing other wikis doesn't mean anything. Furthermore, since English constitutes much (I'd say more than a supermajority) of our traffic, we naturally (and rightly) put our attention to that. So unless there is a demonstrated need for a specific language to be supported, there really isn't a reason to object to anything on grounds of translations, to do so otherwise would be a waste of effort. I don't ever think I've advertised this wiki as "the wiki that anyone can translate," that simply isn't our goal. (as an aside, I don't see any feasible way you would be able to merge the best of two translation systems by just javascript and modules, so surprise me). --

  Jinbobo

  02:18, 21 July 2016 (UTC)

  We can't screw with that extension. It's something that Gamepedia will hopefully fix at some point. We cannot look at the numbers related to traffic by country anymore- it basically just says 0 0 0 0 :P hopefully it's fixed soon. I remember when we last checked, the country the most traffic was from was the US (big surprise), and the second being from Germany, and the third being from the UK. So if you judge by those results by corresponding countries to languages, our German translation project is pretty big, and the combination of the other languages would make the whole translation project be bigger. There are, however, a lot of Germans who speak English and use it, so, like I said I don't think these results are very accurate. I consider multilingualism to be a very important part of this wiki- it's really the only big thing that separates us from our rival wiki, the wiki that must not be named :P and it certainly does get a lot of usage, even if it's a much smaller amount of usage than the English documentation.

  Not feasible? Pfft. It's feasible. It's just going to be hard to make- particularly the JS part, because I don't have a ton of experience with it (fortunately, I have experience in general programming, and also experience in learning how to do things I don't have experience with). -Xbony2 (talk) 14:03, 21 July 2016 (UTC)

  BEHOLD. STATISTICS. http://i.imgur.com/qfxy6La.png 🐇Retep998🐇^{🐰Bunny Overlord🐰} 16:28, 21 July 2016 (UTC)

  Coolio. Well, if you combined the English countries and combined the non-English countries, the ratio is 283,368 to 96,957, pretty close to 3 to 1. It's still not ideal since there are more non-English countries that aren't counted, and lots of people from non-English countries know and use English as a primary language in modded Minecraft. But if we were to assume these numbers correctly corresponding to language usage, that would mean cutting our translation projects would hurt 25% of our traffic... pretty bad. -Xbony2 (talk) 20:31, 21 July 2016 (UTC)

• [insert outdent here]
• do you really think that translations are the only big thing that separates us from ftbwiki.org? seriously? now I'm really skeptical your motivations.
• I'm saying translations not our priority. It shouldn't distract us from the important stuff, given that translations are, ultimately, just translations of english articles. (aside: feasibility implies that I've considered difficulty. given that people spent probably thousands of hours on the translation extension and you claim to have a better solution, I would imagine that you'd also need to spend hours upon hours on that.) --
  Jinbobo
  04:21, 22 July 2016 (UTC)

  Translations are the biggest thing that separate us from them that I can think of. What else is there? Tilesheets? Do non-editors really care about those? In other differences, they have more documentation on the bigger mods, they have a dark skin per default, their staff doesn't spend all their time arguing, they're usually first in the search results, their editorship is declining (at least when compared to us), um, they don't vote over user rights (or at least it doesn't look like they do formally), they have one bureaucrat and about two dozen administrators (majority of which are inactivity- they don't unpromote inactive staff), and... hmm... they don't have visual editor, which has seemed to work out pretty well for them.

  I'd like to point out translation also brings another type of traffic. Many users who joined through translation became tremendously helpful producers of English content. LuminousLizard, 3tusk, ImmortalPharaoh, etc, contributing much to Project Red, BuildCraft, AcademyCraft, Thaumcraft 4, etc. If translation wasn't here, I think there would be a lot missing than we can imagine. That's why it is a priority, and not a small one at that.

  It'll take time, sure, a fair amount of time, but it will be a lot simpler. The Translate extension is highly complex, and it contains a lot of features that T3 never will. -Xbony2 (talk) 12:41, 22 July 2016 (UTC)

  T3, at least in its initial stages, will probably only apply to articles (mainspace mostly). -Xbony2 (talk) 12:46, 22 July 2016 (UTC)

  Not necessarily. I myself came to the English Minecraft Wiki first, and only later did I turned my sight to the Russian wiki. Even people that use English as a second or later language may opt to use and edit the English-language wiki. Because it usually appears to be more full.

  I would be interested in exact statistics in relation between Russian Minecraft Wiki and this wiki. The statictics showed by Retep show that Russia comprises about 14,800 unknown to me points (visitors per day?). Now I need to know what’s the value for my home wiki. Game widow, can you check that? — NickTheRed37 (talk) 12:54, 22 July 2016 (UTC)

  Yeah. A lot of users are like "Hey, a wiki. Look, it's translatable. I suppose I could translate something?" (simplified dramatization). It's sort of the same thing with edits in general, but translation is easier for users to get into (you don't need to worry much about templates, you don't need to do much research, etc), and translated documentation is a bit rarer than original English documentation (You can find English documentation on pretty much any mod; maybe not here, but if you combine this wiki, other wikis, in-game docs, youtube, etc, you can. One of the response to "If you don't contribute very much, why not?" was "well, I can usually find the information I want through Google", one that I didn't foresee when I made the survey). -Xbony2 (talk) 13:15, 22 July 2016 (UTC)

  I can't speak for the rest of the staff so I'll stop here.

  frankly all your arguments made for translations being our biggest attraction are bullshit with no justification. I don't know why I even bothered, talking to you has been like talking to a pit that just spits out angry responses. I'm pretty sure everyone can see through you easily. --

  Jinbobo

  15:39, 22 July 2016 (UTC)

  Excuse me? -Xbony2 (talk) 15:48, 22 July 2016 (UTC)

• Pages made without VisualEditor also have blaring issues, too. I don't see your point there. That was the same argument used to oppose anon editors. -- SatanicSanta🎅^{FTB Wiki Admin} 19:30, 19 July 2016 (UTC)

  You don't get it at all. Many of the glaring (but not really blaring) issues are largely caused by VE. It's like a bad IDE causing bad code. -Xbony2 (talk) 20:34, 19 July 2016 (UTC)

  Arent the issues fairly consistent (like broken lang tags)? We could just write a bot to fix those issues until VE gets fixed. -- SatanicSanta🎅^{FTB Wiki Admin} 20:40, 19 July 2016 (UTC)

  I don't know how possible that is. Do you mean a JS gadget? Feel free to work on it though. -Xbony2 (talk) 21:30, 19 July 2016 (UTC)

  I mean a bot that polls the RC log and checks for the visual editor tag, then does some regex on the page. It'd happen within a few seconds of the edit, I'd imagine. -- SatanicSanta🎅^{FTB Wiki Admin} 21:48, 19 July 2016 (UTC)

---

This proposal still sucks. If you're going to remove staff, you should at least do it right.

1. You're removing staff on the idea groups should be solely right-oriented and not role-oriented, and yet you're still keeping "translator".
2. Same with DAC.
3. Same with translation admin. Well, it's unclear if translation admin is an extension of admin or an extension of editor or just a random right.
4. You're unclear who can vote. You're also unclear on the vote ratio.
5. The abuse filter should be administrator+, as it is on pretty much all wikis. Much of what can be done through the abuse filter can be done through JS anyway. Same with editwidgets, same with nuke, same with protecting pages.
6. Does extending the bureaucrat vote to 14 days really make it better? Does the additionally 7 days really make it more right?
7. You're going to have to remove the ranks on the forums. You're going to have to remove the ranks on Reddit. You're going to have to remove the "Wiki Team" channel on CurseVoice, or replace it with a public "Wiki" channel. You're going to have to make IRC rights admin+ or something. You're going to have to tell Slowpoke we're no longer run by staff, and that anyone who says they're staff is nostalgic or full of crap. You're going to have to depreciate the Staff's Noticeboard and the FTB Wiki Staff page. This is what removing staff means.

-Xbony2 (talk) 13:47, 25 July 2016 (UTC)

I don't really see your point in #7. "Things will have to be updated to this new thing!" isn't really a good argument against something. Peter and I also already talked about the forums; we would have a wiki administrator or bureaucrat rank that can access the secret wiki forum, and everything else would be public. Given the current amount of discussion in that section, I don't think this would be a very major change. Most of the discussion about wiki changes that occurs on the forums is in the public section anyway. I don't see what needs to be hidden from the public aside from boring bureaucratic shit. -- SatanicSanta🎅^{FTB Wiki Admin} 01:16, 26 July 2016 (UTC)

Point 7 is some things you need to do, it's not an argument against it. There should not be any forum ranks with the removal of staff, period, especially not for three administrators. The "new staff" should not be a very small elite group, which is one thing I'm afraid of. Wiki discussions should be public and on the wiki anyway; we agree on that I suppose. But, the few (very few) things that are non-public are better discussed elsewhere. -Xbony2 (talk) 02:17, 26 July 2016 (UTC)

Why shouldn't there be any forum ranks? You didn't give a reason -- SatanicSanta🎅^{FTB Wiki Admin} 02:20, 26 July 2016 (UTC)

Well...

1. Translators aren't a separate group. They're just a role. Roles determine responsibilities, while groups determine rights. I should probably clarify their orthogonality.
2. Ditto for DAC.
3. Ditto for Translation Admin.
4. I will update and clarify this.
5. You do realize that only Curse has the editwidgets right at the moment? As for changing protection, that brings up a question, since protection can be set to bureaucrat only, if admins had the right to change protection, could they remove that bureaucrat only protection? I'm not sure how I feel about your logic "Because this group has power X and power X can be abused to do some really bad stuff, they should be given access to all these other powers that can be abused." Nuke should probably be given to administrators since they have the power to block anyway. I'm not sure how I feel about abuse filter so I will defer that decision to santa.
6. Higher power groups should necessarily have a longer vote period because there is more responsibility and power at stake.
7. I want all wiki related discussion to be public anyway. I don't like having a private channel for the wiki on Cursevoice, I don't like having a private section for the wiki on the forums. Really all that is needed for bureaucrats or admin+ to have some sort of channel for communication with Gamepedia and FTB for technical and bureaucratic reasons. Forum ranks are nothing more than shiny stickers in my view, and I fail to see how removing the staff group means that all wiki related forum ranks have to be removed. IRC has a variety of rights and privileges that can be granted, so if staff was removed I'd just rearrange the IRC groups a bit to reflect the new order, no need to only give IRC rights to admin+, never mind you don't say what an "IRC right" even is. Definitely can't be the right to use IRC since everyone can do that. Also "deprecate", not "depreciate". I don't see a problem with getting rid of the staff noticeboard and focusing discussions in places like centralized discussion or any of the other noticeboards. The Wiki staff page would just be renamed and updated to reflect the new order. The way I envision the staff page is a section for each group, where each group is a list of all the people in that group and their roles.

🐇Retep998🐇^{🐰Bunny Overlord🐰} 02:50, 26 July 2016 (UTC)

I think that the abuse filter stuff should be for bureaucrats, because it is a right that is very rarely used, and when it is, it is usually after a very long discussion. -- SatanicSanta🎅^{FTB Wiki Admin} 04:07, 26 July 2016 (UTC)

If it's Curse-only, why is bureaucrat now? Maybe Curse doesn't want us to have it? The proper right is for admins, but we don't have that extension installed... if we did, though it would be better as admin+, but without?

Extending it to 14 days seems arbitrary at best. How is 7 days not long enough to tell if someone is a bum or not? It's 7 days of extra waiting. If I make an application for bureaucrat, I know half of you are going to vote against me in the first day. After a week, I have little doubt all will be said.

Some of the things you can do with the abuse filter have disappointingly not been implemented here. Having tags for the addition of translation tags, bad words, deprecated templates, etc, would be tremendously helpful. But anyway, I don't think a right being "very rarely used" means that no one should have access to it. That doesn't make sense. -Xbony2 (talk) 13:38, 26 July 2016 (UTC)

no one = everyone qualified --

Jinbobo

02:34, 27 July 2016 (UTC)

Votes

If you wanna vote on this proposal, vote here. All users are allowed to vote, although probably not all votes will be counted.

• Support. I wrote this proposal. 🐇Retep998🐇^{🐰Bunny Overlord🐰} 19:35, 17 July 2016 (UTC)
• I Support this --sokratis12GR ^Staff 19:28, 17 July 2016 (UTC)
• My stance is pretty obvious (Support) -- SatanicSanta🎅^{FTB Wiki Admin} 19:37, 17 July 2016 (UTC)
• Against -Xbony2 (talk) 02:18, 26 July 2016 (UTC)
• Support $\times \infty$. you know, xbony's arguments are pretty focused on trivialities or non-issues if you think about it for a moment. -- [Insert IP here, totally not me] 04:28, 26 July 2016 (UTC)

  Amendment, I would not mind the current listing of former staff just get moved to some archive or get changed to something simple like just a list of names and their roles. I don't know why I bothered bloating up that page, it just looks stupid to me now with that timeline and crap. --

  Jinbobo

  04:35, 26 July 2016 (UTC)