I was redirected to creating this topic by the Dev Engagement Team.
Greetings,
This issue has been prevalent in #help-and-feedback:scripting-support, where people just copy-paste their entire programs instead of pinpointing the error/focus of the topic. This leads to the topic staying dormant until a daring user volunteers to read through all of that and find the issue.
Not only that, if the OP is able to present their problem in a readable manner, it shows how much they care about getting assistance with it. Otherwise, it’s just like “here’s everything, now help me.”
Currently, in the guidelines, it does say not to ask for entire scripts, but it shouldn’t also be said not to post entire scripts. It should add:
Additionally, please do not post entire scripts, instead, pinpoint the lines error. You should also state what each variable/function does to provide context.
This will benefit both the OP and the viewers, who can easily spot the error and help fix it.
I agree with you. When I go into #help-and-feedback:scripting-support, sometimes I see people paste about 100 lines of code without clearly showing where the problem is. The rules about posting entire scripts aren’t that clear and they should be rewritten to remind people not to post entire scripts.
Making a rule against posting an entire script would also cause problems when your script isn’t that big; an example is when it’s only like one function that only does it small list of things. Maybe instead of outright not being allowed to post an entire script there should be like a maximum number of lines that you can post or something like that.
OP obviously meant significantly large ones, I don’t think a 10-line script being the whole thing is a problem, but when that multiplies, it can become a problem. In general you should be providing an MCVE of the problem.
This might cause an issue of pretty much banning people that barely understanding scripting from asking for help because often, if someone barely understands their own code or barely understands the issue, they’d post too much information.
The OP can edit the post, so you could reply to ask them to narrow it down if possible. If they can’t, then help them debug by having them add breakpoints / prints and by making sure they check the Output for errors AND warnings.
I don’t think it would or should result in a ban. There’s almost no correlation with someone’s ‘understanding’ and posting lengthy scripts. The support categories have criteria/ expectations, which try to narrow down your problem anyways. You should actively try to debug your code if you’re unsure what the specific issue is.
this would affect topics like: “How do I debug this?” or “I’m not sure how to debug, but …” or “I’m new at scripting, why doesn’t this work?”, the topics from people that don’t know where to start in debugging or don’t understand debugging
with this rule, instead of just being too lazy to help, you’d report them and end up removing the topic
When I said “prohibit,” it’s just going to add to the guidelines. Nothing in any of the guidelines are always taken strictly, e.g. people still ask for scripts despite the guidelines advising against that. Plus, not all scripting support topics fit the three-step model the guideline provides (e.g. asking for assistance in understanding API), but it is still “legal” in DevForum terms.
The types of topics you mentioned are very niche. If users are having a hard time debugging, then they often show screenshots of the output, which helps others find the lines of error.
And for the record, I don’t think anyone reports topics that don’t exactly follow the guidelines. This would mean that all those single-lined topics asking “how to create X” would get flagged, which I haven’t seen happen.