Feed The Beast Wiki

Follow the Feed The Beast Wiki on Discord or Mastodon!

READ MORE

Feed The Beast Wiki
Register
Advertisement
← 2016 | 2018 →

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 NagEditsStaff 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[]

-- 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 ThermalExpansion Arrow Progress Left.png 48 32
GUI Smelting Progress GUI Smelting Progress.png 48 34
GUI GregTech Distillery Progress GUI GregTech Distillery Progress.png 40 36
Forestry Squeezer GUI Progress Forestry Squeezer GUI Progress.png 86 36
GregTech Printer GUI Progress GregTech Printer GUI Progress.png 40 36
RotaryCraft GUI Progress RotaryCraft GUI Progress.png 48 34
GregTech4 IndustrialBlastFurnace GUI Progress GregTech4 IndustrialBlastFurnace GUI Progress.png 40 22
IC2 Bottler GUI Progress IC2 Bottler GUI Progress.png 34 26
GregTech4 FusionReactor GUI Progress GregTech4 FusionReactor GUI Progress.png 50 34
ExtraUtilities QED GUI Progress ExtraUtilities QED GUI Progress.png 44 30
GregTech4 IndustrialCentrifuge GUI Progress Down GregTech4 IndustrialCentrifuge GUI Progress Down.png 20 20
IC2 Canner GUI Progress IC2 Canner GUI Progress.png 46 30
GregTech4 IndustrialCentrifuge GUI Progress Left GregTech4 IndustrialCentrifuge GUI Progress Left.png 20 20
GregTech4 IndustrialCentrifuge GUI Progress Right GregTech4 IndustrialCentrifuge GUI Progress Right.png 20 20
GregTech4 IndustrialCentrifuge GUI Progress Up GregTech4 IndustrialCentrifuge GUI Progress Up.png 20 20
FallingMeteors Freezer GUI Progress Arrow FallingMeteors Freezer GUI Progress Arrow.png 48 34
FallingMeteors Freezer GUI Progress Snowflakes FallingMeteors Freezer GUI Progress Snowflakes.png 28 28
Railcraft RollingMachine GUI Progress Railcraft RollingMachine GUI Progress.png 50 24
RailCraft CokeOven GUI Progress RailCraft CokeOven GUI Progress.png 44 32
GregTech Canner GUI Progress GregTech Canner GUI Progress.png 40 36
GregTech Wiremill GUI Progress GregTech Wiremill GUI Progress.png 40 36
GregTech Sawmill GUI Progress GregTech Sawmill GUI Progress.png 40 22
IC2 Compressor GUI Progress IC2 Compressor GUI Progress.png 48 34
GregTech4 VacuumFreezer GUI Progress GregTech4 VacuumFreezer GUI Progress.png 40 22
IC2 Electrolyzer GUI Progress IC2 Electrolyzer GUI Progress.png 48 34
GregTech BronzeBlastFurnace GUI Progress GregTech BronzeBlastFurnace GUI Progress.png 40 22
GregTech Centrifuge GUI Progress GregTech Centrifuge GUI Progress.png 40 36
GregTech4 ChemicalReactor GUI Progress GregTech4 ChemicalReactor GUI Progress.png 20 60
GregTech4 Electrolyzer GUI Progress GregTech4 Electrolyzer GUI Progress.png 60 20
Railcraft Crusher GUI Progress Railcraft Crusher GUI Progress.png 58 106
Witchery Distillery GUI Progress Arrow Witchery Distillery GUI Progress Arrow.png 76 70
Witchery Distillery GUI Progress Bubbles Witchery Distillery GUI Progress Bubbles.png 26 58
ThermalExpansion Saw Progress ThermalExpansion Saw Progress.png 32 33
ThermalExpansion Power Progress ThermalExpansion Power Progress.png 33 30
GUI Smelting Flames GUI Smelting Flames.png 28 28
PamsHarvestcraft Quern GUI Progress PamsHarvestcraft Quern GUI Progress.png 48 34
IC2 Recycler GUI Progress IC2 Recycler GUI Progress.png 48 34
IC2 OreWashingPlant GUI Progress IC2 OreWashingPlant GUI Progress.png 40 38
IC2 Machines Power IC2 Machines Power.png 28 28
IC2 Macerator GUI Progress IC2 Macerator GUI Progress.png 48 34
ThermalExpansion Pulverizer Progress ThermalExpansion Pulverizer Progress.png 30 30
GregTech MetalBender Progress GregTech MetalBender Progress.png 40 36
GregTech CuttingMaschine GUI Progress GregTech CuttingMaschine GUI Progress.png 40 36
IC2 MetalFormer GUI Progress2 IC2 MetalFormer GUI Progress2.png 66 26
GUI Thermal Centrifuge Progress GUI Thermal Centrifuge Progress.png 10 60
BloodMagic HellfireForge GUI Progress BloodMagic HellfireForge GUI Progress.png 36 180

Survey results[]

Here is a dump of the entire results. Anyway, I'm going to talk about the survey as a whole-

  • This survey started on July 9th. The plan was to close it on August 9th. It's now closed on today, October 1st. Yeah. Around August 9th, we just kept on getting results, so I figured maybe we could until the results slowed down. They didn't. It was suggested that we could just let the survey be ongoing, but this has a few issues- the results are only in the hands of a few users, I'd have to keep checking and releasing the results, and people might have different opinions about certain things as time goes on. I would like to make another survey in the future though, maybe even with a real deadline :P
  • We got 501 responses, not including 2 deleted responses. The 2 deleted responses include one response that was completely blank, and one where every single button was clicked, which would of messed with the overall statistics if it was included. There were some joke/troll/hate responses that I didn't remove, since they didn't mess with the statistics. Originally me and other editors were worried about a lack of responses, but as you can see, plenty came in. Some of the early responses are staff responses, if you want to try and guess which result was whose (I'm the first responder btw).

Question results-

  • What Minecraft version/versions do you usually play on?
    • Survey 1
    • 1.7.10 won this, of course. That was expected. I found when looking through the results, 1.10 appeared more frequently as time went on. It kind of sucks this probably wasn't completely accurate because of the flow of time this survey has taken up.
  • What Minecraft version/versions should the Official FTB Wiki focus on?
    • Survey 2
    • 1.7.10 won this too, but 1.10 was much closer than before; there were many users who reported they used 1.7.10 but wanted us to focus on 1.10. 1.10 also appeared more frequently as time went on.
    • It's important to note this question (and also the previous question) could be answered with multiple versions. Many users voted for both 1.7 and 1.10 (or other "newer" versions), and a few users voted for every single option. I was hoping this question could help provide a contrast between 1.7 and 1.10, but that didn't work out like I wanted it to.
  • What mod/mods should the Official FTB Wiki take attention to?
  • What Modpack Launchers/Installer do you use regularly?
    • Survey 3
    • It took me a long time to figure out how to do this in OpenOffice [I have a certification in Excel, but I don't actually own Excel :/], but 346 responders (71%) used either CurseVoice/FTB. So you could FTB wins, but nearly a third (30%) of the respondents don't use anything FTB related, with 75% not using CurseVoice and 44% not using the FTB Launcher. Keep this in mind for a future proposal of mine.
  • What languages do you have a native (or near-native) understanding of?
    • Survey 4
  • What languages do you have an advanced understanding of?
    • Survey 5
  • What languages do you have an intermediate understanding of?
    • Survey 6
  • What languages do you have a basic understanding of?
    • Survey 7
    • I'd like to encourage you to take these results with a lot of salt. Many, probably near half of users didn't see the "[Include the last answer]" note, or didn't have the patience to listen to it. Maybe I can screw around with OpenOffice some more and try to find accurate results. Anyway, there were a few people who didn't know anything besides from English, and a few people who claimed to know near ten (!) languages. Most people knew English of course. I remember one user in there somewhere who claimed to only know Russian and one user who claimed to only knew Portuguese (I guess they used Google Translate).
  • What languages do you prefer to use while reading documentation?
    • Survey 8
    • English won, of course. Maybe you could look at this results and say "Hey, translations don't matter!". However, this survey is highly biased; because the survey itself (and the site message) is in English, users who didn't know English or only have a basic understanding of English, the kind of users who would be very likely to be interested in translations, were unable to be represented. Anyway, the most popular languages mentioned were German, French and Russian.
    • One thing that might come off as rather disappointing is the lack of votes for Chinese, considering it's our largest translation project (and it's usually the first language that comes up the search bar, except for English). However, according to 3tusk, "if you can access google docs in China... you really wont mind whether the documentation is Chinese or not" (that factor also adds further bias to the results of this questions).
  • How often do you contribute to the Official FTB Wiki?
    • Survey 9
    • You can't really see the numbers here... it's 346 (70.6%) "You can edit wikis? [I never have.]", 95 (19.4%) "I have a few times.", 20 (4.1%) "Sometimes.", 11 (2.2%) "Frequently" and 18 (3.7%) "Very Frequently". It's worth noting a number of users who responded with "very frequently" are users that were lying; I, as someone who knows about everyone around here, could not recognize a fair amount of them by their other results (for example, if you responded to this with "very frequently" and responded to the next question with "Never edited a wiki", you're probably lying). Anyway, the majority of responders have never edited the wiki, as expected.
  • If you don't contribute very much, why not?
    • Survey 10
    • The main reasons for users not contributing is lack of time and lack of interest. This is no surprise. There were a lot of "other" results. "Lack of knowledge" was a big one, which I wish I didn't overlook when I was making this survey. A few users (although a rather small amount) didn't know the wiki was editable. A few users weren't really sure.
  • What platforms should the Official FTB Wiki improve accessibility to?
    • Survey 11
    • Computer browser (improving the regular interface) and in-game Minecraft was the most popular.
  • What web browsers do you usually use?
    • Survey 12
    • Chrome and Firefox won big time. I was surprised by how much, but no matter.
  • When using the wiki, what skin do you prefer? [Note: you can change the skin in your preferences]
    • Survey 13
    • The regular skin won. Santa recommended that I added this question, and I did as you can see. It's kind of a evil, marketing-ish way to alert users the dark skin exists.
  • Do you have any final suggestions or words for the Official FTB Wiki?
    • So... there's were a lot of responses to this. I encourage you to go through the dump. I shared and discussed several of them in IRC, so if there's anything anybody wants to address in particular, feel free to pull it out. There were plenty of heart warming responses, plenty of silly responses, plenty of not very nice responses, and plenty of comments and recommendations.

-Xbony2 (talk) 01:29, 2 October 2016 (UTC)

Here are the suggestions I found most useful:
  • "Getting Started" guides are always the most helpful to me.
    • Though we do usually have getting started guides for most major mods, it might be useful to make sure these actually get updated as often as the content articles do.
  • Please do not abandon old versions of the game.. I understand it is hard to make sure all version notes are well documented but it is very useful to see many versions worth of information
    • This is something I've been thinking about a lot recently actually. The Minecraft wiki has a History section of their articles that lists all the changes in all the versions to that item. I think it may be useful if we pursue something like this as well.
  • The biggest reason I usually go to ftbwiki.org first is that they offer a search engine add-on that I have added to my search bar so I don't need to go to the wiki first before searching (saves a step and I don't need to remember the address or find the bookmark). I'm going to try to make one myself for ftb.gamepedia.com (you can do that on your local computer), but you really should offer/publish one yourselves, they're really easy to do.
    • We can do this, but perhaps we should advertise it a bit more so people know about it.
  • Yeah. Make design a bit lighter and more spaced, because right now it's too cluttered with info that is not immediately needed. Do some metro/material edits, maybe.
    • I agree with this at least partially. Our skin is still basically the old ftb skin just slapped onto Hydra. We should definitely prioritize modernizing it.
  • Too long for language questions
    • Yeah xbony :P
  • ...A simple and effective way to begin fleshing out documentation would be to simply open a poll and let users report on mods' pages that they feel need considerable attention...
    • This is probably a good idea.
  • you sould show a minecraft block harvest level
    • I think it would probably be a good idea to have the same information in our infoboxes as the vanilla wiki does (luminance, transparency, hardness, harvest level, etc). Obviously not including integer ID but you get the point.
-- SatanicSanta🎅FTB Wiki Admin 05:45, 2 October 2016 (UTC)
  • "We can do this, but perhaps we should advertise it a bit more so people know about it."- we talked about this in IRC and we already do this apparently, but we don't have a logo.
  • "I agree with this at least partially. Our skin is still basically the old ftb skin just slapped onto Hydra. We should definitely prioritize modernizing it."- checkout my user CSS btw, I have my toolbar cut in half, and after a month or so of using it it's much better. I was going to request it be added to the main CSS, but there's one glitch I need to iron out (the share dropdown, I've been too lazy to take care of it).
  • "Yeah xbony :P"- that's mostly because of a flaw in the way google's surveys are. Maybe in the future we'll just cut out the languages-you-know questions.
  • "This is probably a good idea."- like I've said before, I don't think we really need much help knowing what needs attention, just getting things done.
  • "I think it would probably be a good idea to have the same information in our infoboxes as the vanilla wiki does (luminance, transparency, hardness, harvest level, etc). Obviously not including integer ID but you get the point."- we had a tool parameter at one point, and to be honest I'm not sure why we removed it. -Xbony2 (talk) 11:42, 2 October 2016 (UTC)

Mod categories structure[]

I think we've all had some frustrations with the current way mod categories and the mod list is structured. In particular, the difference between a mod and a minor mod is debatable, often arbitrary and sometimes meaningless. So I propose this- getting rid of the "Mods" and "Minor Mods" categories, and putting all mods all in one category called "All Mods". Additional categories can also be added to mod pages, like Client-side mods, Performance optimization, IC2 Addons, whatever. On the main page, the entire mod list can be merged as one. Although this seems like it would be rather messy and difficult to navigate, I have a solution for that too- we can put a TOC at the top, similar to what Wiktionary does with large categories. Also I'd like to reduce the font size just a little bit (maybe around the size the unofficial wiki uses, if you go to their main page). The TOC idea does have some issues with translations, but since the mod list would be small enough to navigate for most translations I think it would be fine. -Xbony2 (talk) 13:29, 8 October 2016 (UTC)

we'd just use the current Mods category, "All" is unnecessary. Otherwise at first glance I condone this. Can you make an example of what the main list would look like in your sandbox? -- SatanicSanta🎅FTB Wiki Admin 15:04, 8 October 2016 (UTC)
Your wording makes no sense. Anyway...
The thing I like about the word "all" and why I chose it is because it enforces that all mods should be included in it, and that specific subcategories aren't enough for each page (similar to MediaWiki' wiki). And um, gonna see if I can make a mockup real quick. -Xbony2 (talk) 15:29, 8 October 2016 (UTC)
Something like this. -Xbony2 (talk) 16:00, 8 October 2016 (UTC)
Personally I like this one more as it keeps the image in and the very small text looks a little silly. Both are more compact than the current main page anyway.
Category wise it should just use Mods, as once it had all the mods in and there was no minor mods anymore (because having that too is not helpful if it's purely opinion based with no use what so ever), there'd be no reason it'd need reinforcing. Chocohead NagEditsStaff 16:34, 8 October 2016 (UTC)
I agree with Chocohead on all counts. Also on my wording, I wrote that as soon as I woke up, so sorry. Clearly you got the gist of it though :P -- SatanicSanta🎅FTB Wiki Admin 16:42, 8 October 2016 (UTC)
I'd like it if the TOC (if we may call it that) was just a little bit smaller. The Z falls off on my monitor and it looks silly. -Xbony2 (talk) 22:48, 8 October 2016 (UTC)
(Well, it doesn't fall off my monitor, but it does fall of the line into a new line) -Xbony2 (talk) 10:11, 9 October 2016 (UTC)
How about now? Chocohead NagEditsStaff 12:15, 9 October 2016 (UTC)
Yes :P I don't have a tiny monitor btw, I just have Safari at a certain window size that doesn't cover the entire screen, maybe like half. -Xbony2 (talk) 13:12, 9 October 2016 (UTC)
I would jump on this and do this, but you know, I'm not an admin and can't edit the main page. -Xbony2 (talk) 10:54, 19 October 2016 (UTC)
I'd like to have more input from people before we do this. Stop complaining about not being admin, thanks. cc Retep998. -- SatanicSanta🎅FTB Wiki Admin 16:25, 19 October 2016 (UTC)
I agree that we should not have separate mods and minor mods categories. Just lump all mods together. 🐇Retep998🐇🐰Bunny Overlord🐰 16:29, 19 October 2016 (UTC)
I think I have the right to complain when I have to constantly remind the admins to do stuff. This isn't the first time, this isn't the second time, and I don't think this is the third time either. -Xbony2 (talk) 19:39, 19 October 2016 (UTC)
I'd argue that this is less a case of an admin not doing something, and more a case of not yet concluding on the decision to move forward with the change. At the point you complained, only three people had even commented on this, and this would be a rather significant change to the main page. 🐇Retep998🐇🐰Bunny Overlord🐰 19:51, 19 October 2016 (UTC)
If there are no comments after ten days, then I think it is safe to assume people do not have any concerns and we're in agreement. If you have a problem with it, you should of spoke within the time you had. If I say to my family "Hey, we're getting taco today", and nobody says anything, I think it's safe to assume that they are okay with that or don't care. -Xbony2 (talk) 20:04, 19 October 2016 (UTC)
So is this going to be done, or.... -Xbony2 (talk) 23:55, 25 October 2016 (UTC)
Asking if it's going to be done is no use as the answer could always be yes. If it's going to be done any time soon would probably get you further. Chocohead NagEditsStaff 00:06, 26 October 2016 (UTC)
Do I have to apply for admin to get this done, or is an existing admin going to do it? -Xbony2 (talk) 11:39, 26 October 2016 (UTC)
I'll update the main page as soon as TheSatanicSanta says it is okay to proceed. 🐇Retep998🐇🐰Bunny Overlord🐰 12:26, 26 October 2016 (UTC)
If Santa says "I'll update the main page as soon as Retep998 says it is okay to proceed" I'm gonna slap him :P -Xbony2 (talk) 19:41, 26 October 2016 (UTC)
I'll update the main page as soon as Retep998 says it is okay to proceed -- SatanicSanta🎅FTB Wiki Admin 20:01, 26 October 2016 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Thanks guys. -Xbony2 (talk) 20:57, 26 October 2016 (UTC)

The location of the language bar should probably be fixed. -Xbony2 (talk) 21:06, 26 October 2016 (UTC)
────────────────────────────────────────────────────────────────────────────────────────────────────
I quite like where it is now. Chocohead NagEditsStaff 21:42, 26 October 2016 (UTC)

FTB Infinity Lite 1.10[]

With the release of FTB Infinity Lite 1.10, I'd like to announce a little announcement. At the end of 2014, I made the goal over reaching 8000 articles during the new year of 2015. At the end of 2015, I stretched it to 13,333 articles. Both goals were crushed; we all did great, and I'm shit at guessing projections and making goals. But for this new year, I have a new goal. Rather than reaching a certain amount of articles (which is not really way a great to measure growth), I have a different goal. It's going to be much more difficult, and it will require maximum effort. Here's my dream- to completely document every single mod in FTB Infinity 1.10. *Takes a breath*. Crazy goal, right? FTB Infinity 1.10 is currently not released, but in the meantime we can use FTB Infinity Lite 1.10 to get a sample of it. Achieving this goal will require a lot of hard work from all users. I'm looking for everybody to help out; I might be a crazy documentation-generating machine, but this is not a goal I could achieve alone. I'm looking at you, editor who doesn't do a lot of writing. Lastly, I'd like to dedicate the WikiPack 2 server to the documenting of FTB Infinity Lite 1.10 (and in the future the regular version). So far, all of my goals, even though I thought that they would be unrealistic, have been crushed easily. By that logic, I think we can do this if we work hard enough. Hype! -Xbony2 (talk) 11:30, 4 November 2016 (UTC)

I am with you. If there are good magic mods in FTB Infinity 1.10 (I am pretty sure there is). -IndestructiblePharaohVII 11:44, 4 November 2016 (UTC)
Meh, it's not GregTech. However I will try to dedicate time towards improving non-article things that can help with the FTB Infinity documentation, like improving my tilesheet program and stuff. 🐇Retep998🐇🐰Bunny Overlord🐰 16:03, 4 November 2016 (UTC)
Maybe if you worked on EI a bit more I'd have some extra time to dedicate to the wiki for this ;) I'm sure at least some of the mods I'm playing will be in FTB Infinity so I will be helping at least a little bit. -- SatanicSanta🎅FTB Wiki Admin 17:30, 4 November 2016 (UTC)
I'm not saying we should focus exclusively on FTB Infinity; I'm still going to try to document/maintain Actually Additions and Quark as well as probably other mods. But it will be a focus. And Santa, maybe if you worked on the wiki a bit more I could focus on mods :P -Xbony2 (talk) 20:47, 4 November 2016 (UTC)
Well it seems we have quite the conflict here. -- SatanicSanta🎅FTB Wiki Admin 20:48, 4 November 2016 (UTC)
There is Mekanism in FTB Infinity Lite. Could we ask aidan for using his wiki's content? That wiki looks like all rights reserved though. T3==ThaumicTechTinker, Urey.S.Knowledge Welcome back, commander 19:10, 5 November 2016 (UTC)
Nah, we're probably going to document it from scratch. Aidan is somewhat MIA, so getting in touch with him would be hard. Also he/Indie Wikis might not be fond of competition since they make money off ads to that website... and much of that wiki is outdated anyway. -Xbony2 (talk) 21:12, 5 November 2016 (UTC)
I'll take part of this challenge, I'll write for Forestry and Bee related mods such as gendustry or whatever is avaiable for 1.10, didn't touched 1.10 yet as it's not my motto to suffer like a bastard every time a bug destroys all my creations haha. Frenchiveruti (talk) 05:28, 13 November 2016 (UTC)
Well, welcome :P -Xbony2 (talk) 12:57, 13 November 2016 (UTC)

Where the heck do I upload images[]

So, I give up, I have no idea where I have to look or either uploading format for the bee icons, there's a lot of them that aren't working and I wanted to start filling those gaps, but I can't find any documentation or either the pages that should contain the pictures themselves, take for example the Ardite Bee, it doesn't contain a picture, but I don't know how's the format for the "picture" to be uploaded or what name should I give to it. Frenchiveruti (talk) 14:52, 11 November 2016 (UTC)

Frenchiveruti- Basically, icons on this wiki on done via tilesheet; a tilesheet a big picture with tons of icons. All of the icons for Bees are on the Forestry tilesheet (+the 32x32 version), since Forestry makes all Bees, even those added by addons, be registered under its name (or at least it used to be like that). Currently, tilesheets cannot be extended without help from staff, but this guide should be able to get you where you want to be ^^ -Xbony2 (talk) 15:04, 11 November 2016 (UTC)
Ah, I see, and for what I see on the forestry assets for 1.7.10, they switched to a basic outline with colors and effects added via Java coding, and not anymore via a Tilesheet. Frenchiveruti (talk) 17:24, 11 November 2016 (UTC)
No, I mean, WE use a tilesheet. -Xbony2 (talk) 17:40, 11 November 2016 (UTC)
It doesn't matter how the mod renders its tiles or handles its assets, because we dump the rendered icons from ingame either using NEI or blockrender. Someone with the appropriate permissions then runs the dumped icons through my program to create a tilesheet and uploads it to the wiki. 🐇Retep998🐇🐰Bunny Overlord🐰 17:43, 11 November 2016 (UTC)
Yes yes, I actually read the link that Xbony2 left after writing the comment, anyways, I've already uploaded the PNG Dump and left the link on the right area of the wiki. If I create the TileSheet myself can I send a link to you guys to upload here? I think it would be better to have all the bees separated from the Forestry mod sheet itself, as there's more bees than items from the mod combined. Frenchiveruti (talk) 21:59, 11 November 2016 (UTC)
It would probably bee (gettit) better to have bees in their own tilesheet, but it's not really much of an issue. Anyway, going to update it ^^ -Xbony2 (talk) 22:34, 11 November 2016 (UTC)
done -Xbony2 (talk) 22:54, 11 November 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 autoconfirmed users 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 user 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. Roles are not mediawiki user groups, but rather just arbitrary labels.

  • Translators. Requires a vote where existing translators in that language have greater voting power (at least 3 days). All users are allowed to translate anyway, so this is just a rubber stamp that the user's ability to translate to that language was verified.
  • 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.

After the proposal passes but before the transition actually occurs, there will be a vote for each staff member to decide whether they will become an editor or an admin. 7 days, staff can vote, required support/against ratio is greater than 1.

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

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

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. -- 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. -- 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)? -- 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 ;)
    Translation plus VisualEditor
    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? -- 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 Kappa 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 . -- 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). -- 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). -- 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.) -- 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. -- 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 Kappa -- 02:34, 27 July 2016 (UTC)
I'd rather be as liberal with rights as possible. Obviously things that can be abused shouldn't go to people that could abuse them or misuse them. -Xbony2 (talk) 11:49, 27 July 2016 (UTC)

Maybe it's just me being over-conservative, but is changing the conditions of the vote during the middle of the vote kind of sketchy? -Xbony2 (talk) 21:50, 17 August 2016 (UTC)

In particular, changing the conditions of the vote without asking anyone at all if it is a good idea or not. -Xbony2 (talk) 21:55, 17 August 2016 (UTC)
Well, I realized that making votes contingent on being editor+ was basically preserving the staff exclusiveness thing the proposal is trying to avoid. I thought it would be fairly uncontroversial for anyone who already supports getting rid of staff. You're free to change your vote if you disagree with that though. Also, that isn't changing the conditions of this vote itself, because the proposal hasn't gone through yet and as such cannot apply to this vote. I'll poke anyone who voted to notify them of that change. 🐇Retep998🐇🐰Bunny Overlord🐰 21:57, 17 August 2016 (UTC)
My vote is still against either way (I'm against having votes be autoconfirmed, too). If you're going to make a vote, figure it out before making users be able to vote in it. If you're going to change the vote over time, then I don't think this vote is valid at all. -Xbony2 (talk) 22:25, 17 August 2016 (UTC)
A reason to make all autoconfirmed be able to vote is partially because TheSatanicSanta wanted to have more groups between user and editors for more fine grained control of permissions. Should those people also be allowed to vote? Anyway, as long as everyone who voted support is notified of the change and has the opportunity to update that vote, I don't see any reason the change shouldn't be allowed. 🐇Retep998🐇🐰Bunny Overlord🐰 00:37, 18 August 2016 (UTC)
Ask people first and then change it.
I do not think I should be able to summon all of my friends from, say, Wiktionary, users who have little place or experience here, to vote in my favor and manipulate the vote. The editor right shows trust by fellow editors, autoconfirmed shows trust by the software. -Xbony2 (talk) 01:09, 18 August 2016 (UTC)
right, but at that point "editor" is just the staff rank renamed and the wiki stays as exclusive as it already is. In the future the plan is to not even vote on things very often, so I doubt it will really be an issue. -- SatanicSanta🎅FTB Wiki Admin 18:08, 10 September 2016 (UTC)
If it is judged by numbers, it should certainly not be open to anyone who can make an account. If it is judged by your idea of "consensus", Wikipedia's "consensus" is an admin's decision, and our "consensus" is the staff's (or preferable the editor's) decision. I don't see how the first is less exclusive than the second. -Xbony2 (talk) 21:46, 10 September 2016 (UTC)
You're oversimplifying this. Just because everyone gets the right to vote on things does not mean every single vote is equal. A vote made by a frequent editor with thousands of contributions is "more" than a vote by an IP that fixed a grammatical mistake. Furthermore a vote that also provides an actual list of reasons and creates discussion to improve the proposal has always had more weight than a vote that is simply "Support". Pretty much everything that gets voted on is ultimately up to the administrators (Peter and I right now) anyway, it's just that voting gives us a much easier time coming to a decision. The difference would be that the administrators would need to actually discuss the comments and come to a decision based on that. The group coming to the conclusion doesn't change (except by adding more admins which is not very relevant right now) (therefore the exclusiveness of that decision doesn't change), just what it is based on (discussion rather than numbers). Besides most votes are conditional anyway lately :P -- SatanicSanta🎅FTB Wiki Admin 21:58, 10 September 2016 (UTC)
>Pretty much everything that gets voted on is ultimately up to the administrators
It's ultimately up, or should be ultimately up IMO, to the full staff. They have the powers, sure, but if the administrators act too totalitarian those can easily go poof. This applies to both the current system and proposal. -Xbony2 (talk) 22:16, 10 September 2016 (UTC)

So, what is going on regarding this proposal? What are you waiting for? — NickTheRed37 (discussion & contribs) FTB Wiki Revolutionary 10:37, 10 September 2016 (UTC)

Consensus -- SatanicSanta🎅FTB Wiki Admin 18:08, 10 September 2016 (UTC)
Saying this has a negative effect on my evil agenda, but what does the consensus look like to you?
Also, like ImmortalPharaoh pointed out, new admins should be elected before this system is put into place. I don't want the one and a half admins to be relied on for translation and vandalism for a week. You can simply vote "support if the group vote passes" if you want to, but I don't really see it not passing at this point. -Xbony2 (talk) 22:02, 10 September 2016 (UTC)
Yes we will be electing new administrators and shit before the groups are changed. There are still some things I need to figure out and discuss with Peter before the overhaul IIRC. -- SatanicSanta🎅FTB Wiki Admin 22:07, 10 September 2016 (UTC)

I was thinking about it last night, and I think there is something fundamentally wrong with the way we are doing this. No, not exactly doing this, but also the way that we are looking at it. If we really care about less exclusion, we shouldn't be thinking of rights in terms of "if they won't use it, don't give it to them". If we really care about having less of a power gap, we should be thinking in a liberal sense of "if they won't abuse it, give it to them". If we want less of a power hierarchy, we should be thinking in this latter sense. This is largely how I was thinking when I came up with the idea of merging admin and bureaucrat in one of my earlier proposals, whether I realized it or not. Part of this proposal strips down admin rights based on the earlier clause, which is something that I do not find constructive about it. -Xbony2 (talk) 14:40, 29 December 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.

  • Pictogram voting supportSupport. I wrote this proposal. 🐇Retep998🐇🐰Bunny Overlord🐰 19:35, 17 July 2016 (UTC)
  • I Pictogram voting supportSupport this --sokratis12GR Staff 19:28, 17 July 2016 (UTC)
  • My stance is pretty obvious (Pictogram voting supportSupport) -- SatanicSanta🎅FTB Wiki Admin 19:37, 17 July 2016 (UTC)
  • Pictogram voting opposeAgainst -Xbony2 (talk) 02:18, 26 July 2016 (UTC)
  • Pictogram voting supportSupport . 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. -- 04:35, 26 July 2016 (UTC)

* Pictogram voting neutralNeutral ... because it is not my area of expertise and the others know what they are doing. --LuminousLizard FTB Wiki Staff de-N / "en-2" (talk) 20:44, 28 July 2016 (UTC)

  • Pictogram voting supportSupport - After reading the entire discussion I think I can change my opinion. I support it because a flat hierarchy is better because the rights are more clearly distributed and every person has a clearly position and a short distance to the leadership. After reading the comments I think that a distinction between an "editor" and a "wiki staff member" is bad. It's like a 2 class society among the editors. I don't think that an editor who often contributes to the wiki should get more rights than an editor how rarely contributes. Maybe one has less time to contribute or to play (some people should have a girl-/boyfriend, I have heard), the other doesn't know many about a mod/item/block to contribute much, and again another doesn't want donate to much time for contribution. And sometimes the editor who only contributes rarely writes better articles as an editor who contributes more. Experienced editors (for help) can also be recognized by the number of posts respectively wiki points or . But I'm wondering that the admin losses quite a few rights. What I also learned from the discussion: Xbony2 and Jinbobo don't like each other. --LuminousLizard FTB Wiki Staff de-N / "en-2" (talk) 23:06, 25 December 2016 (UTC)
    Feel free to compare the rights that admins currently have (Special:ListGroupRights) vs the rights that they will have in the spreadsheet linked above (admins are 3). If you have any suggestions, feel free to offer them. 🐇Retep998🐇🐰Bunny Overlord🐰 00:21, 26 December 2016 (UTC)
    I think I'm the last one around us who has the knowledge and understanding of the system to make proper changes. I was referring primarily to the number of rights. Nevertheless, I wonder why rights like editusercss and edituserrjs are given to the bureaucrat because these rights are more technical than bureaucratic. That wiki_points_admin, achievement_admin and award_achievements is given to the bureaucrats, I think that's ok. -- Preceding unsigned comment was added by LuminousLizard (talkcontribs)
  • Pictogram voting supportSupport
    JZTech101 (talk) 21:05, 17 August 2016 (UTC)
  • Pictogram voting opposeAgainst. I see that staff rank cannot be removed. Staff are probably a well known active editor. I see that editors are people who are still learning the wiki and haven't yet mastered how to create almost anything. In my opinion, I see that editors are here to edit and create articles but not create templates, uploading icons for making navboxes and all that work that requires wiki text skill. Staff, on the other hand, have knowledge on how to create almost anything the wiki needs thus, Staff are needed in order to guide people where editors can only teach editing. IndestructiblePharaohVII 21:01, 28 July 2016 (UTC)
    So do you mean that regular wiki users can’t be as experienced as staffers do? Then it becomes a paradox, because the staff system requires first users to be experienced in the first place. Also do you mean that regular users can’t have the right to teach other users? You appear to be too staffist like xbony2. The suggested system still does have an intermediate group between regulars and admins, it’s called “editors”. But it’s not for a role, it apparently should be granted to simply experienced users. — NickTheRed37 (talk) 15:53, 29 July 2016 (UTC)
    What I mean is that staff are the go-to for new users as they are more experienced than editors. You can basically say that staff have more experience and knowledge about the wiki than editors. Or you can say that editors are staff in training as they are considered new or if the user isn't active enough or they do not want to submit a staff application. IndestructiblePharaohVII 16:01, 29 July 2016 (UTC)
    But there is a group more experienced than editors. The admins are people with a lot of technical knowledge and are where users can go to ask for help with complicated stuff. Plus there would be more admins anyway, not just me and santa. 🐇Retep998🐇🐰Bunny Overlord🐰 16:05, 29 July 2016 (UTC)
    (edit conflict) I repeat. Absolutely anyone has the possibility to teach other users, regardless of the status. Also experience doesn’t necessarily correspond with status. I don’t have any special status here anymore, but I can find out and explain how the wiki works. The models for newcomers may quite easily be just administrators, the amount of which will be necessarily increased with abolition of the system. — NickTheRed37 (talk) 16:10, 29 July 2016 (UTC)
    I repeat too, staff are the go-to for new users. If you didn't know, new users are new, which means that they know no-one and they would probably head and ask for staff (like I did) or admins for help. I don't see many admins here and I suggest postponing this request until there are more admins.IndestructiblePharaohVII 16:34, 29 July 2016 (UTC)
    Part of the point of this proposal is that there would be more admins. Postponing a proposal due to a problem that would be fixed by the proposal seems wrong. 🐇Retep998🐇🐰Bunny Overlord🐰 16:37, 29 July 2016 (UTC)
    Then you can remove that point then postpone it until there are more admins as there would be clearly some time before people who are eligible of becoming admins and time to accept the application, etc.IndestructiblePharaohVII 16:44, 29 July 2016 (UTC)
    Some of the current staff will automatically become admins during the transition. Why would I remove that point, that makes no sense. 🐇Retep998🐇🐰Bunny Overlord🐰 17:45, 29 July 2016 (UTC)
    By your dictatorship? -Xbony2 (talk) 00:05, 30 July 2016 (UTC)
    No, instead before the transition actually happens we would have a vote for each current staff member to decide whether they should be admin or editor. 🐇Retep998🐇🐰Bunny Overlord🐰 00:07, 30 July 2016 (UTC)
    Good. -Xbony2 (talk) 00:10, 30 July 2016 (UTC)
    The idea that staff is here to help new editors is just condescending, the very label implies that there is a divide between roles. That label is what NickTheRed and I am against, we're not against having experienced editors nor admins. Furthermore, there is absolutely nothing stopping you from making "technical aspects" of editing painfully easy. That is what we should be working towards instead of defending legacy artifacts and practices. Crafting grid parameters are hard to learn? Maybe you can make VisualEditor generate syntactically correct wikitext, or maybe have the tilesheet extension parse regular ol' strings. Thinking that having a staff is the only solution the problem that wiki editing is difficult and requires experience is completely backwards, unsustainable and against the wiki spirit. -- 21:48, 29 July 2016 (UTC)
    I think he's saying newcomers are more likely to approach users who have the label of "staff" to ask for help. If you look at the Minecraft Wiki, there are a fair number of users who ask the "staff" there (admins) for help, even with things that do not really need administrative attention. I wouldn't really say it's enough of a point in itself to vote against it, though. -Xbony2 (talk) 20:49, 31 July 2016 (UTC)
    Xbony2, you understand me! \o/. -IndestructiblePharaohVII 18:31, 2 August 2016 (UTC)
  • Pictogram voting supportSupport. Liberty, equality and fraternity! — NickTheRed37 (talk) 15:53, 29 July 2016 (UTC)
    Changed your mind about not voting, huh? -Xbony2 (talk) 16:40, 29 July 2016 (UTC)
  • Pictogram voting waitConditional Based on discussions with Peter, assuming some of the requirements are met, then I'm okay with this. Developaws (talk) 03:26, 30 July 2016 (UTC)

Who has the right to vote[]

Who should have the right to vote, or rather whose vote actually counts? The current system is staff. Under the proposal it would either be editors or autoconfirmed users. There needs to be some sort of minimum bar to prevent people from bringing random people over to vote, and to prevent vote fraud, but what should that minimum bar be? Please vote on what you think it should be here. Also, if the bar becomes editor, supposing in the future we get more fine grained groups below editor and above user, should those groups also get voting power? Also, would there be votes where the voting requirement is more stringent, such as voting on whether to take punitive action or whether to make someone a bureaucrat? 🐇Retep998🐇🐰Bunny Overlord🐰 01:17, 18 August 2016 (UTC)

As a point of comparison, wikipedia specifically discourages voting and instead works on "consensus". metawikimedia:Don't vote on everything. 🐇Retep998🐇🐰Bunny Overlord🐰 01:38, 18 August 2016 (UTC)

I think I could get behind following a "Don't vote on everything" system. I think it would encourage more thoughtful discussion on things, and perhaps reduce the amount of "What he said" on votes. Furthermore, voting on a project such as this is by default restrictive, and could end up reproducing the issue this group proposal is trying to address. -- SatanicSanta🎅FTB Wiki Admin 20:27, 18 August 2016 (UTC)
See also- the way I was running my group proposal. -Xbony2 (talk) 21:52, 18 August 2016 (UTC)

Voting/consensus change[]

This is a proposal to change how we achieve consensus on policy changes and what-not. As per metawikimedia:Don't vote on everything, I am proposing that we use a new method to achieve this consensus. Rather than voting on everything, we will simply have a discussion and share insights on the subject, we* will, once discussion cools down or the proposal discussion period ends, interpret the peoples viewpoints to eventually take some action. This allows for better compromises based on peoples opinions and needs, which voting support/oppose does not allow for, among other things.

*The people responsible for finding consensus is dependent on who has the ability to enact the change. If only a bureaucrat can enact the change, then the bureaucrats are responsible for finding consensus. If only an admin can enact the change, then the administrators are responsible for finding it. If any editor can do it, then the administrators or bureaucrats are only necessary when the consensus is not overwhelmingly obvious.

-- SatanicSanta🎅FTB Wiki Admin 22:37, 15 September 2016 (UTC)

Thoughts[]

Votes[]

Ironically, we are voting on this. This vote has been closed for a long time.

  • I Pictogram voting supportSupport this, obviously. -- SatanicSanta🎅FTB Wiki Admin 22:37, 15 September 2016 (UTC)
  • Pictogram voting supportSupport because this gets rid of the barrier of entry. Anyone and everyone can participate and have their voice heard. At the same time, because it isn't vote based, there's no vote fraud to worry about. 🐇Retep998🐇🐰Bunny Overlord🐰 22:49, 15 September 2016 (UTC)
  • Pictogram voting opposeAgainst. For one thing, this is something we kind of do already- we usually talk over changes and apply them if everyone agrees, without voting. Votes are usually reserved for user group changes and large scale, possibly controversial changes; things that should be voted on and discussed before a vote (see also- on Wiktionary, where they generally discuss things on the beer parlor before voting or if voting at all). The problem I have with your idea of "consensus" is that admins/bureaucrats have the final decision instead of the staff's(/more preferably editor's) decision. Anyone can "have their voice heard", even if they can't vote, in discussions. This has hardly been an issue; non-staff editors [the group] themselves have been very rarely involved in votes/discussion, much less non-editors! It is/should be not be too difficult to get editor rights (it's somewhat akin to Wiktionary's requirements- 50 edits predating the start time of the vote by a week, but we go by our own scales than edit count, since edit count is not a perfect measurement, especially here). -Xbony2 (talk) 01:45, 18 September 2016 (UTC)
Your problem with it makes no sense because admins/bureaucrats will only have to find consensus in a few cases. Most of the time the consensus will be found by editors. -- SatanicSanta🎅FTB Wiki Admin 20:13, 18 September 2016 (UTC)
What's voted for is exactly what should be done. -Xbony2 (talk) 21:28, 18 September 2016 (UTC)
  • Pictogram voting opposeAgainst because it's not actually solving anything. Either we don't bother with a vote because everyone agrees or we vote on it and the same people vote every time. We've never really had any non-staff input on major votes, so consensus isn't really going to change what happens past Retep and Santa potentially getting what they want slightly more because they're the ones resolving the winner. It doesn't even fix vote fraud as people could just appear and support an idea informally rather than putting a vote down. The current system is a bit naff, but this won't fix it, if we had more normal users providing input maybe it might. Chocohead NagEditsStaff 23:05, 23 September 2016 (UTC)
  • If it solves the problem that you guys were talking about, then I Pictogram voting supportSupport (sry xbony2 for not voting like you but I want to end this loop) IndestructiblePharaohVII 06:47, 20 October 2016 (UTC)
    3 vote support and 2 votes against generally don't meet a passing requirement. Instead of voting to "end the loop", vote on what's logical. Read Santa and Retep's arguments and then mine and Chocohead's. -Xbony2 (talk) 09:48, 20 October 2016 (UTC)
    Well, from what I have understood that there will be voting except when there is a vote for someone who wants to be an editor or an admin, and I agree with that. IndestructiblePharaohVII 08:24, 21 October 2016 (UTC)
    Not sure what you mean. Basically the proposal is that votes are not counted by number, but ultimately by the interpretations of the person/people that can enact the changes (ultimately Santa/Retep). Santa/Retep have argued this opens up voting for everybody (even though non-staff have hardly ever voted, much less non-editors) and this allows everybody to have their voice heard (even though you can still "have your voice heard" without the right to have your vote count, just like I have talked to my dad about who to vote for vote for US president, even though I cannot vote). I've argued this allows Retep/Santa to pretty much get whatever they want because they're making the final decision, and Chocohead thinks this won't help either. -Xbony2 (talk) 11:15, 21 October 2016 (UTC)
    Gotcha, but they said they will only do that when they there is no consensus achieved. Also, there will be more admins. Which means that there are more people non-editors who can vote and the wiki will pretty much be what the users (those who read) want (which I think what you guys want to do). Ps: Sorry if I did not make any sense but I am sure that you will get what I mean. -IndestructiblePharaohVII 12:12, 21 October 2016 (UTC)
    I'm sad that you really don't trust us that much. -- SatanicSanta🎅FTB Wiki Admin 19:05, 21 October 2016 (UTC)
    I'm sad that nobody realizes this vote has been over for nearly a month now. It was only supposed to last 7 days. 🐇Retep998🐇🐰Bunny Overlord🐰 19:20, 21 October 2016 (UTC)
    I did notice that, but I didn't say anything.
    ImmortalPharaoh7- if we all agree on something that isn't too major, we generally don't vote on it and just do it. That's something we all argue on and already do. There being more admins doesn't really change anything here or have anything to with this vote. Non-editors rarely give their feedback on noticeboards, talk pages and the like, them having the right to vote doesn't really do anything. -Xbony2 (talk) 19:49, 21 October 2016 (UTC)
    You say that as though you can see the future -- SatanicSanta🎅FTB Wiki Admin 19:51, 21 October 2016 (UTC)

Addons in the navbox[]

When I was making {{Navbox Asgard Shield Core}}, I sort of snuck in a little something. I was hoping someone would notice and comment, but alas. Anyway, it's something I 100% stole from the unofficial wiki- including links to the mod's addons in the navbox. I personally think we should do this for all navboxes, as I would argue they are in within the scope of the mod. -Xbony2 (talk) 00:40, 4 January 2017 (UTC)

I noticed, I just didn't say anything because I assumed it was something specific to Asgard Shield Core, like addons– upgrades– for the shields or something. Anyway, since you are bringing this up I'm assuming they are mod addons. In such a case I agree completely. I would however like the input of GreenZombie76 and Retep998 if that's possible since they have documented solely mods with many addons and addons themselves, whereas I have documented, since joining the team (really after 1.4 because when I first started I was primarily documenting GT and IC2), primarily small mods or large mods with no addons (like Witchery and Twilight Forest). -- SatanicSanta🎅FTB Wiki Admin 00:51, 4 January 2017 (UTC)
Seems cool to me. We are talking about the apparent addition of an "mod addons" section to the Navbox? My only concern is that with a mod like Thaumcraft it will make a too-large NavBox even larger.GreenZombie76 (talk) 18:00, 11 January 2017 (UTC)
Yeah that's what we're talking about. I suppose for navboxes that make the Addons section larger than the rest we could have that subgroup default collapsed? -- SatanicSanta🎅FTB Wiki Admin 21:51, 11 January 2017 (UTC)
There's really not that many addons. You can look at the unofficial wiki for about what the size would probably be. -Xbony2 (talk) 00:33, 12 January 2017 (UTC)
Also since it would probably be at the very bottom, I don't think it would make it any more difficult to navigate or anything like that ^_^ -Xbony2 (talk) 00:38, 12 January 2017 (UTC)
If you're only adding a single additional row to the navbox with the addon names on, it's only going to be larger than the rest if the base mod is tiny and has loads of addons. Compared to trying to integrate all the addon's navboxes at the bottom of the main mod's (which would definitely be a bad idea), I don't see why it would be anything but a convenience (apart from maintaining the addon list itself of course). Chocohead NagEditsStaff 23:08, 12 January 2017 (UTC)

Voting Conditions[]

For a while, especially during all the antics with group overhauls, there have been times when votes have happened where the result is ambiguous. There have also been times when new ideas for fixing this situation by deciding on fixed conditions for a particular vote to pass. As fun as predictable order and standardisation is, it makes things less exciting, so I propose we keep the current system just as it is without changing absolutely anything. Anything especially includes creating, voting to and implementing a standard set of conditions for a vote to pass, depending on the type and situation of the vote of course.

In the spirit of the proposal, the vote will end at some vague and unspecified date. Chocohead NagEditsStaff 16:56, 5 January 2017 (UTC)

Support[]

Pictogram voting supportSupport I'm going to support this until Chocohead explains it better 🎅-Xbony2 (talk) 22:38, 5 January 2017 (UTC)
  1. Pictogram voting supportSupport So do I. -IndestructiblePharaohVII 07:51, 6 January 2017 (UTC)
  2. Pictogram voting supportSupport -Moritz30German translator 19:09, 6 January 2017 (UTC)
  3. Pictogram voting supportSupport balance -Xbony2 (talk) 14:00, 8 January 2017 (UTC)

Against[]

  1. Pictogram voting opposeAgainst: The anarchy must end. Chocohead NagEditsStaff 16:56, 5 January 2017 (UTC)
  2. Pictogram voting opposeAgainst: I'm a socialist so I think that would mean I would fundamentally oppose this. I don't really understand this proposal so idk. -- SatanicSanta🎅FTB Wiki Admin 20:17, 5 January 2017 (UTC)
    Voting against something you don't understand isn't the best thing to do you know. I suggest waiting for someone to explain this more (Chocohead). -IndestructiblePharaohVII 20:23, 5 January 2017 (UTC)
    So is voting for something -Moritz30German translator 19:10, 6 January 2017 (UTC)
  3. Pictogram voting opposeAgainst: --LuminousLizard FTB Wiki Staff de-N / "en-2" (talk) 09:24, 8 January 2017 (UTC)

Neutral[]

  1. Pictogram voting neutralNeutral. Specifically chaotic neutral. 🐇Retep998🐇🐰Bunny Overlord🐰 17:10, 5 January 2017 (UTC)
    Pictogram voting neutralNeutral this is all rubbish, I'm just going to make it tie. -Xbony2 (talk) 20:21, 6 January 2017 (UTC)
    One thing though, sokratis is still going to vote I think. -IndestructiblePharaohVII 20:27, 6 January 2017 (UTC)
    I can adjust as needed. -Xbony2 (talk) 20:52, 6 January 2017 (UTC)

Conditional[]

Discussion[]

Uhm... wut? I am confused, can you please summarize and rephrase the paragraph into 2 answers for the questions I have: What? Why? -IndestructiblePharaohVII 18:26, 5 January 2017 (UTC)

Yes Chocohead NagEditsStaff 19:48, 5 January 2017 (UTC)
Meme has gone too farT3==ThaumicTechTinker, Urey.S.Knowledge Welcome back, commander 23:01, 5 January 2017 (UTC)

Vote-ception[]

As seen, the "Voting conditions" didn't go very well, it ended as a tie because those who supported had a condition that Chocohead explains what he said. Seeing as he did not till now, I will open a vote on postponing his suggestion until he has cleared out questions (excluding saying "Yes").

Support[]

  1. Pictogram voting supportSupport Yes. -IndestructiblePharaohVII 10:01, 6 January 2017 (UTC)
  2. Pictogram voting supportSupport because immortal said so. -Xbony2 (talk) 11:59, 6 January 2017 (UTC)

Against[]

  1. Pictogram voting opposeAgainst. The vote by Chocohead has not yet ended because I have not agreed to it ending yet. If you want it to end you will have to bribe me and TheSatanicSanta. 🐇Retep998🐇🐰Bunny Overlord🐰 10:09, 6 January 2017 (UTC)
    How about 2 carrots for you and a ful plate for santa? -IndestructiblePharaohVII 10:21, 6 January 2017 (UTC)
    I find that insufficient. Maybe if you buy me some stuff from my steam wishlist. 🐇Retep998🐇🐰Bunny Overlord🐰 10:24, 6 January 2017 (UTC)
    I can buy you some free games on Steam. -IndestructiblePharaohVII 10:32, 6 January 2017 (UTC)
    How 'bout we don't beat the shit out of you if we see you in real life? -Xbony2 (talk) 11:59, 6 January 2017 (UTC)
    How about we all be nice to each other without threats of violence? 🐇Retep998🐇🐰Bunny Overlord🐰 12:05, 6 January 2017 (UTC)
    And not acting dictatorial? Sure :P -Xbony2 (talk) 12:11, 6 January 2017 (UTC)
    The revolution has begun :D \o/ -IndestructiblePharaohVII 12:15, 6 January 2017 (UTC)
    "In the spirit of the proposal, the vote will end at some vague and unspecified date." By claiming that the vote has ended, that would mean the vote would have to have an explicit and specified date. Because the vote clearly said that would not be the case, your claim that the vote has ended cannot be true. 🐇Retep998🐇🐰Bunny Overlord🐰 12:25, 6 January 2017 (UTC)
  2. Pictogram voting opposeAgainst. The order must continue. Chocohead NagEditsStaff 16:21, 6 January 2017 (UTC)
  3. Pictogram voting opposeAgainst -Moritz30German translator 19:11, 6 January 2017 (UTC)
  4. Pictogram voting opposeAgainst I think Chocohead should answer the questions but postponing the vote is incorrect because there is no set end date. -- SatanicSanta🎅FTB Wiki Admin 20:12, 6 January 2017 (UTC)
  5. Pictogram voting opposeAgainst --LuminousLizard FTB Wiki Staff de-N / "en-2" (talk) 09:27, 8 January 2017 (UTC)
    Et tu, Brute? -IndestructiblePharaohVII 09:37, 8 January 2017 (UTC)
    ??? --LuminousLizard FTB Wiki Staff de-N / "en-2" (talk) 13:59, 8 January 2017 (UTC)
    I think you need to read some Shakespeare. -IndestructiblePharaohVII 14:11, 8 January 2017 (UTC)
  6. Pictogram voting opposeAgainst I agree with the others --sokratis12GR Staff 18:31, 8 January 2017 (UTC)
    Et tu, Brute? IndestructiblePharaohVII 18:33, 8 January 2017 (UTC)
    Yes. --sokratis12GR Staff 18:40, 8 January 2017 (UTC)
    :'( -IndestructiblePharaohVII 18:41, 8 January 2017 (UTC)

Neutral[]

Discussion[]

Results[]

Welp... that didn't go well for me :( -IndestructiblePharaohVII 22:23, 10 January 2017 (UTC)


Giving editors translators markup rights[]

Hello, it's me ImmortalPharaoh7, and I have something that has been bothering me and I want to change it; markup rights for editors translators. Benefits:

  1. Allows editors translators to be able to markup pages and not wait for an admin to mark it up after adding tags.
  2. For lua navboxes, marking it up will allow editors translators to see their changes without having an admin to be around and pushing that one button.

I don't see any inconveniences with not giving it to editors translators since they are basically like delete and move rights, you need to be responsible to use them; which editors translators are. -IndestructiblePharaohVII 20:43, 3 March 2017 (UTC)

Support[]

  1. Pictogram voting supportSupport x 100^100. -IndestructiblePharaohVII 20:43, 3 March 2017 (UTC)
  2. Pictogram voting supportSupport. People can already add translation markup and do it wrong, it hardly happens, but it's not like it's making the situation worse if it does. I suspect most editors won't use it at all if they don't know how to, similar to tilesheets and ore dict and all that rubbish. The main reason why this has been brought to attention is to alleviate the issues with Lua navboxes. I recognize it's not a perfect solution, but I really don't see how it hurts. If we give editors (this vote is for editors, not translators btw, that's a not a group) that right and it turns out the entire wiki blows up, we can take it away and all make fun of me later for being wrong, but I really don't think that's going to happen. -Xbony2 (talk) 01:27, 4 March 2017 (UTC)
    How are we defining blowing up? Chocohead NagEditsStaff 01:41, 4 March 2017 (UTC)
    Causes a mess and everybody says "damn we shouldn't have done this". -Xbony2 (talk) 01:52, 4 March 2017 (UTC)
  3. Pictogram voting supportSupport. Translation markup isn't really that hard, and would be helpful for more efficient work. Also if some things aren't done correctly they can always be fixed, but like Xbony2 stated it happens in rare cases. --sokratis12GR Staff 19:27, 4 March 2017 (UTC)
  4. Pictogram voting supportSupport for Kyth. Here's the proof - IndestructiblePharaohVII 14:14, 5 March 2017 (UTC)
    Can confirm I support it. While it adds scope for breakage, the current system means that regular users basically can't edit translated pages at all without admin help (need to be a translator to translate, and the english translation comes from the source page). Kythyria (talk) 14:24, 5 March 2017 (UTC)
  5. Pictogram voting supportSupport Sure. I think that would not be a bad change. -Moritz30German translator 17:31, 11 March 2017 (UTC)

Against[]

  1. Pictogram voting opposeAgainst Translation markup is confusing. I don't even do it right usually when I get sucked into doing it. I'd rather not have translation managers/admins have to spend time fixing messed up translation markup. Also if a page is not ready to be marked for translation, but it gets marked, then admins have to deal with un-marking it, which is annoying. I'd rather this be left entirely in the hands of translators and translation administrators. -- SatanicSanta🎅FTB Wiki Admin 20:47, 3 March 2017 (UTC)
    Ok, so if the editors get changed to "translators" you would support? -IndestructiblePharaohVII 20:52, 3 March 2017 (UTC)
    Not necessarily. It seems like the coordination between translators and translation admins works fine enough. The only time it doesn't work is for Lua modules. I'd rather we fix that issue instead of adding a band-aid solution. -- SatanicSanta🎅FTB Wiki Admin 20:56, 3 March 2017 (UTC)
    You know that xbony2, the translation admin, lives on the other side of the planet for me, meaning that we don't really talk to each other that much. -- Preceding unsigned comment was added by ImmortalPharaoh7 (talkcontribs)
    I mean the difference between our timezones (mine and yours) is even greater. Also User talk:Xbony2 is a thing :P -- SatanicSanta🎅FTB Wiki Admin 21:06, 3 March 2017 (UTC)
    And we have been talking like 2 messages everyday using LittleHelper and that affects the communication between the translation admin, you, and myself. -IndestructiblePharaohVII 21:11, 3 March 2017 (UTC)
  2. Pictogram voting opposeAgainst I'd much rather see a proper solution to making the translation system easier, especially when it comes to lua modules. Simply giving editors the ability to mark up pages for translation isn't going to help, because translation markup is hard to get right. If an editor is skilled enough to markup various articles templates and modules correctly, then they're likely skilled enough to be an admin. Move and delete rights, on the other hand, are not particularly difficult to use correctly, you just need to understand the basic guidelines of what articles should be named and have a minimum level of responsibility. 🐇Retep998🐇🐰Bunny Overlord🐰 21:05, 3 March 2017 (UTC)
    I'm somewhat skilled enough to add translation markups, even ask xbony2, yet you keep telling me that you highly doubt of supporting me if I apply for one. -IndestructiblePharaohVII 21:11, 3 March 2017 (UTC)
  3. Pictogram voting opposeAgainst All this is doing is perpetuating the current translation system which is definitely not what we want. If you want to be useful, keep pestering xbony2 to actually do T3, so that translation is generally much better than what we've got now (especially for modules). Chocohead NagEditsStaff 14:16, 5 March 2017 (UTC)
    Don't you think that what is xbony2 doing is a large project and requires some time and effort while just giving editors (and translators) the right to work without the need of an admin to be needed is better and easier and a temporary solution till he finishes T3? -IndestructiblePharaohVII 14:23, 5 March 2017 (UTC)
    If all we do is keep using the old system, there's no incentive to actually work on a new one (which he hasn't been doing anyway, so even more reasons not to is definitely not good). Especially if the new one is not particularly compatible format wise with the current system, the more it's used the more that needs to be replaced. We don't even know if that's the case since T3 doesn't exist yet. Chocohead NagEditsStaff 15:08, 5 March 2017 (UTC)
    T3 isn't still ready or in place of being ready, so it's a long wait till it's ready. Xbony2 can work on T3 meanwhile you give us markup rights, so the translation isn't stopped until xbony2 makes a better system. I trust xbony2 with making T3 after you give us the rights since you aren't affected in any way and he is the translation admin. -IndestructiblePharaohVII 15:59, 5 March 2017 (UTC)
    It's only a long wait because he's not started it, translation isn't stopped from this not happening either, forcing him to keep marking pages up himself is a good way of getting him to make T3. It's the current system being stupid that means letting the world be able to translate is a bad idea, not because editors are particularly reckless. Spam doesn't affect us in anyway but it's still something that we don't want, broken translation markings are the same. I don't trust xbony with T3 at all because it's taken so long to get nowhere, he'd had plenty of opportunities to start it yet we're still waiting on something else that wasn't a problem months ago despite T3 not changing plan wise. You need to see where the priority should be. Chocohead NagEditsStaff 16:48, 5 March 2017 (UTC)
    Alleviating the old system a little bit will not slow down T3, that's silly. The reason why T3 has not been worked on is because of other projects being prioritized, once the Modded Minecraft Wiki rename/remarketing is out of the way I should be able to focus on that. Thanks for all the help on that btw guys. Oh wait. (눈_눈). I've had to do most of it myself. If ya'll could help me out with branching out that would be really awesome. -Xbony2 (talk) 15:39, 5 March 2017 (UTC)
    It's not slowing down T3 being made, but slowing down the implementation of T3 to get all the translated pages into the new format. Other (apparently more important) projects have been kicking around undefined for months, yet you still insist how important translation is meant to be, as well as how much better it will be. Renaming shouldn't be taking priority as T3 isn't dependent on it, it's not reliant on the brand so doesn't have to wait for it. Renaming will happen when we actually get a logo and decide on a main page layout, but the lack of any solid proposal means it's hard to make suggestions on nothing. Chocohead NagEditsStaff 16:48, 5 March 2017 (UTC)
    It's not about T3 depending on it, it's about it being prioritized over it at the moment. I can't work on twenty projects at once. If I did, T3 will look like the removal of staff so far- half-assed and incomplete because Santa and Retep are too busy to work on it. That wouldn't be better than now. It's more than renaming, it's remarketing and redefining the wiki, which is what I am currently trying to work on. -Xbony2 (talk) 17:01, 5 March 2017 (UTC)
    What exactly are you doing to remarket the wiki?
    Okay, I'm really gonna need you to stop complaining vaguely and indirectly about whatever it is I'm not doing at the time. When I'm developing extensions or libs or doing bureaucratic shit, you complain I don't write content. Now I'm writing content, so you're complaining I'm not doing bureaucratic shit. If you want me to do something, which you clearly do, just fucking tell me instead of vaguely complaining about my lack of doing Unknown Thing (TM) to Chocohead. -- SatanicSanta🎅FTB Wiki Admin 17:31, 5 March 2017 (UTC)
    Okay, this is getting out of context, the vote is on giving markup rights to editors. That will make admins like xbony2 free for other crap like T3 or anything else instead of marking stuff up. My proposal would free some work out of xbony2 (since he is doing most if not all of the markups) and put more responsibility on translators / editors to translate while xbony2 has the time to do other stuff like working on T3 (I'm also willing to help if I know how to) and renaming / remarketting the wiki.
    In conclusion, if my proposal passes, it will free time to admins and others who have markup rights to do other stuff.-IndestructiblePharaohVII 17:44, 5 March 2017 (UTC)
    This very much is the context, you're talking about the translation system and that's what's being discussed. You're not going to be saving any time with this change though, as it's going from admins marking things up right (or at least you better hope they do) to people marking things up then the admins having to fix it if they do it wrong. The admins still have to check the marking up of translations so they're no better off. You've got to remember it's not just you who is getting the ability to mark things up if this passes, and if other people start doing it wrong the right will just get revoked and then you're no better off from it. Chocohead NagEditsStaff 17:56, 5 March 2017 (UTC)
    This proposal is only gonna add a right, and if editors don't know markup, they don't. Easy. On the other hand, people who know how to markup will not waste admins time since they will only check if they missed anything and thus taking less time. -IndestructiblePharaohVII 18:00, 5 March 2017 (UTC)
    Editor is the most basic permission people can gain, just because they don't know something doesn't mean they won't try use it. Easy is an incredibly naive approach to take when there's plenty on examples of translated pages for people to try having a go. Admins still have to check the translated pages which isn't really much faster than just doing it themselves, you still have to check everything which you'd have written yourself otherwise. Admin's time isn't heavily invested in marking up translations anyway, so there's little benefit to be gained at all. Chocohead NagEditsStaff 18:23, 5 March 2017 (UTC)
    This is not how it works. Editors aren't beginners, users are. Since it takes voting in order to become one and thus they have a responsibility, as well as we can tell them don't do stuff they don't know how to use. Easy. Plus, you are the people who voted on removing the staff, so there is a gap between editors and admins. -IndestructiblePharaohVII 20:37, 5 March 2017 (UTC)
    You've not read what I wrote properly. Editor is the most basic permission people can gain, not have. Voting them in, as proven a few days ago, is a hollow procedure as one or two people actually bother voting then it automatically passes so there's hardly much investment responsibility wise. This shouldn't chance though as there's no benefit from restricting new enthusiastic people by having a long process to make them editors. Telling them not to use things they don't understand isn't productive though, at best you're just scare them from experimenting, at worse you'll scare them from editing at all. We have complicated templates for example, telling people to not use them because they don't understand is not going to make them better contributors. Removing staff doesn't change much in this situation anyway, having a separate translators permission is the only way of handling this, not just trusting people to be able to use the mess of the translation system because they can edit normally or just trusting them to not touch it. Chocohead NagEditsStaff 21:27, 5 March 2017 (UTC)
    I trust current editors for not doing anything irresponsible. Also, you could just write a proposal to create a translators group instead of completely going against this one. -IndestructiblePharaohVII 06:46, 6 March 2017 (UTC)
    Current editors are not the same as the future, unless of course we never get anyone else new again, which is probably much worse. Either way though, If you want it passing so badly you can make your translation group suggestion yourself because I definitely don't support this one. Chocohead NagEditsStaff 16:01, 6 March 2017 (UTC)

Neutral[]

  1. Pictogram voting neutralNeutral I'd like to see some sort of automatical solution... (my browser will crash if i press "delete" button so i cannot correct my typo) T3==ThaumicTechTinker, Urey.S.Knowledge Welcome back, commander 00:22, 6 March 2017 (UTC)
    Gee, you should probably get that fixed. -Xbony2 (talk) 00:33, 6 March 2017 (UTC)

Discussion[]

Creation of a translators group[]

Seen as in the proposal above, those who are against, mainly Chocohead, see that giving it to editors is too "broad" (from what I understood) as they are the first thing that gets voted for as well as translators actually needing it to markup pages and all that and I'm too lazy to write everything but since they said in IRC making it for the translators group is better. -IndestructiblePharaohVII 18:35, 6 March 2017 (UTC)

Support[]

  1. Pictogram voting supportSupport 100^100^100 -IndestructiblePharaohVII 18:35, 6 March 2017 (UTC)
    Ok now this is pointless :P -IndestructiblePharaohVII 12:10, 15 March 2017 (UTC)

Against[]

  1. Pictogram voting opposeAgainst. This should just be part of the editor group. I haven't really been able to vent my views on the subject because Immortal has done most of the arguing (some of his points I may agree with, some I may not) and as a result there's a messy wall of text. I have little to no doubt that giving editors the translation marking right will not cause greater harm than help, nor slow T3, nor produce anything that I am incapable with dealing with. -Xbony2 (talk) 00:04, 7 March 2017 (UTC)
    I know, but Choco and people who opposed said around the words of "Editors are not going to use it and it's hard and all that". So that is just for these people to support. -IndestructiblePharaohVII 17:43, 7 March 2017 (UTC)
    I'm not voting for the last resort if the better option is still in. If it closes I'll consider updating it. -Xbony2 (talk) 00:53, 8 March 2017 (UTC)
  2. Pictogram voting opposeAgainst because your other proposal passed so this is 100% pointless -- SatanicSanta🎅FTB Wiki Admin 23:23, 12 March 2017 (UTC)

Neutral[]

  1. Pictogram voting neutralNeutral Note that translators in general wouldn't need this group. Anyone can translate pages already. This group would only be needed for people that need to be able to mark pages up for translation. If the proposal clarified this and didn't call the group "Translators" but something more fitting, then I would support it. 🐇Retep998🐇🐰Bunny Overlord🐰 18:40, 6 March 2017 (UTC)
    What about "Markup Allowed" or "TransMarkAllowed" or "TransMarkPerms" ? just ideas --sokratis12GR Staff 19:21, 6 March 2017 (UTC)
    You do note that there is a group you like called editors even though anyone can edit (thnx to Santa who said that in the discussion). So should I change the name of the editors group since everyone can edit? -IndestructiblePharaohVII 19:39, 6 March 2017 (UTC)
  2. Pictogram voting neutralNeutral Until I could determine its necessity. T3==ThaumicTechTinker, Urey.S.Knowledge Welcome back, commander 01:23, 7 March 2017 (UTC)
  3. Pictogram voting neutralNeutral I'm not sure why more groups but well... --sokratis12GR Staff 22:43, 12 March 2017 (UTC)

Discussion[]

  • I do not really understand the purpose of this. Are you asking for a translation administrator group (as was removed in the group overhaul) or a "translator" group that actually has the permissions which would be expected for a translation administrator? Anyone can translate so I don't really see the point in this. I guess we have a group called "editor" even though anyone can edit. I don't know. -- SatanicSanta🎅FTB Wiki Admin 19:05, 6 March 2017 (UTC)
    Just a group who has markup rights since anyone can translate maybe a name suggestion or anything but that is basically what my proposal wants to create. -IndestructiblePharaohVII 19:31, 6 March 2017 (UTC)
  • I guess we need to deal with those untranslated articles first? T3==ThaumicTechTinker, Urey.S.Knowledge Welcome back, commander 01:23, 7 March 2017 (UTC)


Splitting up the Armor category[]

I propose that we split up the Armor category into four distinct subcategories:

  1. Headwear
  2. Chestwear
  3. Legwear
  4. Footwear

Currently, we have almost 700 articles in the Armor category. This would make it much more navigable and useful for both editors and for readers. This would not make the Armor category a "top level" category (no articles in it); it would simply serve as a catch for all the articles which do not fit in any of the above four categories but are still considered armor.

What does everyone think? -- SatanicSanta🎅FTB Wiki Admin 20:32, 28 April 2017 (UTC)

How could something be armour yet not fit in at least one of those categories? It's hardly armour if you can't actually wear it. Chocohead NagEditsStaff 20:38, 28 April 2017 (UTC)
There are some pages categorized as armor simply because there isn't a better way to categorize "It armors you from taking damage." For example, an item that you hold in order for it to replicate armor. This really isn't a large set of the pages in there, but it's still worth addressing. -- SatanicSanta🎅FTB Wiki Admin 20:46, 28 April 2017 (UTC)
I second Santa's opinion, as some wearables (great pun there from the ModOff) aren't actually "armor" but more like something you wear. -IndestructiblePharaohVII 20:51, 28 April 2017 (UTC)
Pictogram voting supportSupport There's enough pages of each to warrant their own categories. 100% behind this. --SirMoogle (talk) 23:03, 28 April 2017 (UTC)
Pictogram voting supportSupport Yeah... I'm all about this. --sokratis12GR Staff 17:19, 3 May 2017 (UTC)

FTB Core Team Representative[]

In order to improve communication between FTB and the wiki community, FTB has decided to allow a single member of the wiki community to become a member of the FTB core team. The representative would be responsible for forwarding questions and comments from the wiki community to FTB and vice versa. The representative would not gain any special privileges on the wiki as a result of their position. After discussion with FTB about who they would accept as a representative, they narrowed down the possible candidates to Retep998 and TheSatanicSanta. The choice between these candidates is now up to the wiki community to decide. Remember that the most important characteristics for this role are maturity and the ability to communicate effectively. Writing many articles, while certainly a good characteristic for an editor, is not a relevant characteristic for this role.

Retep998 and TheSatanicSanta have both been part of the wiki for many years with Retep998 joining in April 2013 and TheSatanicSanta joining in August 2013, both longer than any other active editor. They currently serve as the wiki's two bureaucrats. Retep998 is 23 years old while TheSatanicSanta is 17 years old (will be 18 around the time this is finished, though). They are both active on IRC and are online 24/7.: Retep998 is online 24/7 while TheSatanicSanta is online for only part of the day.

Outside of the wiki Retep998 is a prominent member of the Rust language community, regularly taking part in discussions with the community, and triaging issues on Github, even earning recognition as a Friend of the Tree. TheSatanicSanta meanwhile is a volunteer at Democracy at Work, a part of the Portland Assembly, former prominent member of the Portland Ruby language community, and is a key part of the Esteemed Innovation community as the mod and API's primary developer.

This vote will end on May 1, 2017.

Retep998[]

  1. Pictogram voting supportSupport. Voting for myself. 🐇Retep998🐇🐰Bunny Overlord🐰 16:51, 16 April 2017 (UTC)
  2. Pictogram voting supportSupport: Maybe you'll actually do something if you had a role that didn't involve writing :P Chocohead NagEditsStaff 15:49, 30 April 2017 (UTC)

TheSatanicSanta[]

  1. Pictogram voting supportSupport He takes stuff a lot more seriously imo and doesn't get lazy for doing stuff. -IndestructiblePharaohVII 16:54, 16 April 2017 (UTC)
  2. Pictogram voting supportSupport I think I'm pretty cool -- SatanicSanta🎅FTB Wiki Admin 17:09, 16 April 2017 (UTC)
  3. Pictogram voting supportSupport No offense to Retep, but I doubt his commitment to the wiki and ability to advocate for us, at least compared to Santa. Judging from prior commitments I don't really trust him (if he was actively doing something else that benefited the wiki, I'd give him a pass, but he does not appear to be). -Xbony2 (talk) 21:28, 16 April 2017 (UTC)
  4. Pictogram voting supportSupport He's on the wiki often and is quick to bring things up to standard. I see Retep every once in a while but I'm more likely to see SatanicSanta in action. --SirMoogle (talk) 04:34, 17 April 2017 (UTC)
  5. Pictogram voting supportSupport TheSatanicSanta brings the impression of a more serious man than Retep998. — NickTheRed37 (Alisa, do not go to Z’ha’dum!) 15:52, 1 May 2017 (UTC)

Discussion[]

What happens if the result is a draw? Normally it would be up to the bureaucrats to decide the outcome, but that happens to just be both of you. Will there be a dramatic fight to the death to decide? Chocohead NagEditsStaff 17:03, 16 April 2017 (UTC)

Peter and I will play pok-ta-pok; the first person whose hips cannot take it anymore loses. -- SatanicSanta🎅FTB Wiki Admin 17:09, 16 April 2017 (UTC)
Or, it could settle down to an editathon, or a game of chess. Afterall, being good at chess is always a good sign for a good core team :P. -IndestructiblePharaohVII 18:35, 16 April 2017 (UTC)
Or like stated in IRC it will probably be up to FTB/Slowpoke. -Xbony2 (talk) 21:30, 16 April 2017 (UTC)

I'm not super sociable but I see Santa's work frequently while Rep seems to be more in the background code stuff editors are less likely to notice. I have no idea if that's relevant to this in any way but wanna introduce yourself, Rep? Lady Oolong (talk) 18:09, 16 April 2017 (UTC)

Who is Rep? 🐇Retep998🐇🐰Bunny Overlord🐰 18:23, 16 April 2017 (UTC)
you run through my lack of ability to spell :p -- Preceding unsigned comment was added by Lady Oolong (talkcontribs)

Alright, the vote is apparently over. 1 for Retep, 4 for Santa (not including votes of the candidates themselves). Now it’s up to Mr. Slowpoke to let out the decision. And yes, I am back, temporarily.NickTheRed37 (Alisa, do not go to Z’ha’dum!) 14:26, 3 May 2017 (UTC)

Results[]

Vote results:

Peter: 2
Santa: 5

Slowpoke will be adding me to the Core Team next week apparently.

-- SatanicSanta🎅FTB Wiki Admin 04:14, 6 May 2017 (UTC)

Official wiki renaming proposal[]

I propose for the renaming of this wiki from the "Feed The Beast Wiki" to the "Feed The Beast and Modded Minecraft Wiki" (FTB&MM Wiki for short). Originally when this wiki was created, it was purely an FTB Wiki. This is no longer the case. This wiki has been open for all of Modded Minecraft for a very long time, and I think it's appropriate our name reflects that.

Our rival wiki, ftbwiki.org, did something similar to this almost two years when they turned their wiki into an FTB/ATL Wiki rather just an FTB Wiki. However, I think adding other specific modpack names for us would be too exclusive, as there are many more modpacks and mods outside of Feed The Beast and ATLauncher and other popular mod ecosystems, hence why I'm proposing it be "and Modded Minecraft" rather than "and ATLauncher" or "and Technic" or other options.

According to my survey, 44% of our users don't use the FTB Launcher, 75% don't use Curse, and 30% don't use either. For the amount of users who don't use FTB, you can round that number up a fair amount if you consider that Curse (and also the FTB Launcher) don't exclusively host FTB packs. This wiki is marketed as a "Feed The Beast Wiki", even though it's more of a general Modded Minecraft wiki. Like I've said, we've been very welcome to the documentation of mods outside of FTB for a long time, and I think it's important we reflect that to potential editors and viewers that may not think of us as that.

Lastly, this allow us to do a proper "merge" with Modpedia, which is something that has been discussed in IRC and the Gamepedia Slack for a while but hasn't been done yet.

To clarify, this is a request to change the website name and how we refer to it. This does include this namespace (we'll probably make "Feed The Beast Wiki:" redirect to "Feed The Beast and Modded Minecraft Wiki:") and how the name will display in certain places (like the "wikis" section of the Gamepedia main page) However, I do not want to change the url of this wiki and the location of the main page (although I would like to update as well as improve the main page). -Xbony2 (talk) 13:53, 5 November 2016 (UTC)

I don't like to change the name since it is too long (that is my first opinion without thinking much about that subject). -IndestructiblePharaohVII 14:07, 5 November 2016 (UTC)
I noticed that too, but it's not like "Feed The Beast Wiki" is already pretty long. You can still call it the FTB Wiki, or the FTB&MM Wiki, or the Modded Minecraft Wiki, or whatnot, it's just that we'd refer as the Feed The Beast and Modded Minecraft Wiki formally. -Xbony2 (talk) 14:23, 5 November 2016 (UTC)
I have no problem with changing the wiki name, however I'd strongly prefer something that isn't too long. Also, we'd need to have it approved by FTB to make sure they're okay with it. 🐇Retep998🐇🐰Bunny Overlord🐰 15:37, 5 November 2016 (UTC)
We should be either FTB/Feed The Beast Wiki or MM/Modded Minecraft Wiki, not both. Also what Peter said about talking to FTB (mainly Slow, Quetzi, and Tfox). -- SatanicSanta🎅FTB Wiki Admin 04:32, 6 November 2016 (UTC)
Combing them both allows us to still have a focus on FTB while at the same time not being exclusive. I don't see why it has to be either or :P I do get that it's rather long, there's not many wikis that we can compare with. It's worth investigating if we can use something smaller, like "Feed The Beast Wiki and Modpedia", but I don't really like the sound of that. -Xbony2 (talk) 10:17, 6 November 2016 (UTC)
Probably more like Feed The Beast and MineModPedia Wiki? (I know I am good with coming out with names :P). IndestructiblePharaohVII 07:10, 8 November 2016 (UTC)
That sounds rather silly :P -Xbony2 (talk) 12:00, 8 November 2016 (UTC)
I'm just curious about why do we even consider a merge on a wiki that has ~200 articles (compared with the 13k articles on here), and the last edit was made about two weeks ago. On the other hand, I don't agree that the wiki should cover all the mods for minecraft, as there's problems even covering the ones that already are available on FTB alone, such as forestry or Thermal Foundation are kind of outdated, with no mention on popular but not so complex mods such as Extra-utils or decocraft, that integrate most of the official Modpacks of FTB, but yet we don't have pages for their mechanics or items that come with them. Frenchiveruti (talk) 01:56, 13 November 2016 (UTC)
We already DO aim to cover all mods for minecraft. That's kind of a pillar of this wiki, although FTB is somewhat of a focus (or it should be, ultimately people document what they want to). We're never going back to the dark ages of being only FTB :P Anyway, the reason I want to merge the Minecraft Modpedia with here now, even though it's tiny, is because it would very much easier to do now, while it is easy to do and small, instead of when it has a large content base, since it would be very complicated to do so then, which could potentially happen if we don't do this now. -Xbony2 (talk) 02:22, 13 November 2016 (UTC)
It's worth noting "merging" at this point basically means making the entire wiki redirect to this wiki, since there's no content worth moving over :P -Xbony2 (talk) 02:24, 13 November 2016 (UTC)
I see, well, what about if instead of naming "and modded minecraft" FTB, like separating the terms, we integrate the fact that the modded minecraft experience it's intrinsic to FTB, as Modded minecraft probably wont be able to distribute its mods in other platform that it isn't curse. Just to be clear on what I mean, FTB IS modded minecraft, but modded minecraft isn't necessarily FTB as there are mods that don't form part of FTB official packs. Frenchiveruti (talk) 02:41, 13 November 2016 (UTC)
Not entirely sure what you mean :c -Xbony2 (talk) 12:57, 13 November 2016 (UTC)
For the record both DecoCraft and Extra Utilities have some very basic documentation here. I started DecoCraft a while ago, but it was really redundant and boring so I stopped. ExU was being documented by someone who I can't remember off the top of my head. -- SatanicSanta🎅FTB Wiki Admin 18:08, 13 November 2016 (UTC)
It was Warlordjones, although other users have contributed a bit here and there. Currently nobody caries that torch, although I might aim to document Extra Utilities 2 since it's very different. -Xbony2 (talk) 20:42, 13 November 2016 (UTC)

Wiki renaming proposal 2[]

Yes, I'm going to revive this proposal. Most of you guys opposed the original on the account of it being too long. Although, I have another opposition to add of my own- being FTB-focused. If we were, say, going to collaborate with another major modpack, they might not want to be under that banner. Not saying I have something planned, but who knows what is in store for the future? Anyway, that's why I propose this wiki be renamed to the "Modded Minecraft Wiki". It's short. It's direct. And it doesn't hurt that it might be the first thing that comes up when you google "modded minecraft wiki" :P certainly is pretty marketable.

Anyway, just to extend this a little bit, I'd like to propose a little something more. To keep the FTBness of this wiki, I'd like to suggest the addition of a "Portal:" namespace. The main page we currently use would be moved to "Portal:Feed The Beast". Potentially there will be other portals too- I definitely have "Portal:ATLauncher" and "Portal:Technic" in mind, but there's also potential for portals for specific mods or maybe other future concepts. The regular main page would include a blurb about modded minecraft, a few links to the main portals, and an expanded mod list. I'll try to make a conceptual version in my userspace I suppose. -Xbony2 (talk) 22:36, 21 January 2017 (UTC)

I don't know if I have any say in this but here are my two cents anyway. I discovered this wiki (well, I discovered the unofficial one first) not because I was playing an FTB pack (it was an unofficial technic pack), but because I was playing with a mod that I wanted to learn more about. What was the first thing I found when searching for that mod or item in the mod? These FTB wikis. They generally seem to come up as the only wikis pertaining to Modded Minecraft unless the mod itself has a wiki of its own. I feel like this renaming would take that extra step to place the wiki in the spotlight of the Modded Minecraft community forever. Crazierinzane (talk) 23:52, 21 January 2017 (UTC)
I am personally fine with the name "Modded Minecraft Wiki". I really do not want to name it "Modpedia" (Benjamin mentioned that in a private convo I had recently; that name sucks). We have to talk with the Gamepedia people (really we should just talk to Benjamin about it). Benjamin said he would "put out some feelers and try and get some info from within Curse" and the Curse people that work with the core FTB team. We also have to discuss this with Slow though I doubt he'll care one way or the other. I can do that if you don't want to. -- SatanicSanta🎅FTB Wiki Admin 00:54, 22 January 2017 (UTC)
I really have no idea what to expect from slowpoke or the FTB team. It would be good to do it as a team (multiple people arguing can create a very good persuasive effect), but if you don't think he'll get in the way you can take care of it. -Xbony2 (talk) 01:48, 22 January 2017 (UTC)
It's hardly like they're very attached to the wiki, we're very infrequently mentioned (if at all by FTB itself). It's not even like we even focus on documenting the mods that are in FTB packs anyway. Chocohead NagEditsStaff 02:03, 22 January 2017 (UTC)
I probably would document their mods if they ever gave a shit about us. We've never been mentioned in their news (even when I explicitly told them every time we had newsworthy shit happen), and none of the important things I've requested (giving us easy access to up to date MineTweaker scripts without having to download their entire modpacks, attempting to get editors, etc.) have ever been done. -- SatanicSanta🎅FTB Wiki Admin 02:07, 22 January 2017 (UTC)
We'll still serve as the Official FTB Wiki, it's just that we'll be more :P -Xbony2 (talk) 02:09, 22 January 2017 (UTC)

A new main page might looks like this, btw. Obviously I'm not a web designer, but you can at least get the idea. I'd like it if the links at the top were images instead of just text, but maybe that can be done later. The main portals put forth are "ATLauncher", "Feed The Beast" and "Technic", the most biggest modpack groupings. I wouldn't add any more, unless something else becomes especially popular in the future or if we partner with someone. -Xbony2 (talk) 04:02, 22 January 2017 (UTC)

[]

If we're going to rename and remarket our wiki, we're going to need a new logo. If anybody wants to play around and design something, go ahead and throw it here :P -Xbony2 (talk) 01:08, 30 January 2017 (UTC)

Give me a general theme/concept and an idea of what sort of color scheme you'd like to see, and I'll see if I can cook something up. Do need at least some starting point for an idea from the rest of you. DSquirrelGM𝓣𝓟𝓒 02:48, 14 February 2017 (UTC)
Well, since I can't seem to get any suggestions on the logo, let's try a different approach... Which of the following ideas would you prefer to see?
  1. Design based on an anvil with text stamped or chiseled into it
  2. A representation of various production machines stacked side to side or staggered like stairs
  3. Command block as a background with various tools and weapons in the foreground
Or suggest some alternative based on these suggestions. DSquirrelGM𝓣𝓟𝓒 03:49, 16 February 2017 (UTC)
All my ideas involve rabbits. 🐇Retep998🐇🐰Bunny Overlord🐰 03:46, 16 February 2017 (UTC)

There's been some concerns about the lack of a logo, but have no fear. This will be our new logo henceforth.

Clay logo

-Xbony2 (talk) 16:30, 1 April 2017 (UTC)

eat my ass xbony you made my dog have a nightmare with that image -- SatanicSanta🎅FTB Wiki Admin 20:43, 1 April 2017 (UTC)

These were created by Drullkus. You can click them for a bigger picture. -Xbony2 (talk) 20:40, 10 April 2017 (UTC)

This is completely serviceable but also completely un-Minecrafty. My thought is that below the underline, maybe the icons of some iconic modded blocks could be arranged. Alternately, work the Forge logo/loading screen icon in somehow. Lady Oolong (talk)

Renaming the wiki to the "Modded Minecraft Wiki" vote[]

I think everybody agrees with it (or doesn't care), but because it is a big change, I'd like to do this the formal way. This vote is on renaming and remarketing the wiki from the "Feed The Beast Wiki" to the "Modded Minecraft Wiki". Keep in mind this not a change in policy- this wiki has long been more of a general modded Minecraft, and it's allowed for non-FTB mods for years now. A large amount of our users don't play FTB modpacks at all, and I'd say most of our editors don't either. This change should allow us to be more marketable to potential editors and partners who don't want to be under the FTB banner. For a bit more on that, go through the #Official wiki renaming proposal discussion and #Wiki renaming proposal 2 discussion. This vote will end in one week. If passed, we'll send a message to Gamepedia to proceed.

Support[]

  1. Pictogram voting supportSupport. -Xbony2 (talk) 10:06, 4 February 2017 (UTC)
  2. Pictogram voting supportSupport. Then no problem with that :P -IndestructiblePharaohVII 10:36, 4 February 2017 (UTC)
  3. Pictogram voting supportSupport. --sokratis12GR Staff 10:48, 4 February 2017 (UTC)
  4. Pictogram voting supportSupport. -Moritz30German translator 18:52, 5 February 2017 (UTC)
  5. Pictogram voting supportSupport I spoke with Benjamin from Gamepedia a while ago and he says the Gamepedia folks support the change. It would require a complete overhaul of the main page, which Benjamin briefly described in private with me. Slowpoke also supports it, basically as long as we don't document the Jadedpacks– fortunately those were never intended to be documented here, but instead to just link straight to Jaded's wiki. It should be stated somewhere on the main page that we are still the official source of information on FTB content, though. I propose we change the name of the wiki to "Modded Minecraft Wiki" and the URL to "moddedmc.gamepedia". Once this is all done (as in, the wiki is renamed and the main page is redesigned), we can begin working with Lordofediting and the rest of Gamepedia to transfer any content from modpedia that was not copied from here over here, and then deprecate/delete that wiki to prevent segregation. -- SatanicSanta🎅FTB Wiki Admin 19:13, 6 February 2017 (UTC)
    *cough* sample-ish main page here.
    I want to argue against the subdomain "moddedmc.gamepedia". "MC" just seems like a shitty partial abbreviation. Maybe "moddedminecraft.gamepedia" (15) is long, but it wouldn't be the longest subdomain- pillarsofeternity.gamepedia.com (17), totalwarwarhammer.gamepedia.com (17), strongholdkingdoms.gamepedia.com (18), orcsmustdieunchained.gamepedia.com (20), civilizationbeyondearth.gamepedia.com (23), everybodysgonetotherapture.gamepedia.com (26), legostarwarstheforceawakens.gamepedia.com (27), loversinadangerousspacetime.gamepedia.com (27) to name a few. Other alternatives could include "mm.gamepedia.com" if we wanted to go short, maybe "modminecraft.gamepedia.com"? (I really don't like that one tho) -Xbony2 (talk) 22:29, 6 February 2017 (UTC)
    I think all of those URLs you proposed are ew. Perhaps we should see what Gamepedia people think? -- SatanicSanta🎅FTB Wiki Admin 02:54, 7 February 2017 (UTC)
    Aye, and/or if anybody else has any ideas. I'm learning towards "mm" myself, although I will admit I am not 100% satisfied with that option either -Xbony2 (talk) 11:54, 7 February 2017 (UTC)
    I'd lean towards moddedminecraft.gamepedia.com. CrsBenjamin (talk) 17:24, 17 February 2017 (UTC)
  6. Pictogram voting supportSupport. Slowpoke is okay with it, Gamepedia is okay with it, therefore I am okay with it. 🐇Retep998🐇🐰Bunny Overlord🐰 21:53, 6 February 2017 (UTC)
  7. Pictogram voting supportSupport I'd lean more towards "minecraftmods.gamepedia.com" for domain name. DSquirrelGM (talk) 17:35, 7 February 2017 (UTC)
    I don't think "minecraftmods" is all that accurate because we document, and plan to document, quite a bit more than just mods. -- SatanicSanta🎅FTB Wiki Admin 18:00, 7 February 2017 (UTC)
    True. I thought about that name myself, although I didn't suggest it because it doesn't match the name of the wiki as a whole (Modded Minecraft Wiki), which I think is important. -Xbony2 (talk) 21:07, 7 February 2017 (UTC)
  8. Pictogram voting supportSupport T3==ThaumicTechTinker, Urey.S.Knowledge Welcome back, commander 23:00, 7 February 2017 (UTC)
  9. Pictogram voting supportSupport. Good idea ! --LuminousLizard FTB Wiki Staff de-N / "en-2" (talk) 18:15, 24 February 2017 (UTC)
  10. Pictogram voting supportSupport Why the hell not? LordofEditing =(Talk)= 21:20, 5 March 2017 (UTC)

Neutral[]

  • I'd rather we confirm whether FTB peeps are okay with this before making a decision here. 🐇Retep998🐇🐰Bunny Overlord🐰 21:08, 4 February 2017 (UTC)

Against[]

  1. Pictogram voting opposeAgainst Slowpoke is against it, therefore I am against it. 🐇Retep998🐇🐰Bunny Overlord🐰 14:39, 12 April 2017 (UTC)

Discussion[]

Would we still be the Official FTB Wiki? Meaning that we are still FTB's official wiki? -IndestructiblePharaohVII 10:32, 4 February 2017 (UTC)

Yes (unless they change their mind, but I doubt that they will be dicks about it). -Xbony2 (talk) 10:34, 4 February 2017 (UTC)
I still have not talked with slow or tfox or anyone high up in the FTB bureaucracy about it. Bony did you or are you just assuming they'll be fine with this? -- SatanicSanta🎅FTB Wiki Admin 21:03, 4 February 2017 (UTC)
I am saying if they do not agree that it will not be their call. Nowadays, they don't host us or manage us any more than Microsoft does the Minecraft Wiki. Now, I don't want to be a jerk to them, but we will be jerks if necessary. But I don't think we'll have to. -Xbony2 (talk) 21:36, 4 February 2017 (UTC)
And an update on this- slowpoke has stated he is okay with this, as long as we generally focus on FTB modpacks (which I generally plan to do), and also that we don't include modpacks that contain mods without consent from the mod author(s) (with a few exceptions for the historical Technic packs), which I think is reasonable. -Xbony2 (talk) 23:10, 4 February 2017 (UTC)
What about creating a new wiki as modded Minecraft wiki? -Moritz30German translator 18:54, 5 February 2017 (UTC)
Sure, take all the years of hard work and start over at a new wiki. -IndestructiblePharaohVII 18:57, 5 February 2017 (UTC)
Maybe one could copy articles over but I think this wiki should still be focused on FTB modpacks and not small mods. Documenting small mods is good, however I don't think it should take place in a large scale here. This wiki is optimized for FTB modpacks and large mods but not really for small ones. -Moritz30German translator 19:07, 5 February 2017 (UTC)
Creating a new wiki just segregates the community even more, makes it a royal pain in the ass for users to find documentation, and doesn't even make sense because we've already been documenting non-FTB mods for at least a year. The wiki isn't "optimized" for any specific set of mods; it works fine for any number of mods. -- SatanicSanta🎅FTB Wiki Admin 20:01, 5 February 2017 (UTC)
It's optimized for all the mods \o/ -Xbony2 (talk) 02:33, 6 February 2017 (UTC)
BTW what will happen with the old existing links and pages that linked to this site ? will the other URL redirect them here ? --sokratis12GR Staff 12:11, 7 February 2017 (UTC)
If the url is changed, the old url will redirect to the new url. Links will not be broken. 🐇Retep998🐇🐰Bunny Overlord🐰 12:20, 7 February 2017 (UTC)

Final Decision[]

This has been supported unanimously. It'll take a while to fully update everything, and for Gamepedia to do their part. In the meantime, we can probably work on making some base documentation on other modpacks or making new portals or whatnot. Also above this, we need to decide on a logo (I really don't like Modpedia's logo, no way we're going to be using that) and other stuff. -Xbony2 (talk) 17:12, 11 February 2017 (UTC)

Here's a list of things that need to happen:
  1. Decide on Wiki Name
    This seems to have consensus as "Modded Minecraft Wiki"
  2. Decide on URL
    There seems to be some discussion, but best practice would be to use the wiki name, so moddedminecraft.gamepedia.com
  3. Create a logo
    I can get assistance from Curse's design team if its necessary, with about 1 week lead time. But there would need to be a fairly clear idea of what was wanted.
  4. Mock up new main page
    I think someone had started on this, but happy to get some help from our wiki team as well if its desired.
Once all of these things are ready, then we can set a date to make the changes, which we'd be happy to support via social media, etc. We're excited about this. Even though the wiki has covered mods of all varieties for some time, I think this change will be a great move towards making it really clear what the project's mission is. We get not infrequent requests for wikis for minor mods, and its been a little confusing to people sometimes for us to send them to "FTB Wiki". CrsBenjamin (talk) 17:31, 17 February 2017 (UTC)
CrsBenjamin- I'd rather not set a date currently so we don't have to rush. I'd like to work a bit more on making a few pages to bind everything together before calling one. By the end of the month is entirely possible, though. -Xbony2 (talk) 22:38, 18 February 2017 (UTC)
Sorry for the late reply. But yeah, definitely no rush, I just mean once everything is ready we'll want to coordinate. CrsBenjamin (talk) 17:04, 24 February 2017 (UTC)

When two items are merged in one[]

Ender IO in 1.10 has removed Redstone Conduit and given what used to be Insulated Redstone Conduit (the version that handles bundled redstone channels) that name. What's the correct way to handle the pages? Lady Oolong (talk) 17:05, 26 February 2017 (UTC)

Sorry for the late reply. Chocohead described the solution in the Gamepedia Slack
Different sections for different versions most likely

The page would describe the latest logic then have a section below it describing legacy

-Xbony2 (talk) 22:11, 26 February 2017 (UTC)

ModOff[]

FTB Wiki at ModOff

Me and ImmortalPharaoh7 are representing the FTB Wiki in ModOff! In case you don't know what it is, ModOff is a modding competition where participants are tasked to make a mod in a 5 day period (similar to ModJam). Me and Immortal, and any other interested editors, are sponsoring the event by documenting the top three mods from it (plus any mods we particularly like, of course). On April 26th to 30th, the ModOff server will be opened for modders to display their creations and for viewers to vote on which one(s) they like the the most. We have our own plot as well, as you can see above, and I highly encourage you to visit it. On May 1st, the results of the competition will be released (it's also my birthday too btw), and me/Immortal/any interested editors will start documenting the top three mods shortly after. -Xbony2 (talk) 20:25, 24 April 2017 (UTC)

Update: it is open currently. Support the wiki and the event by coming out, yo :P -Xbony2 (talk) 11:30, 26 April 2017 (UTC)
Update- if you're interested you probably already know anyway, but the winners of Modoff are Wearables, Skillable and Augmented Interactions. And just for funz here was a picture from the event.

FTB Wiki at Modoff

(ImmortalPharaoh7 took this one I believe which is why his name is missing) -Xbony2 (talk) 21:08, 3 May 2017 (UTC)
lol, I had no idea a picture of me was ever taken. Nice. I wonder if Tartaros was ever fixed... -- SatanicSanta🎅FTB Wiki Admin 21:48, 3 May 2017 (UTC)
Pretty sure you were lagging there, and right after the picture was taken, you left the game. -IndestructiblePharaohVII 14:25, 11 May 2017 (UTC)

Mod and modpack contest categories[]

I just had a thought. It could be useful to create categories for mods and modpacks made as part of a contest, for example "Mods created for Modoff". If nobody opposes I can just do it since I don't think it's controversial enough to need a full scale vote. -- SatanicSanta🎅FTB Wiki Admin 16:06, 5 May 2017 (UTC)

I was thinking about something like that. I don't know if we should use specific "versions" of competitions in categorization, though (like "Mods created in ModJam 1" vs. "Mods created in ModJam" or use both at the same time [which I would prefer]).
I wouldn't recommend even bringing up voting for this or anything else that isn't super huge anyway. -Xbony2 (talk) 00:25, 6 May 2017 (UTC)
Alright, so I've done this. Unfortunately, ModJams have been horribly documented so the only ones I know of for each ModJam are the very popular ones (iChun's mods and Translocators). I've asked both Searge and iPixeli on IRC about getting a list of each ModJam's submissions, which could also be helpful for finally creating ModJam articles. I've also asked Slow for a list of all JamPacked submissions. -- SatanicSanta🎅FTB Wiki Admin 02:26, 6 May 2017 (UTC)

Ore Dictionary Requests[]

It's my first time... Is this the right place for this? Did I do this right? storagedrawers Thanks! Andyglover (talk) 18:45, 19 June 2017 (UTC)

Yup, perfect, thanks. I've been meaning to dump this mod. Done. -- SatanicSanta🎅FTB Wiki Admin 01:14, 20 June 2017 (UTC)
Sweet. My pleasure. Just realized I did make one typo in my submission: "Basic Drawers 1x2(Spruce)" should be "Basic Drawers 1x2 (Spruce)". Sorry about that. Here's an updated txt if you need it: storagedrawers -- Preceding unsigned comment was added by Andyglover (talkcontribs)
I updated it manually. Be sure to always include a signature using ~~~~ when communicating :) -- SatanicSanta🎅FTB Wiki Admin 15:59, 20 June 2017 (UTC)

Railcraft 10.1.2 Thanks! Andyglover (talk) 04:15, 21 June 2017 (UTC)

This dump was somehow compressed into 4 lines. Could you upload the raw dump as provided by OreDictDumper without alteration? Thanks -- SatanicSanta🎅FTB Wiki Admin 05:10, 21 June 2017 (UTC)
RC.txt Sure, here you go. Sorry about that! Andyglover (talk) 06:21, 21 June 2017 (UTC)
Done -- SatanicSanta🎅FTB Wiki Admin 17:45, 21 June 2017 (UTC)


Death to Category:Mod categories[]

I don't think this will be very controversial but it is somewhat large. Anyway, I propose the deletion of Mod categories. It was somewhat useful when minor and major mods were separated, but now all mod categories are subcategories of Mods so it's pretty useless. -Xbony2 (talk) 22:46, 20 July 2017 (UTC)

Definitely agree. I've been meaning to bring this up. -- SatanicSanta🎅FTB Wiki Admin 01:41, 21 July 2017 (UTC)
And I deleted it. -Xbony2 (talk) 15:59, 29 July 2017 (UTC)

Discord[]

Chances are everyone who would read the CD already saw this mentioned in IRC (except Retep since he's in the woods), but we now have a Discord server here. This is bridged with the IRC, so if you don't like Discord or don't have it (...you're missing out, the modded community is very active in various servers) you can continue to use IRC (and we will have to in order to access our bots, for the time being). I also put it in the sitenotice because why not. -Xbony2 (talk) 16:41, 1 August 2017 (UTC)

Capitalising "vanilla"[]

As Xbony2 has noted, there's no official decision on whether or not "vanilla" should be capitalised in sentences. As it is not an official MojangTM term, I say it should be kept in all lowercase as a standard adjective. --SirMoogle (talk) 04:21, 24 September 2017 (UTC)

Support[]

  1. Pictogram voting supportSupport For reason listed above. --SirMoogle (talk) 04:21, 24 September 2017 (UTC)
  2. Pictogram voting supportSupport I know I'm late to the discussion but hey! Those are internet times! --Frenchiveruti (talk) 17:35, 12 October 2017 (UTC)

Against[]

Discussion[]

I've seen it both ways across the community (capital, like here, here, here, etc.... and not capital, like here, here, here, etc....). It could be argued that "vanilla" is used as adjective, or it could be argued that it's part of the name, even if it is an unofficial name. But I would argue that it mostly comes down to aesthetics. For this reason, I'd like to have a "community referendum": a simple poll put on Reddit. If no one objects I'll set up one soon. -Xbony2 (talk) 13:23, 24 September 2017 (UTC)

That's a good idea. Be sure to blast it on Twitter, IRC, and the FTB Forums though because Reddit is not representative of the community. -- SatanicSanta🎅FTB Wiki Admin 23:27, 25 September 2017 (UTC)
As it isn't an official term I wouldn't capitalize it. Also, I only go to reddit as an asbolute last resort, the searching, organization, and verification, there is horrible. DSquirrelGM𝓣𝓟𝓒 01:57, 29 September 2017 (UTC)
I don't think we need to bombard every corner of the internet for something so minor; I am highly skeptical different portions of the community would have inherently different opinions over this matter. Here is my Reddit post (or skip to the strawpoll here). You can share it elsewhere if you want to. Haven't had any issues with Reddit. -Xbony2 (talk) 13:57, 29 September 2017 (UTC)
Update: "vanilla Minecraft" (uncapitalized) won by about three votes after angry grammaticans stormed the building. Unless anyone is opposed I'm going to add using "vanilla Minecraft" in the style guide and fix it in places. -Xbony2 (talk) 22:57, 5 October 2017 (UTC)
And all is right with the world. 👍 --SirMoogle (talk) 18:16, 12 October 2017 (UTC)
One argument for it was 4000 characters which to me was quite reactionary for an extremely minor spelling difference in a website the one arguing had little to do with x.x -Xbony2 (talk) 22:36, 12 October 2017 (UTC)
I assume you're referring to this one. --SirMoogle (talk) 22:40, 12 October 2017 (UTC)

BTM Moon[]

We are at BetterThanMinecon with a booth: https://i.imgur.com/EG0JZOS.png (would host on wiki instead of imgur but image stuff is broken, so sorry). Come and visit my little booth! -Xbony2 (talk) 00:31, 18 November 2017 (UTC)

Advertisement