Spreading too thin

[LogicParrot]

Expending disproportionate effort on trivial matters is known as bikeshedding, or Parkinson’s Law of Triviality, and I feel the community, myself included at times, often does just that. The intention of this post is constructive criticism, no disrespect intended.

Cuberite has quite a few essential missing features at the moment, and I believe things like imporving stability, polishing the Lua API, imporving entities, mobs, documentation, 1.10 block support, etc should be the top priority.

But brain-power is often being spent on far less important discussions or features such as YAML support, turning Cuberite into a library, implementing complicated optimizations, Integrating Redis, building a plugin repo, overhauling the admin web API with javascript, adding Javascript, Python, or LuaJIT support, etc.

Fortunately little to no code has been written for most of these ideas yet (with the exception of the repo and the smart chunk solution). But I just wanted to remind the community that while new cool features are nice, in my opinion, we should prioritize becoming on par with Bukkit in all the essential aspects, and we shouldn't spread too thin.

[xoft]

I agree, though on the other hand, it's good to talk about those issues (and vent them out), just so that someone doesn't go and spend so much time implementing something on those lines, only to be rejected because most other people don't like it / have a better idea. As long as the talking is on topic and not too time-consuming.

We are spread quite thin already, but that's pretty normal with open-source programs and voluntary work. Most of us, if not all, joined the project with some vision, wanting to do something. And either we manage to do that, or we don't; but there's no way anyone can be forced to touch a part of the code that they don't want to touch. I'm pretty sure I won't be touching any redstone-related code anytime soon. Similarly, most people don't want to bother themselves with the Lua API details, or optimizing memory usage. To each their own. We can only hope to spark interest in more new people, so that they join us with their new additions to our work.

[yangm97]

I think someone said Cuberite developers had their own personal to-do lists. What about turning them into GitHub Projects? Also, adding priority tags to issues could do something. Setting priorities would be nice too. Do we all agree Cuberite needs to be feature complete asap or should we instead focus on things Cuberite would do better? Like that Lobby API for minigames. I myself use both Cuberite and Spigot on my server, it’s not unthinkable other people would do that too, thanks to bungeecord. EDIT: Cuberite can already be a god damn good lobby and login server! Only missing bits IMO are:
- Login plugin that stores data on MySQL with bungeecord and spigot support (maybe creating a AuthMe drop in replacement would work);
- Good Looking Portal plugin that teleports to other bungeecord servers.

xoft is right about the project needing more developers though. I know I can (and have done) a Dockerfile for Cuberite. I know I can (and am going to) make another webadmin interface for Cuberite. I report things I, as an end user, think are issues. Still, none of that would make Cuberite more feature complete against vanilla, but that’s what I know how to do. 

On an unrelated note, I've chosen to learn programming in C++ so that maybe someday I could help Cuberite 

[sphinxc0re]

I agree with all of you. I also think that if we want to get a little bit more serious about this project that we should start organizing and prioritizing issues so that we can easily distinguish between easy and hard, important and unimportant. That would mean putting issues into GH projects but also touching the messy labels. I like how ruma manages their labels: https://github.com/ruma/ruma/labels

[LogicParrot]

Let us discuss this here: https://forum.cuberite.org/thread-2801.html

[omboner44]

Ok, then let's do this there

[tigerw]

And don't forget the spaghetti monster that is #3115.