On Thursday 26 April 2012, Ramy Yanetz wrote: > Good points Scott. We need more than just communicating known issues but also > classifying the tickets. Ticket voting would be great too. The majority of > tickets are stuck in the wishlist bucket, and we need a way to priorities > them. But I am not sure who may be authorized to do so. When I tried to bump > up the priority of some of the tickets I opened I got scolded... That would have been me.
> It appears that the priority of a ticket is currently up to the discretion of > the developers only, I have no problem when a new ticket is initially created with some suggestion for an implementation milestone. But in the end it is a developer who has to invest his own free unpaid time to implement something - so please accept their scheduling. The workload of the active developers for xcsoar is significant. Submission of working code is certainly welcome and greatly increases the chances of it to be included fast. > which could be understandably biased based on workload, personal preferences > etc. This certainly is one aspect of it. Another one is the that developers already often have some restructuring in mind where some "quick" - the complexity is often also completely underestimated by users - implementation would severely complicate the final goal and lead to wasted work. But another important aspect is that many of the vocal users, which have some specific wishes, loose sight of the many more "quiet" users which are already now completely overwhelmed by the sheer number of options xcsoar has. I see that in my club all the time. Simply piling option after option in xcsoar will drive this users away in search for a simpler solution. If something needs a setting because it is not a feature appreciated by all users the benefits have to be carefully considered, even if for the requester it means a minor inconvenience. Making a feature available is a one-way road. Removing a feature (even for something as simple as a choice of the style of the wind arrow rendering) will always cause an uproar. And finally, changes to existing working code always have the potential for regressions. The timeframe for introducing changes also has to consider the potential side-effects. The more combinations of settings there are, the larger the probability of missing some unintended interactions is. Also the developers can not test all combinations of settings, target devices and external devices - many of which he has not even available for testing. Andreas ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Xcsoar-user mailing list Xcsoar-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcsoar-user
