Recently I’ve noticed a few cases where someone needed help with setting up or installing something (whether Python itself, Pip, a third-party package…) - but instead of making a new thread, they posted in an existing thread that appears to be about the same or a similar problem, but experienced by someone else with perhaps a completely different environment/diagnostics. Typically this happens a long time after the original case is resolved (or abandoned), and at most tangential reference is made to that case.
Is it intended that the forum should be used this way, or are people expected to use new threads to get individualized help?
Should I be flagging such new posts to request moving them to new threads?
I’ve seen this commonly as well—this seems to be much of the basis for the sentiments expressed in this thread, for what it’s worth.
Requesting them be moved to new threads seems reasonable to me. Additionally reducing the inactivity threshold for warning to 2 months (or maybe even ≈32 days) as well as perhaps considering an e.g. 6 month (or perhaps less) auto-close for threads in the Python Help section specifically, would help reduce this happening in the first place without requiring more manual moderator burden (which other moderators have previously expressed concerns about).
What do you think, @davidism ? And what about other community members (particularly those, like yourself, active in helping out in Python Help where this problem is concentrated)?
In my experience, moderators have been very responsive when flagging threads/posts. Flagging seems to be the way to go. Automatic closing is not the solution; things change, and a thread marked as solved today may not be so tomorrow.
Sure, but the difference is that there will almost always be additional context to the request. If a person isn’t responding within 60 days, I think it’s reasonable to have them open up a new thread asking for help.
And if it’s a new person, that person is almost always better suited to posting a new request/question with the context relevant to their specific problem.
Again, this is my opinion specifically with regards to Python Help .
But StackOverflow has a specific design goal that’s different than Python-Help. StackOverflow is trying to create an evergrowing repository of specific questions with specific answers… a living knowledgebase, as it were. If a question already has an established solution on SO, those threads get closed and then redirected towards the existing solution.
Python-Help is different. There are no guidelines/standards for people to post looking for help. We don’t require that the question be unique. People are more than willing to offer teaching advice to basic questions. Many of the threads in Python-Help would be closed on Stack Overflow.
Right, but (as @kknechtel can perhaps expand more on, being a top SO contributor), SO is a question/answer site that is specifically designed to curate and update knowledge like this, and not be a help forum for individual users like this Discourse. In practice, I’ve found long threads with lots of answers, especially ones that change over the years, to be incredibly hard to navigate and find the gems in the rough, especially for beginners, and tend to mislead more often than help. Without major changes to the site structure, rules, moderation and tools, we’re not really equip to do that effectively, and Stack Overflow already fulfills that niche far better than we could.
I’m rather a curator and meta participant nowadays; I no longer write new answers there (although I have occasionally updated some old ones). Hopefully I will be able to phase that out in the long run as well, and see superior alternatives catch on.
That said, you have the right idea generally, and @adamsilkey puts it very well also.
For that matter, where Stack Overflow has fallen short of its goals (or collapsed in upon itself, or gained a bad reputation for “toxicity” - whatever that is), a large part of that has to do with the user base not recognizing how different the site is intended to be from a traditional discussion forum. That’s the risk of allowing user-generated content, and putting up a big shiny “Ask a Question” button, and offering social-media style “likes”. Codidact is taking many measures to improve how all of that works, and has the benefit of a meta community that’s learned from Stack Overflow’s experience. However, it’s still very small, and where it seems to be doing well could simply be because it hasn’t been properly tested yet.
One thing we can do is make pinned threads to describe the most common issues people need help with here (which may not be the same as the most commonly re-asked questions on Stack Overflow) and give general advice for troubleshooting (which can be challenging to express in the Q&A format). If a hundred people have the same problem in slightly different contexts, but 90 of them could figure out the problem without a detailed back and forth if they read through a specific guide first, that potentially saves a lot of effort. And then the other ten can explain where they’re still stuck, or ask further clarifying questions (and maybe the guide thread even gets improved as a result). And, of course, if someone overlooks the pinned thread, we can start out by just pointing it out instead of launching into the usual process.
Just noting that the lack of marking a help thread as solved, long threads, and many duplicates for the same problem, among others, have prevented me from contributing further in the Help category. It creates a sense of futile effort, or, in other words, wasting time!
In the case of Stack Overflow, all important questions are answered. It takes hours to find a ‘real’ problem to solve. Most of the unanswered questions involve the implementation of specific applications, not worth the effort to answer, or are too complex.
We can see these cases as extremes of one another. The lack of site features discourages user helping, while a site with all necessary features ensures problem exhaustiveness. The latter is preferable.
Don’t forget, though, that that category is NOT purely a Q&A help request category. It’s the “General” category too. Not everything in there is a help request.
I didn’t even realize that. Naming the forum ‘Python Help’ implies that it’s a forum about (giving/receiving) Python Help. The description underneath should support the name of the forum, not redefine what it is.
I didn’t even realize that. Naming the forum ‘Python Help’ implies
that it’s a forum about (giving/receiving) Python Help. The
description underneath should support the name of the forum, not
redefine what it is.
Well, it was renamed to Python Help because newcomers kept
overlooking the general Users category and instead asked off-topic
support questions in other parts of the forum (e.g. Python Software
Foundation, Core Development, Core Workflow…). If you notice, the
URL stub for the topic is still “users” in fact, revealing a bit of
For reference, this was the full discussion that eventually lead to that:
As I alluded to previously, some (including myself) proposed adding a new #general category in addition to renaming the Users category to Python Help, but at the time it was decided to just do the latter change and defer the former.
In light of the proposed changes here to better tailor Python Help toward user questions, perhaps its time to reconsider it, as following that there did appear to be a fair bit of support for the former idea (and it seems at least to me that we’ve gotten more non-Python-Help threads in Python Help over time, and more threads that start out in other specialized categories but don’t end up meeting the bar for their requirements get moved to Python Help .
I’m for adding an automatic lock on help topics. There are two types, a set time limit after the initial post, or a set time limit after the last post, which I think is more appropriate in the help category. I’d even consider 1 month after the last post enough time. A post can always be flagged if it does need to be reopened.
For the projects I maintain, I have a workflow that locks issue and PR discussion on closed/merged issues after 2 more weeks of inactivity. Before implementing this, I found that it was a pretty big amount of my time was spent re-examining years old issues that received new “me too” style comments. Users often seemed to have trouble distinguishing their own error from an existing one that may have sounded similar when they were first searching. Even if it was the same error, the code or design decisions had often significantly changed since the original issue, or the original issue itself wasn’t written clearly. In all cases, it was easier for us to review a new issue with fresh details. The user could still link to old issues if they felt they were relevant. Adding this lock workflow greatly reduced the number of notifications we got, while not actually reducing the number of bugs and features being worked on.
I guess what’s not clear at the moment is whether the “Python Help”
topic is just a help topic now, or whether it’s still also the
general Users discussion topic as its description continues to
imply. After all, it was merely renamed from Users to Python Help in
order to get people who have help requests to post there and not in
random other topics instead.
Maybe, as has been pointed out by others, this is yet more fuel for
revisiting the previous decision on having help and general
discussion share one topic rather than splitting them into separate