A bit off the trail of the other topic, so opening a separate discussion …
IMO, These yearly threads should be discouraged.
It is much better for discussion if each FR gets it’s own discussion thread.
Besides, by the time you are opening the “yearly FR topic” it is most likely that the dev team has already decided upon what is “on the docket” for the next year’s development. So, I feel anyone posting in those threads are basically wasting their time. So I myself avoid reading them, or posting in them. (It is just a nightmare trying to discuss multiple features in one thread.)
I think they could serve a good purpose, but not as they currently exist. I’d rather see them be a Wiki type thread where only people with a high trust level have the ability to add a summary of a FR appearing elsewhere, along with a link to the full FR.
Then pin the current year’s wiki to the top of all the “Feature Request” subcategories. Or perhaps have a separate Wiki for each of the (currently 5) Feature Request subcategories.
By doing this, we have a curated “Index” to all feature requests.
But as @DanRathbun says, we can only discourage their current form - unless we want to introduce a ban on that type of thread, anybody can start one, no matter how much it’s “discouraged”.
Alternatively, have a SINGLE Wiki in each FR subcategory - no breaking it into years. Once a FR is actually implemented by Trimble, the FR entry in the Wiki would be changed to show it’s implemented status.
And yes, I know I’m suggesting that we implement a bug-tracker like feature tracker within this forum. I think it would be a valuable reference and stands a chance (not a certainty) of heading off duplicative feature requests.
To me, the big disadvantage about have something like this hosted outside this forum is that it wouldn’t stop non savvy user from suggesting features that have already been requested.
For completeness: I’m not claiming that having such a feature within this forum would stop duplicate feature requests, only that it is my hope that they would be reduced.
I’m a bit on the fence here. I think separate threads for each idea are the best for going into depth but the threads just listing ideas are also interesting to get an insight in the opinions of the community. The large list threads helps see how popular ideas are, as similar ideas often reoccur, and I suspect they are easier to dump a few vague ideas into, while dedicated threads typically go much more into detail on the implementation.
This sounds almost like the opposite of how I view the current wish list threads. If the current wish list threads are the first step where ideas emerge and dedicated threads are the second step where ideas are refined this could perhaps be a third step where thought through ideas are filed?
I wouldn’t say it is a complete waste of time as the features listed in the thread can still be implemented in a few years to come, but I totally agree that the titles are misleading. Instead of new threads each year I think the same thread can just continue.
Individual feature request threads are easier for my Product Management team to track than one big ‘laundry list’ of requests. The most important thing for me is to be able to discuss the idea in more depth- why is the feature interesting, how would it be used and in the service of what tasks.
I have always preferred dedicated idea tracking systems rather than forum threads.
I’d have no qualms about having a dedicated idea tracking system, separate from, but accessible to users of this Forum. If for no other reason than that we could then, on seeing a request on this forum that is already on the tracking system, we could simply point the requester to the appropriate tracking system entry.
But that would do nothing to reduce the number of duplicative requests. And it’s the hope of reducing duplicative requests that causes me to still want, at least, a pinned “FR Index” topic, maintained as a Wiki, with edit privileges restricted to some group of people like Sages, Moderators, Trust Level 4, or something similar. The restriction would exist to make the possibility of malicious edits vanishingly small.