Renegade Projects Network Forums
Accelerated Feature Fate/"Why not?" Requests/Release Speed - Printable Version

+- Renegade Projects Network Forums (https://forums.renegadeprojects.com)
+-- Forum: Inject the Battlefield (https://forums.renegadeprojects.com/forumdisplay.php?fid=60)
+--- Forum: News from the Battlefield (https://forums.renegadeprojects.com/forumdisplay.php?fid=20)
+--- Thread: Accelerated Feature Fate/"Why not?" Requests/Release Speed (/showthread.php?tid=1629)

Pages: 1 2


Accelerated Feature Fate/"Why not?" Requests/Release Speed - Renegade - 29.07.2010

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?


RE: Accelerated Feature Fate/"Why not?" Requests/Release Speed - RandomNutjob - 29.07.2010

This does sound very appealing, my only thought is if have more regular releases and there is a problem with say one of the bigger features would that slow the releases or it be swapped/taken out and tinkered with until is a-ok?

Obviously that is hopefully unlikely to happen but just thought would ask

If releases are all up to scratch then I'd support regular releases as way of keeping people occupied until the next one without waiting as long [though of course as you explained 4 lots of 3 would be addressed in time set out for the 12 as a whole, in theory]


RE: Accelerated Feature Fate/"Why not?" Requests/Release Speed - Black Shadow 750 - 29.07.2010

One complaint I have with the bugtracker, related to removing unwanted features, is the lack of an ability to merge duplicate issue's support. For example, "The ability to have a unit deploy into a different building dependant upon the terrain", Issues 1116, had a lot more support than "amphibious structures" even though they were, in essense, the same.


RE: Accelerated Feature Fate/"Why not?" Requests/Release Speed - RandomNutjob - 29.07.2010

(29.07.2010, 14:13:54)Black Shadow 750 Wrote: One complaint I have with the bugtracker, related to removing unwanted features, is the lack of an ability to merge duplicate issue's support. For example, "The ability to have a unit deploy into a different building dependant upon the terrain", Issues 1116, had a lot more support than "amphibious structures" even though they were, in essense, the same.
Copy-paste?

I commented on low power state weapons in Weapon states so hopefully that'll get incorporated

I agree that those with comments and support should be carried over although can simply copy comment/s and support alternate


RE: Accelerated Feature Fate/"Why not?" Requests/Release Speed - Black Shadow 750 - 29.07.2010

Yes well, for me to copy-paste the support over I'd need access to their computers. Which I obivously don't have. Obviously.
>.>
<.<
Tongue


RE: Accelerated Feature Fate/"Why not?" Requests/Release Speed - ¥R M0dd€r - 29.07.2010

I support the Release Speed idea. It is better


RE: Accelerated Feature Fate/"Why not?" Requests/Release Speed - RandomNutjob - 29.07.2010

(29.07.2010, 16:14:05)Black Shadow 750 Wrote: Yes well, for me to copy-paste the support over I'd need access to their computers. Which I obivously don't have. Obviously.
>.>
<.<
Tongue
I was going to suggest contacting those who had given input but seems be challenging - guess so long as is made clear is duplicate and where should move comments etc to then things should be fine, not hard to read and copy-paste and then give input again


RE: Accelerated Feature Fate/"Why not?" Requests/Release Speed - Dupl3xxx - 30.07.2010

This sounds like a very good idea!


RE: Accelerated Feature Fate/"Why not?" Requests/Release Speed - Guest - 30.07.2010

I support the Release Speed.

Here is my 0.2/3 fav list:
1) More than two weapons on a unit
2) Slaves
3) JKell


RE: Accelerated Feature Fate/"Why not?" Requests/Release Speed - WoRmINaToR - 04.08.2010

having more frequent, stable releases means we get more features out to the larger community much faster and we will have many more opportunities to attract new users and new testers willing to get in on what we do now. Not to mention these people will be using the latest features and making sure they are perfect, and would report back to us if they weren't.

Overall, the effort put in to push out more frequent releases will greatly pay off because we will have all the modding community testing the latest issues (even though they should be stable by then, accidents do happen), instead of our comparatively smaller and somewhat lazier/busier pool of testers.


RE: Accelerated Feature Fate/"Why not?" Requests/Release Speed - reaperrr - 06.08.2010

I'd clearly prefer smaller but more frequent releases. I also agree that issues that have the same 'topic' should be concentrated on one release instead of being spread over several releases. For example like Ren said, I think it would make sense for #846, #882 (both currently scheduled for 0.2) and the sub-issues of #173 (currently scheduled for 0.3) to be in the same release as they all revolve around the RMG.

Btw, this is just a suggestion (and I guess something like this would happen anyway, even without me suggesting it LOL ), but I think after DFD is finished the roadmap could use some revising either way.
It's just my personal opinion, but I believe it would make sense to move features that are both very popular and require only a moderate or even relatively low amount of programming to the earliest possible release(s), and push stuff that is very complex and/or has very little community-backing back to later releases.
Time is a limited resource as we all know, and who knows, maybe YR won't even run on Microsoft's next OS, so I really think the "most wanted" features that aren't too problematic to implement should be given the highest priority, followed by the "possible and wanted but a bit complicated" stuff and finally the "rather simple but not that popular/interesting" stuff should be last (because if barely anyone is going to use it, there's no point in doing it early, imo).


RE: Accelerated Feature Fate/"Why not?" Requests/Release Speed - Darkstorm - 08.08.2010

I definitely support frequent releases. Theoretically you get the same amount of features in the same amount of time just get access to them more quickly.


RE: Accelerated Feature Fate/"Why not?" Requests/Release Speed - AlexB - 08.08.2010

Don't forget the overhead for writing documentation, testing, testing, creating the installation package, testing, updating the website, fixing stuff and more testing. Potentially, you still get the features more quickly theoretically.


RE: Accelerated Feature Fate/"Why not?" Requests/Release Speed - reaperrr - 07.09.2010

(29.07.2010, 01:41:56)Renegade Wrote: 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.

Does that include features currently scheduled for 0.2, or will it only affect 0.3 onwards? I'm asking because there are a few features scheduled for 0.2 that have gathered little-to-no support so far, and that seemingly haven't been worked on yet either, so IF what you said applies to 0.2 as well, I'd comment on them now, because I think it's in everyone's interest to make sure a repetition of what happened to Jarmen Kell won't happen, and delaying unpopular features would be one possible measure.

If you say the 0.2 roadmap won't change (since it's rather close to completion already), I'll fully respect that, I just want to know wether there's a point in voicing my opinion on these particular issues or not.


RE: Accelerated Feature Fate/"Why not?" Requests/Release Speed - Renegade - 07.09.2010

Go right ahead and comment.
If features have already been started, it's up to the individual coder whether he finishes them, but unless one of us really wants to do a certain feature, we're rarely crazy about wasting our time on unwanted features.

The more input we get, the better.