I disagree. Because none of them are going to read it beforehand, regardless of length. This is something to point to when they don’t read it. The length is also because I was explaining why. Without that, people tend to dismiss advice because they cannot comprehend why it applies to them.
Also, we should link to the forum etiquette rules.
And it might be good to say something pre-emptive about code generated by LLMs? And/or using LLMs to learn.
Also, people being in a hurry and treating us as LLM answer machines is part of the problem we are trying to solve. If they don’t want to treat us as human beings and be respectful, is that something we should just put up with? Or should we try to teach them how to program and how to be a part of this community and a compassionate, thoughtful human being?
I don’t mean change the meaning or leave anything out, just lower the word count.
Definitely a good idea to add something about LLM code, linking to forum etiquette rules.
Let’s hear what others have to say, overall. It’s a communal effort, and there’s no deadline looming 
These issues go all the way back to the days of Usenet and BBS forums. There have been many attempts across many forums to mitigate these issues, but as far as I know, there is no cure.
A forum is the sum of its members. As this forums garners more popularity, addressing these issues will be like fighting the tide.
That being said, here’s my 2¢: New users here have all the direction they need to make well-formed, polite requests for help. Low effort is obvious and annoying, and most of the time it is not even worth a response. Otherwise, the course is to continue with “gentle” reminders.
I suspect that there are many young and/or inexperienced programmers who have yet to learn proper decorum. This forum can be an example for them to learn both. However, to finish with a cliche: “You can lead a horse to water…”
But if it wants to give you a gift you shouldn’t look at it’s mouth.
I like what @dragonforge-dev did with breaking stuff into bullet points. Bullet points are a good approach, but I also agree with @phoenixdk that it’s better to lower the word count and keep the language more direct and to the point. Some rudimentary explaining of “why” is ok, but too much of it dilutes the focus. It should be more like those emergency procedure checklists for airplanes: If you want good results - do that, that, that and that.
The thing should be a sticky post put up by a mod/admin. The main beneficiaries of this, beside obviously the newbies, are really the people who answer frequently. With such a text stickied, they won’t need to waste time and nerves on repeating the same stuff over and over and risk getting dismissed as “rude” when doing so. When someone posts a poorly formulated question, we can just gently provide a link to “official guidelines” and be done with it.
There should be some reminder of
“If you were directed to this page, please use the edit button to format your topic to meet the standard.”
Or just make sure you mention that when you direct someone to read the sticky (if it will exist).
If it doesn’t drink the water it was led to, soon you’ll be flogging a dead horse 
I think there should be an option to flag a post as ‘poor format/context’ and if X number of people marks the post as this, the user should be notified and sent to a page it explains how the posts are expected. The post can be invisible until it’s solved, or in the forum it can be shown that it’s marked as ‘poor’ so people won’t pay attention until it’s fixed.
Lets integrate an LLM into the forum, so it can auto format any code snippets. Everyone would be very happy.
No thanks
I should have added that it was a joke!
I’d much rather have incorrectly formatted correct code than correctly formatted hallucinated code.
Giving it a stab, too. I try to keep the language more concise and lower level, as the Godot community is scattered around the globe. I also assume that this topic will be directed more often towards newcomers and people with an entry level understanding of Godot and game dev in general. It’s a draft, i have not spellchecked it yet.
—
People want to help you solve your problem. To make that easy, you should tell them what your problem is in a clear way. Maybe somebody even sent you here to help you get help? Stick to these simple steps:
Your title should include important words about your problem. Are you having trouble with a specific function? Is there a node you struggle with? Or do you have an idea but not an implementation? If you pick the right title, you will attract the best people to help you!
Remember: don’t pick a title that says nothing about your actual problem.
There is no help, if the problem can not be understood. Take a moment to describe your problem. Remember that you know your situation, but everybody else might have never seen your project before. You also show respect for the people who help you - they give you their time.
When explaining your problem, it helps to answer a few questions: What do you want to happen? What does actually happen? Why did you design/script your problem like this? What is your Godot version? Do you have plugins?
If you have a programming problem, always show your code. No screenshots! Just code. On this forum you can format the code in a way that makes it readable for the people helping you. Copy and paste your code on the forum, mark it and push the "code” button 
or press Control+E.
You can also put your code in between these backticks, like that:
```gd
→ Paste your code here ←
```
If the editor gives you errors or warnings, this is very helpful. Post them with your problem, too!
Sometimes words are not enough and your problem needs to be seen. Especially if your problem has nothing to do with code. A great way to show your problem with nodes, for example, is to make a screenshot of your Scene Tree or Inspector. Make sure that all relevant nodes are visible and people can understand how you structured your scene. Sometimes you might even want to record a video.
A forum like this can be slow sometimes. Check back and see if people have questions or need more information to help you.
Or even better: they have a solution! Don’t forget to say thank you and mark your problem as solved. This way you also help other people!
This is all nice and pretty but I think the main problem isn’t the fact that we don’t give people enough information, it’s the fact that people choose not to read said information and just want quick, instant answers. Often with as little effort as possible.
I agree, but this is a second line of defense, meant to be used as an alternative to typing out the answers each time the problem arises. It’s as much a tool for us, as for those asking help.
You are probably right. Still, new people might as well be young, unexperienced people still learning. This sticky is more for people here to use as an unoffensive and quick response.
I still remember back around 2000 when I first got my virtual slapping on a game forum because my language was bad and my effort low. Not sure if it was german or usual attitude back in the day, but i got some whooping that changed me and my internet etiquette for the better 
If it was not for the general nice tone of this community and the Godot team, I’d recommend adding:
If you were sent here by somebody, you should get your shit together and learn how to ask questions.
I get the idea of simplifying the language for non-English speakers. That’s a really good point.
You omitted a question which is very important. “What have you already tried?”
Other than that it looks pretty good for a shortened version.
However, I think these should be verbose, because we want to point to the post, and we don’t want to have to elaborate on the post. Where do the longer explanations of why go?
I think all the highlighting reads a bit like a clickbait article, but maybe that’s a good way to grab attention? I always bold class names, buttons or menu items the person should click in instructions. In the post above, I also used bold for sub-headers. What were your thoughts on the what you highlighted?
@phoenixdk and @ximossi I also want to say this without being offensive - just as a point to consider as we discuss this. It’s clear you both have experience from other forums you’re drawing from and I respect and appreciate that experience. Between the two of you, you have a total of 10 accepted solutions on this forum. From that, I am infer that you have not seen and answered nearly as many people as I have. When I made the edits I did, it was coming from the experience of answering hundreds of posts - many times more than I have accepted answers.
I think it behooves us to find a balance between simplification, and thoroughness. I specifically made bullet points to create a checklist for people to follow. So while they’re verbose, the bold parts are the only thing someone needs to pay attention to to get it.
Maybe something like this would be a good compromise? (Keeping in mind I didn’t simplify the language yet.)
Give the topic a descriptive title that captures the problem accurately - it’s the first thing people will see of your help topic. “Problem with CharacterBody2D” is a bad title, “CharacterBody2D doesn’t trigger collision during move_and_slide()” is better.
Use the help topic template - fill in the Godot version you’re using and any plugin versions as well.
Post any code that is relevant. Resist the urge to only give the code you think is relative, and post the full script causing the problem. Please format your code correctly. Failing to do so will likely result in your first reply being a request to format your code. Do not post screenshots of code. These are hard to read on some devices, and also make it harder to get a good response. When your code is text and formatted correctly, they will often correct your code for you.
There are three ways to format code:
code block. Adding “gd” after the top set will format your code as GDScript and make it even easier to read.) in the toolbar. This is the best option for people on Mobile devices, and people using non-English keyboards. Note you can still add “gd” at the end of top three backticks to make your code even easier to read.This:
#Paste your code here
Turns into this:
#Paste your code here
Explain the problem you’re having in detail, using the 7 questions below. (Keep in mind that while a picture is worth a thousand words - that isn’t true if it’s a picture of text. Be sure to copy, paste, and format any text.)
Tell us the problem you are trying to solve. Often people post the problem with the solution to the actual problem they’re having. In Godot, there are often simple solutions to complex problems. This is especially true if you are a programmer coming from another language, or you are getting advice from an LLM. This is known as the X-Y Problem.
It may not be obvious to your readers what you think should happen. Tell us. also, do not assume that your reader has played the same games as you. Also don’t expect anyone to watch a 30 minute tutorial video to see where you went wrong.
Was this working before? On an earlier version of Godot? Or before you made a change? Did you update your video drivers recently or make other changes to your computer?
If you don’t want to get suggestions for a bunch of things you’ve already tried, tell us what you’ve done to try to fix the problem. Showing that you have spent time trying to solve the problem is more likely to get you more thoughtful responses in return.
You can copy messages from the editor directly and paste them into your post. That gives us information to help you - even if it seems unimportant or nonsense to you. Do not use screenshots. They are harder to read, and if we may need to copy and paste them to do our own research.
Add screenshots of your Scene Tree, Inspector and/or the whole Editor if you think it might be relevant. If you are new to the forum, you can make replies to your own post to add additional screenshots after the first. Do not try and recreate your Scene Tree in text. There are things we can see by the icon or color of an icon, warnings and other things that you may not notice but can help us solve your problem.
Before posting, re-read your question to make sure it’s clear and presentable - then hit Create Topic, lean back, and wait for help to arrive. If you later notice something that can be improved, you can edit your topic.
Thoughts?
I tried to highlight words to hedge a thought and mindset instead of a technical approach. I also tried to make the rhythm and word selection less predictable. Both intentions help break semi-conscious reading pattern and tend to help people stay on track reading.
This is supposed to be an alternative approach to your cleaner and more technical draft, which I personally like more, to be frank.
It does, and was meant to. I agree with @tibaverus sentiment, that we might not need another informative text to deliver actual information. I tried to express my intention above: grab the little attention there is and try to influence the vector a bit. I try to carb my expectations about actually improving anything, though.
No offense taken - your contribution to this forum is amazing and obvious. Your help was some of the first I experienced here first hand and I learned a lot from your resources. Honestly: for me this topic is more about effectively acknowledging the lack of return (in terms of respect and attribution) and mitigating that, than actually help random people dropping in and asking questions like this is a big chat bot, to never return again.
I like it. As you mentioned, language could be a bit easier, but I like the idea of toggles. In this format it could actually be a replacement for the current topic template.
Also, I’d like to express my personal opinion, that moderation is lacking heavily. I understand the problem of the Foundation not having resources for this and volunteer work being what it is. I do think though, that if there was moderation blocking threads with low effort this would mitigate the feeling actual contributors to the community here have. It’s an elitist approach but i have seen it work again and again in so many different fields.
I’d prefer using regular headings and bullet points, the > foldouts seem to me like they’re optional - you look for the one you need to read and then expand that. If the intention is to read everything, they just introduce unnecessary mouse clicks.
Bold text can be good for drawing attention to a word or phrase, but the more it’s used, the less of an effect it has. Consider a sentence:
The first version is silly, there’s more highlighted than not, which defeats the purpose.
The second version highlights the keywords, but doesn’t distinguish between them (they’re all equally important in formatting terms)
The third version highlights only the meaning of that sentence - the other words could be removed without changing the meaning.
That’s great! I was drawing on a master’s degree in mediated communication, but let’s not appeal to any kind of authority - we’re all working together to create the functionally best guide that we can.
Exactly