Of late I have seen a rise in aggressive moderation, locking topics that people bump even if the concern is valid, just because the topic is old and assumed to be unrelated.
Wouldn't it be better to just lock all the old topics pre-emptiveky rather than admonishing users for reviving old topics? It would look less aggressive to do that and would avoid the attitude a number of users have where they avoid posting here because they'll just get snarky attitude at them for it.
I also find it interesting that topics are closed as not relevant without actually being able to judge if they are not relevant. I've seen too many topics that are suggested to be separate and unrelated but are completely related, though often this is something only very technically knowledgeable users can determine.
Hi!
Do you have two or three specific example topics? :)
Then we can look at that and see if there are ways to improve it or prevent "false positives"; eg: accidental closure of related topics.
I know for example I've deleted some "bump" posts from people who tried to get to 10 posts and thus reviving months old topics with nonsense one-liners. I also know those moderations are a bit random, because not all such posts are always caught properly/in-time, and sometimes it's a bit hard to determine if the post really was simply spammy or a valid one; which results in them sometimes being deleted and sometimes they slip through the cracks. It's always a bit difficult to have 100% consistent moderation with such matters when it's borderline spam. But perhaps this is exactly one of the things you're actually *not* referring to. :P
Thanks!
The cases of bugs that were recently bumped as 'are these fixed in 2.0.14 or not', where all three topics got replies from a team member, despite the fact that it's possible all three bugs are still relevant as the messages only confirm fixed in 2.1, not 2.0.
Followed by the one of the three that was outright locked for the same reason because moderation clearly requires two members of the team to chime in.
Hi,
Links please
https://www.simplemachines.org/community/index.php?topic=482511.0
https://www.simplemachines.org/community/index.php?topic=380058.0
https://www.simplemachines.org/community/index.php?topic=475961.0
If you're going to make the whole 'old topics won't be bumped ever' thing a rule, lock 'em all and save certain over-enthusiastic people some time in their day.
I've often wondered why threads of a certain age (one or two years?) weren't locked. Or conversely, why it even matters (Core's spam mention aside).
And here we get to the crux of my point.
Either do it consistently, everywhere, or don't do it - the volume of posts is such that it really doesn't matter, and the people who consistently do it don't seem to know whether things are related. It's not always clear whether the problem in an old post is the same as a problem someone is having now, and unless the error message is massively generic, only in-depth investigation is likely to confirm it is really the same or not.
There is some value to suggesting people open new topics if they are (probably) unrelated, but the trick is to remember that most of the people posting here aren't technical.
Thanks for bringing it to our attention and for the feedback :)
We're currently discussing it.
Nothing else to report at this time, just wanted to let you know that we've taken it under consideration. :)
Will try to post a follow-up with the final result.
Just a couple of questions/suggestions ...
Would it be possible to have different Bug Report (and associated child boards) for each currently supported SMF stream (eg, 2.0 and 2.1) so that it is clear which version of SMF a bug report/fix relates to.
Also, in cases in which an issue affects SMF 2.0 but it is decided to not apply the fix to SMF 2.0, it would be helpful to advise this in the bug report thread.
The questions I asked in the links referenced above referred to issues in SMF 2.0 RC3 and 2.0.2 that were identified between 5 and 7 years ago but I had no way of knowing the fixes were never planned for an SMF 2.0. release.
we have too many boards as is, i dont see it being productive to add more boards.
Quote from: GL700Wing on May 31, 2017, 01:09:55 AM
Just a couple of questions/suggestions ...
Would it be possible to have different Bug Report (and associated child boards) for each currently supported SMF stream (eg, 2.0 and 2.1) so that it is clear which version of SMF a bug report/fix relates to.
2.1 just look on the github section you can see what bugs are fixed on their and what fixes are pending.
As for prior versions the bug report section should mention what version it is for and of course a tick if its fixed or not. Issue of course for this is that many people report a bug when infact its not an issue with the software but a mod or adjustment they have made and forgotten.
That's the thing, these were 2.0 bug reports, fixed in 2.1, not in 2.0.
But now this is off topic and has meant that the actual problem being reported here has been lost. Basically how everything seems to go with the SMF team's organisational style.
Don't worry the suggestion isn't lost. We are discussing internally. :)
That generally is little comfort :p
Quote from: BryanD on June 01, 2017, 10:40:12 AM
That generally is little comfort :p
So is your constant nagging. Respectfully, please find something more productive to do.
Please tell me you haven't confused me with Bryan.
Though the nagging is because we actually care. We've tried to prevent problems in the past, it didn't work, and we no longer have the energy to actually try to fix things. At this point the best we've got is to moan and hope that someone actually listens because we're not complaining for the sake of complaining. We're complaining because we see actual problems that need to be addressed.
I haven't confused you at all. My comment is in response to Bryan's post and Bryan's post only.
Your concern is valid and as had been said ample times in this thread, we are taking it seriously and working internally to address it.
That's the part which concerns me, though. I've been where you are, trying to resolve the problems, only to watch them drown in discussion.
Which is a while ago, has no relevance to the topic at hand and we've clearly indicated we're looking in to it and provide an update later.
In the meantime, please be patient. :)
Thank you for your understanding.
Except given everything I've seen and heard, everything still gets stuck in discussion.
Whatever :) I'll bite.
Take a step back and have a look at the progression here... Rather than even giving it a chance and be patient, you decide it's somehow a better idea to, in less than 24 hours, start making negative (and rarher irrelevant) posts about how poorly the team allegedly functions; and you've already decided for yourself that there will never be an outcome. There's no patience and no willingness to even give us the chance to discuss this report, you already assume it's lost... Let me repeat: all this in less than 24 hours after we said we're picking it up and will be looking in to it. If you posted this after a while of waiting, you'd have a point.
But if you believe this currently is constructive, helpful and showing that you care: then I'd urge you not to show your affection. :P
I know you sincerely care for SMF, but these kind of repetitive negative posts really aren't helpful in any way at all.
I'll repeat: please be patient, and you've been promised an update. Is waiting for that too much to ask? :)
We go a long way, and you know me... I tend to live up to what I promise. (Yes sometimes with a minor delay, no denying that, but this is a volunteer job after all. ;))
If a little patience and getting the chance to look at this is too much to ask, then by all means let's just mark this topic as resolved...
... Or, be constructive and positive! Give us a chance before assuming all is hell and despair. ;)
"Thanks for taking it seriously guys, I'm looking forward to hear the results of your discussion!" - sure, you're welcome. ;)
I'm still looking forward to hearing the results of your discussion.
Any news on the outcome of this discussion?
Yes, we've taken this opportunity to look at multiple facets of moderation rather than limit it to a single scope.
Essentially, for the time being we're going to do the opposite of what you suggested. Moderation in the current context will actually be more lenient.
That's not the opposite of what I suggested. I was suggesting that if it is going to be aggressive, automate it and be consistent.
This is just getting everyone be consistent with where most moderators already were ;)
I see this is still happening where old topics get bumped for whatever reason and get locked. Again, if this is going to be the moderation policy, please be consistent about it, and if you're going to do it such that old topics will be locked if bumped, save the poor moderator's time and effort by just locking all the old ones.
https://www.simplemachines.org/community/index.php?topic=545812.msg3935509;topicseen#msg3935509 for example.
Not all old topics needs to be closed, but in that particular case, the comment the user made (raising an old topic) was not neccessary at all.
Quote from: Arantor on July 15, 2017, 12:43:32 PM
I see this is still happening where old topics get bumped for whatever reason and get locked. Again, if this is going to be the moderation policy, please be consistent about it, and if you're going to do it such that old topics will be locked if bumped, save the poor moderator's time and effort by just locking all the old ones.
https://www.simplemachines.org/community/index.php?topic=545812.msg3935509;topicseen#msg3935509 for example.
Must admit, I saw this this morning and had similar thoughts. ;) To be honest I can't see what harm the additional post caused to that thread, it made me read it again, and I don't mind some of them being resurrected as long as they remain on topic.
Quote from: d3vcho(); on July 15, 2017, 01:36:48 PM
Not all old topics needs to be closed, but in that particular case, the comment the user made (raising an old topic) was not neccessary at all.
You misunderstand me. Certain team members take the view that this is inappropriate. If this is the case, it should be done by everyone. But it isn't.