DeleD Community Edition

[Guest]

How about showing a list of features, and telling us if they are accepted, rejected, or being considered, and what the priority they have in being worked on.

[vincent-v]

I think it's a good idea

[Paul-Jan]

Out of curiosity: why do you want to know this, and in what form would you expect us to make this information available?

[afecelis]

a development list, like the ones many applications got in their site. It's a nice way of checking the development path and the future progression of the program. It also tells you since which version a feature was added in, if it's totally covered or if things are still pending. Here's Irrlicht's as an example:
http://irrlicht.sourceforge.net/development.html

[Guest]

"Out of curiosity: why do you want to know this, and in what form would you expect us to make this information available?"

1. The bigest reason I'd like to see a simple list is because it helps me decide on buying supporting products or waiting. Like should I buy ultimate unwrap or DeleD Pro ?

2. It's also nice to not to request features already tabled.

3. It's nice to see the path the project is taking.

4. DeldD could offer a yearly subscription fee of $10, and give those users rights to vote on feature priority, early access to beta features, etc.

[Sindwiller]

[Paul-Jan]

I am going to make some preliminary remarks here on this subject. These things do not represent the 'official Delgine view' ( ), they are simply me sketching out some thoughts on publishing lists of future development items...

One reason why we do not publish such a list, is because we are small. Public milestones are promises, and when you are too small to guarantee in any way when (and if) these promises are going to be kept, they are worthless (or even have negative value). Please note I am not saying we don't make our milestones, I am just saying I think most one-man-and-his-dog 'companies' on the internet publishing Milestones look a bit silly.

A reason why we do not have a published priority list, is that maintaining such a list takes up a lot of time, since our priorities shift a lot. By small amounts, but they do shift... shifting up priorities is usually no problem, but you wouldn't believe the amount of negative (and time-consuming) feedback you get when you consequently shift down the priority of minor issue XXXXX.

That said (the historical reasons why we didn't put in the effort to publish and maintian such a list, and stick with our internal to-do list), if we can decide on a way to publish this list in such a way that it conveys all the important information in an efficient way, we would be more than willing to consider putting in the time and effort to publish such a list. We had plans for a complete list of current features anyway, so that's about the bare minimum

So the question: "what would you like to see on this list, and in what form" is very important. The Irrlicht development list is a good example, but any more details on what you guys would like to see are most welcome.

In response to Guests response to this questions:

1. We feel very strongly that you should make these kind of decisions on what our application has to offer now. If it isn't worth your money now, don't buy it. There is a free version anyway, see if you like it. If you want something added, ask away. You are right however that there really needs to be a readily available complete list of current features (there is one in the help file), to enable a quick evaluation of the above.

2. True. However, for us it is a very good indication of how 'in demand' a certain feature is if multiple people ask for it independently.

3. Very true.

4. Nice idea, but we prefer to base our development on any user feedback that makes sense. We already have a sifting system: PRO feedback weighs in heavier than feedback from non-paying customers, as we expect them to use the application more seriously. Beta testers feedback is rated the highest. So if a users wants to put in a maximum amount of influence, they will have to join the beta team by use the program intensively, thus providing the highest quality feedback. We believe this system is in the best benefit of the application, rather than having people 'buying themselves into taking the helm".

[Jeroen]

What PJ said is basicly what I'm thinking too. In addition:

[trucker2000]