DFD: Daily Feature Deathmatch

[Renegade]

DFD: Daily Feature Deathmatch

---

The Cruel Fight For Implementation

Intro
If you have followed our bugtracker, or seen RockPatch's wishlist in the past, you know that requesting features is something the community loves to do, and loves to do frequently.
We don't complain about that, we think it's a good thing, and we do encourage you to share your ideas.

However, we also have to be realistic.
We generally have about 3-4 people coding on the project.
We currently have 416 unresolved issues.
We currently have 252 unassigned issues.
We currently have 131 issues that haven't even been looked at.

Going by pure scheduling, we have 300 issues which don't have a target version set, iow, which aren't scheduled to be included yet.
We would like to get to all of those, and we hope we can, one day, satisfy all of them.

However, short-term, let's be realistic: We're trying to schedule a workload equivalent to roughly 20 medium-effort issues per version. The more complex issues end up scheduled, the less overall issues get scheduled for a version - very visible on the schedule for 0.4, which will include super weapon stuff. In addition to those, for each version, you have to calculate the bugs of the previous version, as well as the ones testers find in already coded features - Ares 0.2 is at 51 scheduled issues by now, and even 0.3 has already grown to 29.
By the time 0.2 is finished, there's a good chance it will have cracked 60 issues, only about 20 of which were scheduled in advance.

Now use that knowledge to make a realistic calculation about the work load of those 300 issues. Even if you assume them all to be of 100% equal, medium complexity, you'd still end up with enough stuff to schedule 15 additional revisions. Even if you assume we'd kick out a few for nonsense, duplicates and stuff, over the course of development, new requests would be added to the database, filling the gaps left. Then take into account bugs found, regressions, etc., and, instead of looking at 300 issues, you're looking at a good 1000-1200 issues to be dealt with until all of the currently unscheduled issues are handled.

...with three coders.

You should be seeing the issue already, but just for fun, let's assume the most optimal case for a moment:
Let's assume all those 300 issues are of equal, medium complexity, there are no additional bugs or regressions, and development continues with the amazing pace of one version every two months.

Even under those perfect conditions, it would take us two and a half years to fulfill all the currently unscheduled issues.
And conditions will not be perfect.

And remember: Those are just the issues not scheduled yet. We have scheduled issues up to 0.6 by now. So realistically, we'd be talking 3 1/2 to 4 years, at least.

Now, we are not saying we will not invest that work per se.
What we are saying, however, is that it is very obviously necessary to triage and cut down, on a massive scale.

So we're gonna make a spectacle of weeding out the issues.

The Plan
Update: After further analysis, planning and calculation, this section was updated to reflect current plans.

• Every day, in this very news section, we will announce two death matches between two issues each.
  In general, these will be feature-requests, but there may be the occasional bug report among them, for example when then bug's effect rarely occurs, but the fix would take a considerable amount of work.
  
• For 48 hours¹, the community can make arguments for the survival or death of either fighter.
  The Ares developers will not get involved in these discussions, except to moderate discussion-behavior.
  
• Much like on Wikipedia, there is no strength in numbers. While broader support will be taken into account, the strength of the argumentation will be what's relevant.
  
• After 48 hours¹, the active Ares developers will judge - each coder will say which issue's survival he supports. One issue will die.
  Should, for example through a change in coder numbers, a stalemate occur, both issues will be pitted against new opponents, continuing until one issue died.
  A selection will be made no matter the length, intensity or quality of the discussion, the coders don't have to explain their decision, and their decisions may be influenced by more than the discussion, for example the scope or the viability of an issue.
  
• The losing issue will be closed as suspended and tagged as "dfd-loser"; the winning issue will be set to confirmed and tagged as "dfd-winner", both with reference to the round the elimination or victory occured in.
  
• All issues left standing after Round 5 shall be considered "chosen" by the community. They will be left in the pool of issues for the community to continue the normal process of priority assessment, which will ultimately determine what version the issues are scheduled for.
  If it transpires at a later point that the community does not support the winning issue at all, it can still be killed.
  
• Losers may be resurrected at later points in time, either when the backlog has sufficiently shortened, or to be pitted against newcomers, or when it becomes apparent over time that there is significant support for the issue.
  

The death matches will happen over several rounds in different kinds of pairings. Due to the very volume of issues that has made this kind of weeding out necessary in the first place, the first round of fights was generated automatically. Before each tournament day, the issues will be checked by the coders in terms of viability or desirability - should an issue turn out to be utterly stupid, impossible, or otherwise un-implementable, it will be killed without even being put into a fight. Should the coders decide they want to take on an issue no matter what, it will be taken out of the tournament and placed back into the normal issue pool.
In either case, the remaining issue of the scheduled fight goes into the waiting pool.


Click here to see the Tournament Schedule.

¹ Actual time dependent on the situation, though it'll generally be roughly two days.

The Result
The result will be very Men In Black-like: The best of the best of the best get in.
In the long term, this will increase the quality of Ares as whole, since issues got in not because they were there and someone was randomly in the mood to code them, but because the community actively made convincing arguments to include them.


We realize this system is harsh, we realize this sucks, we realize this will lead to good requests dying.
You don't have to tell us this.
The sad truth is, there are too many requests for us to conceivably work on in the foreseeable future, and while the community has been helpful in telling us which issues it supports to which degree, rarely have there been cases in which the community came forward and outright told us to kill an issue.
This is an understandable attitude for the community - most requests are reasonable and can lead to useful extensions to YR, so you're of course asking yourself not "do I really want this?" but "do I want this more than issue X?".
However, that is not a realistic attitude for development.

The only way to reasonably manage the volume of requests is cutting.
We can't fulfill everything.

We could have made the choices ourselves - just look at issues as they come in, do a quick vote if we want to do it, and if no one wants to, just kill the request.
However, that would not have been nice and community-friendly.

We hope that, as much as you dislike the fact that we are going to kill requests, and as much as you may hate us for asking you to make the selection, you do acknowledge that we're at least giving you a choice, and that we're at least giving you a chance to fight for the issues you love.


As said: No death is final. But killed issues are very unlikely to be implemented soon.



P.S.: As I was writing this post, a few issues have been closed, others have changed, so the counts given above might be slightly off - they're still very much in the same general area, though.