Forum suggestions

[ady4um]

I would like to suggest some things that IMO could improve the forum, specially the Announcements category and the Feature Requests one.

Goals list:

I suggest that each future Announcements thread about a new in-development version (alpha, beta, RC...) should have a list of minimal basic goals for that version to be released.

In the same way there is a change log for changes and fixes in each first post of the thread, there should be a goals log.

Some goals could be dropped out, and others could be added, according to the devs decisions during the development. The goals log would state those decisions, and particularly which goals are already achieved and which still are to be reached.

Users could know there is no point requesting features in the announcement thread, instead of doing so in the appropriate category. If the devs should decide a new feature request is appropriate to be added to that release, then they could added to the goals list of that thread.

Users asking when the final release will be out, would know that it is going to happen when the listed goals are reached. Since there is no pre-established released date, at least users would know what to expect from the next release. According to the goals log, they would know if the devs are more or less near to finish.

Instead of first working on the development and then getting feedback, users could start giving feedback since the beginning of the development, even before the devs start typing. (e.g., if users would have known about all the new tabs in ut 1.8, they could have give feedback sooner, maybe avoiding the Transfer tab at all).

Tittle Flags:

Moreover, feature requests' threads that were included already in ut should be marked so, with some [Done], or [included], or [OK] flag or something alike in their tittles. Or alternatively, they could be moved to a new category. In that way, topics in the Feature Requests category should stay there if they are not already included.

Feature Requests that were *very clearly* rejected should be flagged so in the tittle. This should be done only when in the specific thread there are real arguments about for and against the feature. If any user would want to state *new* arguments to vote for the feature, that's ok. Let me be clear: if there are no logical and based arguments to reject a feature, the thread should be *not* flagged as rejected. This [Rejected] flag should minimize repeated requests that were clearly rejected, without the user adding some clear new argument for it.

On the other hand, if a request is planned to be added to the next ut, the thread should be also marked as [Planned], and the feature should be added to the goals list (see above). When the new ut version is released, the feature request thread should be marked as [included] (see above).

Currently, feature requests' post are being leaved with a question mark. The user doesn't know if the request was welcomed, if it's going to be implemented in the near future, or its priority is so low that it will take "forever" to be seen implemented. Or maybe the request was completely rejected, but users are still waiting and hoping for it, simply because nobody told them it was rejected. The flags should actually save time to the mods, for example by minimizing having to repeat over and over the same answer.

Other flags:

The Found Bugs category, and maybe the Troubleshooting one also, could used some [solved] flag in the tittle. By this, unsolved known bugs are clearly separated from solved ones. New users "finding" already known bugs won't have to search the whole category. The best thing about this would be that if the devs are in need of reproducing some situation to resolve the bug, another flag could be used with reported found bugs, so users would know that even if the bug was already reported, the devs will very welcome their comments. Of course, a bug flagged as [solved] would lost its flag if it is discovered that it is not really solved.

I hope this suggestions could be useful, and it would be great to see them implemented.