The 80/20 rule and Low hanging fruit farming

Everyone knows about the 80/20 "rule" in software development. Thoughtful people also know why it is not a rule per se, but that it has some truth in it: a prototype demonstrating most desired features can be realized in a short amount of time, compared to the time it takes to polish the product, ie. handle errors and all the special cases.

For as long as I can remember, ZK has been an unfinished product. It is a product that you can use, a product providing features (fun, lazors and explosions). But it has a lot of already discovered bugs and a lot of bugs waiting to be discovered. In other words, it is not polished. And if I remember correctly, the goal is to greenlite the game, which require some polishing. Unless you want to cope with the justified backlash of angry players getting a product that had known defects at release time.

So now, there is this difficult phase where the last features and the last bugs have to be fixed and where scalability becomes important (because it costs money). This is the phase that takes "80%" of the time for "20%" of the reward. In other words, a phase where the reward/work ratio is not as good as when you add new feature that amazes players (for a week, until they figure it is broken and the code gets commented or just not used).

How do you intent to incentivize contributors (everyone) to swallow the bullet and fix the open bugs, instead of adding new features that briefly amazes the players, ie. farming low hanging fruits? How to get new developers for hard tasks?

Currently, it is clear that large portions of the code are unmaintained and that nobody is taking care of issues reported by users or other infrastructure people, not without consequences. Take the recent episode of lobby server disconnections, the problem was reported, but nobody took care of it, with important consequences (spring migrating, more latency, potentially more network problems) and a lot of very angry players.

Let's posit that we can not blame anyone for these bugs, since ZK is run by volunteers. In the ZK project, nobody is responsible for sub-projects or functional areas. Nobody is responsible for triaging issues and making sure they are fixed before new features are added. Known bugs gets forgotten, remain in the code until someone waste time trying to figure why autohosts do not start or whatever. When players report a bug, it gets announced in #zkdev. It doesn't mean someone will look at it, and it clearly doesn't mean the bug will be assigned to someone and will end up in some to-do or get a task priority.

#zkdev has been cultivating this "fix it yourself" attitude. I suspect it is simply because they are like everyone else, they want a high reward/work ratio in their free time hobby. The veterans expect newcomers to join the project to fix the bugs and handle the special cases, a tedious and not very rewarding task that require intimate knowledge of the system.
And wannabe contributors, do you think they really want to do the hard part of the job of someone who already switched to another new funny prototype project? At some point, you have to face reality... it is not an appealing proposition.

In other words, there is no incentive to fix bugs or to spend the time needed to tackle harder issues that "my icon is too small" or "we need a color picker in lobby". There is already a list of 50 open bugs in the new github bug tracker and a large amount of bugs that have simply been forgotten in the previous bug tracker.

I'm trying to bring in the idea of project management, because I feel that a lot of effort is wasted, I know that a lot of money is burned on misused hardware (and more will be), and I'm afraid a lot of time and opportunities are lost. The size of the code in the repository is growing at a fast pace, if we believe the graphs. So do bugs.

Is the project getting closer to a greenlite-compatible quality level? It feels like zeno's path at the moment.

Before discussing suggestions... do people agree the observations?

The migration to github, at least, seems to me like a massive recent-ish improvement. Especially for the game part of ZK, and for making stable versions of it. Having the core devs act as uncircumventable gatekeepers is the kind of quality control element that was sorely needed.

Of course, sheep still raises valid points. Kudos for bugfixes?

if somebody did tell a newcomer to fix something, it's probably out of the "we don't see this as a major problem, but if you feel it's so dreadfully broken feel free to try to fix it yourself" than a "well what are you waiting for? you've been here 2 days now so start fixing everything for us so we don't have to!" manner.
(and indeed if we changed everything every time one person complained about it, we'd be perpetually disrupting everyone and having instability instead of satisfying most and only bothering a few)

What's bad is when important issues are not seen as major problems.

Take Nightwatch: it has full control over the server; can appoint and recall Spring and ZK admins at will; can set the required Spring version for other games; it can ban, kick, has control over chat channels and whatnot. At the same time it is also a crucial piece of ZK infrastructure that handles offline messaging, channel security, punishments, various notifications, the Planet Wars matchmaking, and probably more.

Was it seen as an issue that its password was publicly available in plaintext?

quote: [23:14] Licho so you found exploit and FORCED others to fix that? [23:14] Licho because you dont like that? [23:14] Licho how stupid is that? [23:14] Sprung what was i supposed to do? [23:15] Licho fix it yourself [23:15] Licho or nothing [23:15] Sprung if someone else abused it, it would be much worse [23:15] Licho its like, hey i told you 3x you should lock your front door [23:15] Licho so i broke in, smashed some windows, stole your stuff [23:15] Licho now you had to fix the lock and use keys [23:16] Sprung i didnt actually break anything [23:16] Licho if someone else abused it it would be much worse! [23:16] Licho this is pure idiocy sprung [23:16] Licho and there is no excuse for that [23:16] Sprung alright, fine [23:16] Sprung just that else noone would do anything [23:16] Licho and why should they if there was no problem [23:16] Licho you created problem because it might be a problem in future [23:16] Sprung NW password being available plaintext is not a problem? [23:16] Licho apparently it wasnt until now [23:17] Licho in civilized countries people dont steal stuff that isnt locked

For clarity, my abuses were:
1) applied all possible forms of adminhood to self and Anarchid (so far I retained Springie rights).
2) made a silly forum post as NW.
3) had NW join the SPRUNG clan.
4) made fun of KR.

(I'm being facetious of course - please don't take that seriously)

On a serious note:
I agree with your observations [V]sheep, but I think your conclusion is hopeless. Basically there needs to be incentives. I don't think there is any viable+helpful way to add incentives.

At least, I can't personally be incentivized to do a single damn thing. I will only do work that I find to be rewarding in its own right.

When I first started working on BA, it was to fix longstanding bugs. When we first forked CA, it was to add features, but it also allowed us to fix a lot of longstanding bugs. Little consistency errors, wreck values being higher after being crushed, script errors, et cetera. Lavishing loving detail on weapon effects and adding consistency and polish.

I don't have the time and energy I used to. I think that's true of a lot of the devs. But we have spent far, far more time on logistics and bug hunting and making sure everything runs smoothly, the 80%, than you can possibly imagine. Most of the time when we knock back proposals from new developers or contributors who are more big on ideas than implementation, it is because of all the effort required to make sure it runs smoothly. We spend more time cleaning up and fixing bugs while rejecting new, potentially buggy proposals than we do implimenting new ideas.

Slowly lavishing love on all the tiny bugs and inconsistencies and messiness in the game that you so enjoy and bringing it all together can be very rewarding. All the current developers would have given up if they didn't find that rewarding. What we need is new developers with that same mindset.

Personally the thing I find most demoralizing is the abysmal state of the engine. I can't be bothered fixing tiny script errors when the engine runs so badly and new versions just get worse.

Yogzototh thats why we should abuse maces and ravens more. A lot more!

sprang github is a step in the right direction. But it didn't change much. I don't think a developer see kudos as a reward, but maybe we can get players to help with finding a systematic way to reproduce a bug, maybe that would deserve kudos

Yogzototh the exact same thing happened to me... it is not an exception, it is the way #zkdev handle security: blame the messenger. That's why things do not change, and ZKLobby can still be used to deploy trojans anywhere and by anyone, server security is abysmal

My point is, can we admit that:
- code in repository is dangerous
- code is partially unmaintained
- authors of the code will not fix it, they expect you to fix it
- nobody is fixing the bugs
- everyone knows the bug is there (devs, users, trolls, attackers)
- some ZK guy pushes the deploy button anyway, he does not feel responsible

Is this an acceptable state for a release ready product?

@abma, I'm afraid it would not work... the ZK spin doctors will explain how nasty you are, and in the end, ZK will setup its own uberserver which will further split the community. I'm not even sure the ZK community understand how much fail has led to this situation where spring is now moving his server... and how donation money is wasted.

quote: Wait what? Did i misse some ZK vs Other mods vs Enginedevs drama?

that's what I was wondering too- was gone for a short time and came back to people talking about server splits. hopefully it's not mirage/eclipse bad(and even more,hopefully disputes never get that bad)