Do you have open feature requests here? Read this.

[LPChip]

For new people:
This forum was created to keep track of new requests when there was no issue tracker yet. This sub forum is now considered obsolete. Please use the issue tracker for requesting new features. You might also post in the General Chatter forum if you expect a bigger discussion being the result of the request.

For people who have open feature requests on this board:
Please take some time and open a new ticket for each of your requested features on the new issue tracker, and then post the link to the ticket in the original feature request thread. We won't do this for you, but if you do this, you'll do us and yourself a great favour, as tracking the requests is a lot easier on an issue tracker than it is on a forum.
Note that you can sort topics by Author, this should help you when searching for your own topics.

Description of the forum:

As you can see, some topics are marked with a status, which means the following:

[ASSIGNED] - When a programmer decides to add the requested feature
[PENDING] - Request has been added, and requires validation on your side to see if its right. If not, status is being set back to Accepted/Open.
[DECLINED] - When a programmer decides to not add the requested feature. (for instance, not possible, or it's a dupe of another feature request thread)

Text updated by Jojo

[SoundCrafter]

I just wanted to say great idea putting this forum in. Makes it a lot more organized and easier for the programmers (I'll be one...someday...)

[Relabsoluness]

Please do not post a request if you aren't sure if it has been posted before.

Does this have to be so strictly formulated(the same for the bug report forum)? People use different terms in descriping requests/bugs and in order to be sure that ones request/bug report has not been posted before, one could possibly have to read and analyze every single one of, who knows how many, previous requests/bug reports; doesn't seem like a 'fair instruction' and indeed a task that I think could prevent some people from posting bug reports or feature requests.

[Sam_Zen]

Nice work LP !
I sometimes was confused with the bug-category, because I think posting a request is very different from posting an existing malfunction. Now the choice is clear, and the member can make up the mind to choose to 'report' or 'suggest'. (shouldn't this be sticky, btw ?)

2 Relabsoluness
I guess time will solve this. Most of the old requests inside the bug-category are probably sunken into history, with or without having realized the suggestion in the meantime. So no need to check that category all the time for
duplicates. I think it's sufficient to check the posts of this new category by the future posters.

[LPChip]

2Samzen: Good thinking for the sticky thingy. Done. Thanks for the idea:)

2Relabs: Basically I copied the entire post from the bug report section, and slightly modified it. As for the line, I want to prevent getting several topics with the same suggestion/bug so that we can end up with a suggestion remaining open while another has been fixed. I can split a few posts to a new topic, but I cannot merge two topics together unfortunatelly. (not yet new system surelly will get this feature).

Due to this, I rather have someone to post in an existing topic if it could be related, so we can split the topic if necessary.

[Relabsoluness]

I see the point in this, but I was just saying about the way it was expressed. If it really is expected that people are sure about the suggestion/bug report being new, hardly even the oldest open posts can be neglected(for example currently there are about 30 posts in bug report forum). I understand that statement 'be sure' likely was not intented to be as 'strict' as I interpret it, but then again, it's so difficult to see what some unknown writer meant with being sure if he really didn't meant 'being sure' (but ok, this probably sounds useless jobsworthing(I'm not sure if this is the right word, couldn't find better , but I don't find it strange at all if someone won't post e.g. bug report because of this).

[LPChip]

They'll post, but they first do a search, which is basically why this statement is there in the first place.

[shableep]

just a suggestion, but...

shouldn't "feature added" and "feature canceled" be 2 totally different abbreviations? i'd like to be able to look at the list and see features added without getting confused with the ones that got canned. so then i guess "S=A"... for 'added'. maybe a smiley face for good measure. and why not make it a sticky? those features aren't going anywhere, and it'll stop people from posting duplicate requests.

also, shouldn't the "S=" mean "suggestion"? then "B=" would mean "bug report". no need to clutter up the pretty equation with "[REQ]".

and just to be picky.. shouldn't "O" mean it HAS been judged? because "P" for "pending" suggests that it's in the process of being judged. pending judgment. because if it's not pending, then it must have been judged to be 'open' or 'closed'. one or the other.

just my 3 cents.

[LPChip]

S= stands for Status

As for the different statusses, I've added this feature some time ago, and it took me quite a while to get support for the different statusses.

For that reason when making the requests forum, I kept with the simple 3 statusses, and didn't add support for more statusses.

Maybe when I get some additional time, I'll add it. I can't promise it though...

[nitrofurano]

i can't create an account on the issue tracker - how can we do that?

[Saga Musix]

Please be more specific what your issue during registration is. If you are getting a password prompt, read it (or in case of Chrome, read the page that is shown when you cancel the password prompt).
(and no, I won't implement a text-based module format just for you.)