| Accelerated Feature Fate/"Why not?" Requests/Release Speed | |
| Posted by: Renegade - Thu, 2010 Jul 29 - Comments: 8 | Views: 88 | |
 |
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? |
| Posted in: News from the Battlefield | |
| DFD: Round II | |
| Posted by: Renegade - Thu, 2010 Jul 29 - Comments: 4 | Views: 72 | |
| |
While we judge another 50 fights of Round 1, you can continue to kill in Round 2 of the Daily Feature Deathmatch. Since Round 2 consists only of issues filed since the beginning of DFD, it's only 5 threads/10 fights. Question: There have been a number of times where the majority of you sat in DFDs and didn't want either of the issues in a fight - would you like an Ultimate Smackdown before Round 3, with the purpose of killing all issues that are complete bullcrap and/or shouldn't even be considered? That way, we'd go into Round 3 with only issues that are at least somewhat sensible. Your call, I can set it up either way. For now, go kill in Round 2. |
| Posted in: News from the Battlefield | |
| Daily Feature... Massacre? | |
| Posted by: Renegade - Thu, 2010 Jul 22 - Comments: 2 | Views: 92 | |
| |
Good day...after a few weeks of DFDs, the strengths and weaknesses of the system become apparent, and we'll adjust accordingly. The concept itself seems to work quite well...while the tracker is quickly filling up with new issues to replace the fallen ones, the DFDs reliably show which issues are most important to the community, and bring up issues that otherwise wouldn't have been thought about. On the other hand, there's a slight pacing issue - most DFDs, despite having 48 hours allotted, end after a few hours without big discussion, and on some days, we simply aren't all that motivated to go through the whole closing, judging & new posting process. Also, I assume by now anyone interested has noticed the DFDs, so there's no need doing them in the news anymore. Therefore, we'll do the following changes to the system today:
You may wonder about how you're supposed to judge all of the issues at once - welcome to our world! Just kidding.  You don't have to. As said in item 2, we'll judge when the fight is obviously over - if the fight hasn't even started yet, then obviously there's nothing to judge. So don't panic about posting in every thread immediately. Go to the schedule, look up the issue numbers of the fights you're interested in, and start with those. We will ultimately even judge fights that no one commented on, but only when it becomes apparent that nobody's commenting 'cause nobody gives a shit. So don't panic, just go and kill as many crappy issues as you can. With the commenting pace the community had so far, this should cut down the total period of DFDs significantly, and we'll soon be able to move on to a more permanent method of issue control. Update 1: The previous DFDs have been moved to the new section. |
| Posted in: News from the Battlefield | |
| Anonymous submissions disabled | |
| Posted by: Renegade - Sun, 2010 Jul 18 - Comments: 14 | Views: 163 | |
| |
Gather round, children, and thank chief moron 95.66.15.208 from Kuwait for submitting his worthless duplicate to #378 for the third time, thus forcing me to turn off anonymous submissions on the tracker. Anonymous morons have submitted a shitload of worthless crap recently, but his submissions were the pinnacle of worthlessness and disregard of the search functions. Thank him you have to log in now. |
| Posted in: News from the Battlefield | |
| Proper filing of a feature request | |
| Posted by: Renegade - Fri, 2010 Jul 16 - Comments: 0 | Views: 47 | |
| |
In light of recent developments I have decided to start actively enforcing the feature request submission rules which have been public for two and a half years now, and still continuously get ignored. For the last time, this is how a proper feature request looks like: The submission rules Wrote How to request a Feature Go to bugs.renegadeprojects.com. Click on Login. If you have an account, log into it. If not and you want to be informed about your request's outcome, plan to request several features, or want to report bugs later, click Signup for a new account and register; if not, click Login Anonymously. Once you are logged in, either normally or anonymously, click on Report Issue. If you didn't do so already, the system will ask you to select a project. Choose Ares and click Select Project. Now set:
Afterwards, click Submit Report. Congratulations, you just requested a feature.In addition, the Priority must not exceed "normal". If it does, the feature will not count as properly filed. Also, as anyone who has followed tracker discussions knows, an actual usage case for your request is vital. We don't implement features just because someday, somewhere, an unknown modder might perhaps eventually have a good idea that your request could possibly be absolutely essential for. Either you can show what your request is good for and that it'll be interesting to the community at large, or its priority will dwindle significantly. As of 30 minutes ago, every feature request not adhering to these guidelines will be suspended immediately. Duplicating it will only make it worse, duplicating it improperly will pretty much guarantee it'll be ignored forever. If the system allows you to, you can re-open/edit and fix the issue, but rest assured, reopening and leaving an issue improper will not increase our goodwill. I would like to stress that these rules aren't new. These have been the submission rules ever since the tracker was installed. In the past, we just didn't actively enforce them. Due to the increasing amount of crappy, improperly filed requests we're getting, this time is now over. In addition, I would like to point out that we're kind of tired of getting spammed with bullshit issues, and that we will employ additional measures to counteract them if necessary - this can range from enforcing registration before request, to an increased number of immediate closings, to an all-out referral of all new issues to a committee of trusted community members who weed out issues and decide what we'll look at in the first place. We're not doing that just yet, but rest assured, the options are there, and we're ready to make use of them if necessary. For the curious: 37% of feature requests in the past 16 days have been closed immediately, and out of those, 43.75% were duplicates. |
| Posted in: News from the Battlefield | |
| Garbage in the tracker | |
| Posted by: DCoder - Fri, 2010 Jul 16 - Comments: 6 | Views: 120 | |
 |
Attention attention: the quality of new issues being posted at the bug tracker has recently reached dreadful levels. Administrative Notice:Cease posting shit immediately. |
| Posted in: News from the Battlefield | |
| Launch Base 0.99.258 | |
| Posted by: Marshall - Tue, 2010 Jun 29 - Comments: 0 | Views: 27 | |
 |
Launch Base Version 0.99.257 - 0.99.258 [2010-06-29]
Launch Base Mod Creator Version 0.99.111 [2010-06-29]
Get them here! |
| Posted in: Marshallx Industries News | |
| DFD: Daily Feature Deathmatch | |
| Posted by: Renegade - Sun, 2010 Jun 27 - Comments: 0 | Views: 183 | |
| |
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.
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. |
| Posted in: News from the Battlefield | |
| Ares 0.1 P1 | |
| Posted by: Renegade - Sun, 2010 Jun 27 - Comments: 0 | Views: 179 | |
| |
Over the past week, a critical memory management issue in Ares 0.1 transpired, which could potentially lead to crashes in all situations in which InfantryTypes which have ever been garrisoned are killed. Due to the high probability of such situations happening in normal games, we decided to release the fix(es) for this issue as a patch to the stable release. The patch has been live in the repositories since this morning, and many Launch Base users should already have been offered the new version. We have now updated the downloadable release packages for manual users. It is highly recommended that all Ares users update to P1 as soon as possible. Thank you for your continued support and trust in Ares.  DOWNLOAD ARES 0.1 P1 This patch includes fixes for the following issues: #1018, #1019, #929, #934, #946 |
| Posted in: News from the Battlefield | |
| Launch Base 0.99.256 | |
| Posted by: Marshall - Thu, 2010 Jun 10 - Comments: 0 | Views: 44 | |
| |
Version 0.99.256 [2010-06-10]
Get it here! |
| Posted in: Marshallx Industries News | |