Since technical problems after a year need usually be looked into with a new perspective I wanted to suggest to auto-close threads after 12 months.
That way users would write their problem. Given that the codebase is changing constantly, I don’t think it makes sense to ask a couple of years about “having the same problem” without new information.
The user can still reference the old thread if they believe it is relevant.
Exception would be the Feature Requests, since they will be closed once resolved I guess.
It’s a good suggestion. On the other hand, the current situation does allow the highlighting of things that perhaps SHOULD HAVE been fixed and never are…
Well, a topic that wasn’t bumped for a year probably wasn’t that important?
I understand, you might think of topics that were not answered by the juce team over a longer period, but I think that is a different problem that might improve once the JUCE teams recruiting succeeded
The bad is that it would prevent users to edit their old posts?
The good is that probably editing such old posts is not very useful (neither common).
There is already a warning message suggesting that to reply to old threads should be think twice. I’m not sure that restricting things just to avoid neglectful users worth the cost. I mean if the result is proliferation of already existing topic! That kind of users always find a way to irritate you.
I remember having several times resumed year-old threads with new information and occasionally even fixes to age-old problems. I think that such an auto-close would be very counter-productive.
I have encountered some bugs and issues which stayed relevant more than one year, sometimes issues may get reintroduced too, so I don’t think auto-close is a good idea in general. There are also cases where people discuss possible workarounds for certain issues, which might become obsolete later. In case of bugs it would be good to mark stuff as “clearly resolved now” instead. The existing warning “you’re bumping a very old thread” is good enough imho.
Idk, seeing how issues evolve is pretty valuable information. You might find a solution for a 64 bit problem on resurrecting or necro-ing a 32 bit thread!
Also you don’t sum the problem that means every year someone could ask the same thing and then next year someone asks the same thing. Then I have to dig through 3-4 different threads pages…
I could see an argument for ending threads with current juce version. However, it might be nice to just list that information. Like version at time of posting…
I just resurrected a 14 years old open-source code project and it was nice to see 6 years ago someone had the same issues I did.
I just realized after I posted… that necro-ing is not a good thing it is trolling…
I thought I was getting compliments. “Way to necro a thread.”
I thought it was good thing like YAYY! “necro a thread” “bring old thoughts to light” “anwser old questions” “resonate with the people who came before you” …nope lol
It’s apparently a bad thing??? From my understanding…
Probably because its’ not that NEW NEW
The reason why resurrecting an old thread is bad, that most of the time many things have changed, so the original context is no longer the same.
Like if somebody struggled with a problem, nobody knows if it is the same problem given in the thread, or if the original issue is even still in the software.
That’s why one should write the own problem with the own context, but potentially link to the old thread saying “seems it was already a problem back then”.
But very often people post “I have the same problem, what’s the solution” and other people have then to guess if it is indeed the same problem, or what even is the problem. Often there was a reason that the old question was unanswered.
I clicked on this post expecting to hear about a juce::Thread that runs for a whole year. I have to say that I’m a bit disappointed, though I’m still hoping that @daniel can come up with a use case.
On the other hand, i support keeping posts open. Old posts still show up in searches, and it’s good to give them continuity as juce changes and evolves. In some senses, this is part of the documentation. I am right now trying to learn a library that doesn’t have the same level of documentation and old forum posts, and I’m finding it much harder than juce was.
100% I don’t want any thread to vanish. They all should show up in searches.
What I am after is avoiding those me-too questions, where the circumstances are totally different from the old postings. Very often it is -forgive me- lazyness for not giving the own context and spelling the question, even though finding the right question is often the first step to the solution, so it is actually in the new posters favour to go that extra mile.
I am totally with you on that. It just shows that a support forum is just not a bug tracker.
In an ideal world bug reports would be propagated to bugs and then scheduled for a fix.
This forum lacks a bug status, so nobody knows what was fixed, and if when that happened…
But that is also an old discussion. Nobody likes bug trackers, especially public ones. But it would be a sign of professionalism and transparency…
IIRC it was mentioned, long ago, that a feature would have been added to this forum, to mark a post as the accepted solution for the problem discussed in each topic (somehow a-la stackoverflow).
I think that would help to keep track of those problems that are still open, maybe in conjunction with a proper tagging/category of what topics are considered bugs that the team has added to their backlog
