Renegade
29.07.2010, 01:41:56
Accelerated Feature Fate
Who frequents either the tracker, the DFDs, or this news section has heard by now that we're dealing with a high number of issues that are best described as "crappy".
In addition, there are a number of issues, both old and new, which are valid feature suggestions, but either find no echo in the community, don't seem worth the effort, or quite simply find no one willing to code them.
In the past, a certain sense of diplomacy led to such issues quietly dwelling at the bottom of the tracker, in a sort of limbo - not closed, but not acknowledged, either.
This will now end.
With DFD Round 2 having started, no new features will enter DFD anymore, and any issue with an ID higher than 1158 will be judged on the tracker again.
However, we have no desire to just start the cycle over and accumulate a new year of issue-cruft.
From now on, all feature requests will be judged swiftly and decisively. We will do assessments of the features as soon as we can, and if we determine that they are either unrealistic or that no one will be there to code them, we will close them immediately.
Those who are left open are to be vetted by the community - we will look at the argumentations in the comments and the expressed community support in the ICS, and will then make a decision on whether to implement the feature or not.
If we decide not to implement the feature, the request will be closed.
If we decide to implement it, the feature will be promoted to confirmed status.
This will be drastic in some cases.
As with DFD, there will be issues the community may want that still get closed. This sucks, and we all wish we'd had an army of magic elves to help us code, but the fact of the matter is -as has been said multiple times during DFD- we simply cannot implement all requests, and to pretend we can by keeping issues open indefinitely serves neither side of this.
"Why not?" Requests
We will also increasingly close "would be nice" kind of issues.
With 142 issues set to be implemented at some point right now, and probably another 20-30 coming in through DFD, we simply cannot afford to implement features just because someday, somewhere, some unspecified mod might, perhaps, use the requested feature.
We understand that there are many features that might have potential uses, which sound interesting, which modders might play around with if we added them, but there are simply too many requests to implement dozens of features only to have them be played around with by two people and then dropped forever.
From now on, we will put a stronger emphasis on community demand, usage cases, et cetera. The mere fact that something "has potential" will only be enough if it sparks an individual developer's interest.
Again, this will be harsh, this will be drastic, but it simply wastes both our and the community's time to implement features just because someone may want them sometime in the future, while there are requests in the tracker that the community demonstrably wants now.
As usual, of course, requests can be reopened, we're open to having our opinion changed, but we simply can't continue the way feature requests were handled so far.
Leaving all requests open indefinitely on the off chance they might gather support was the diplomatic thing to do, but as the DFDs have shown, all that did was create a collection of crappy and meh features that not even the community thinks are worth spending time on.
On a related note, it would also be appreciated if the tracker population went through the already scheduled features on the roadmap and used ICS and comments to voice their opinions. I have no doubt there are features scheduled on there that the community would rather have delayed because there are more important and desirable features requested.
To make this perfectly clear: The idea is not to kill as much as possible for killing's sake, or because we're lazy. The idea is to filter out the issues that are a waste of time anyway, and to instead focus on the most wanted features of the community, to ensure future releases are packed with features the community actually wants asap, and not just ones it's kinda happy about while it's waiting for others.
A "less is more" approach, essentially.
Release Speed
On a similar topic, there is something I want your opinions on: Currently, Ares versions start scheduled with a dozen or two requests and bugs, and then accumulate another dozen or two bugs and small requests over time.
This makes for nice, big Ares-releases with loads of features and bugfixes, but it also means release intervals of several months.
What we can offer, instead, is to cut down the features per version significantly, but to release stable versions with those features more often in turn.
If each developer only did one big feature and one small feature each version, plus bugfixes from the version(s) before, we could release stable versions much quicker and more often, and development would be much more focused - for 0.3, for example, D could focus on the random map generator, I could focus on the morale system, and Alex could focus on some other bigger improvement, and then that would be that - modders would know the themes of the next release, testers would know what specifically to test, and the release would come much quicker and more polished, since we only had to focus on getting three big systems to work, not a dozen.
The price, of course, is features - only a fraction of those currently scheduled per version.
On the other hand, it's not like it actually makes a difference, time-wise. Sure, you might only get three features per release rather than twelve, but if we release four versions in the time it'd usually take for one, you still get all twelve features at the same date as before.
It's an offer, it's food for thought, I'd just like to hear your opinions about it - do you prefer big, loaded releases with long release intervals, or small releases with few features and short release intervals?
Who frequents either the tracker, the DFDs, or this news section has heard by now that we're dealing with a high number of issues that are best described as "crappy".
In addition, there are a number of issues, both old and new, which are valid feature suggestions, but either find no echo in the community, don't seem worth the effort, or quite simply find no one willing to code them.
In the past, a certain sense of diplomacy led to such issues quietly dwelling at the bottom of the tracker, in a sort of limbo - not closed, but not acknowledged, either.
This will now end.
With DFD Round 2 having started, no new features will enter DFD anymore, and any issue with an ID higher than 1158 will be judged on the tracker again.
However, we have no desire to just start the cycle over and accumulate a new year of issue-cruft.
From now on, all feature requests will be judged swiftly and decisively. We will do assessments of the features as soon as we can, and if we determine that they are either unrealistic or that no one will be there to code them, we will close them immediately.
Those who are left open are to be vetted by the community - we will look at the argumentations in the comments and the expressed community support in the ICS, and will then make a decision on whether to implement the feature or not.
If we decide not to implement the feature, the request will be closed.
If we decide to implement it, the feature will be promoted to confirmed status.
This will be drastic in some cases.
As with DFD, there will be issues the community may want that still get closed. This sucks, and we all wish we'd had an army of magic elves to help us code, but the fact of the matter is -as has been said multiple times during DFD- we simply cannot implement all requests, and to pretend we can by keeping issues open indefinitely serves neither side of this.
"Why not?" Requests
We will also increasingly close "would be nice" kind of issues.
With 142 issues set to be implemented at some point right now, and probably another 20-30 coming in through DFD, we simply cannot afford to implement features just because someday, somewhere, some unspecified mod might, perhaps, use the requested feature.
We understand that there are many features that might have potential uses, which sound interesting, which modders might play around with if we added them, but there are simply too many requests to implement dozens of features only to have them be played around with by two people and then dropped forever.
From now on, we will put a stronger emphasis on community demand, usage cases, et cetera. The mere fact that something "has potential" will only be enough if it sparks an individual developer's interest.
Again, this will be harsh, this will be drastic, but it simply wastes both our and the community's time to implement features just because someone may want them sometime in the future, while there are requests in the tracker that the community demonstrably wants now.
As usual, of course, requests can be reopened, we're open to having our opinion changed, but we simply can't continue the way feature requests were handled so far.
Leaving all requests open indefinitely on the off chance they might gather support was the diplomatic thing to do, but as the DFDs have shown, all that did was create a collection of crappy and meh features that not even the community thinks are worth spending time on.
On a related note, it would also be appreciated if the tracker population went through the already scheduled features on the roadmap and used ICS and comments to voice their opinions. I have no doubt there are features scheduled on there that the community would rather have delayed because there are more important and desirable features requested.
To make this perfectly clear: The idea is not to kill as much as possible for killing's sake, or because we're lazy. The idea is to filter out the issues that are a waste of time anyway, and to instead focus on the most wanted features of the community, to ensure future releases are packed with features the community actually wants asap, and not just ones it's kinda happy about while it's waiting for others.
A "less is more" approach, essentially.
Release Speed
On a similar topic, there is something I want your opinions on: Currently, Ares versions start scheduled with a dozen or two requests and bugs, and then accumulate another dozen or two bugs and small requests over time.
This makes for nice, big Ares-releases with loads of features and bugfixes, but it also means release intervals of several months.
What we can offer, instead, is to cut down the features per version significantly, but to release stable versions with those features more often in turn.
If each developer only did one big feature and one small feature each version, plus bugfixes from the version(s) before, we could release stable versions much quicker and more often, and development would be much more focused - for 0.3, for example, D could focus on the random map generator, I could focus on the morale system, and Alex could focus on some other bigger improvement, and then that would be that - modders would know the themes of the next release, testers would know what specifically to test, and the release would come much quicker and more polished, since we only had to focus on getting three big systems to work, not a dozen.
The price, of course, is features - only a fraction of those currently scheduled per version.
On the other hand, it's not like it actually makes a difference, time-wise. Sure, you might only get three features per release rather than twelve, but if we release four versions in the time it'd usually take for one, you still get all twelve features at the same date as before.
It's an offer, it's food for thought, I'd just like to hear your opinions about it - do you prefer big, loaded releases with long release intervals, or small releases with few features and short release intervals?
Forum Rules
(01.06.2011, 05:43:25)kenosis Wrote: Oh damn don't be disgraced again!
(25.06.2011, 20:42:59)Nighthawk Wrote: The proverbial bearded omni-bug may be dead, but the containment campaign is still being waged in the desert.
RandomNutjob
), but I think after DFD is finished the roadmap could use some revising either way. 
![[Image: darkstormsmall.png]](http://img263.imageshack.us/img263/6215/darkstormsmall.png)
AlexB