The following texts were partially or completely generated with the help of generative AI models.
Or: If you want help, you should motivate the helpers positively.
When you post a technical question in a forum and want an answer to it, there are many things you can do wrong. But also many things you can do right. Well-described problems with sufficient information and relevance are usually answered gladly. They also provide seed crystals for interesting discussions, because often there is more than one good answer. This article is written from the perspective of a community member who frequently helps out with questions in the forums. On the one hand it draws on my experiences from SAP's SCN forum, and on the other hand on my professional experience so far in software development.
When I like to help
Anyone who wants help in forums should be aware that the answers come from members of the community. These people work voluntarily and without any compensation. They spend their time on your questions—time they could also spend with their family or on other hobbies. I like to help when I can tell that the person asking:
- already knows their way around the topic. But if the basic qualification is missing, then I'm not going to waste my time on the questions, am I?
- has made an effort with the question. Complete sentences, good formatting—including of source code—examples, screenshots etc. help a lot! For further details see below.
- doesn't want to have their work done by others. Sometimes it's not about the spark of an idea or a problem, but about wanting entire programs.
- has themselves already contributed something to the forum at some point.
- has thanked people for other answers and accepts the answers.
Tips for a high probability of getting a suitable answer
In detail I have the following pieces of advice. I have numbered them so that I can refer to them in blogs:
1. Say thank you for all answers
Even if the question wasn't answered exactly: someone took the time for your problems and tried to help. A short thank you is an expression of politeness. Keep in mind: the next time you ask, your behavior on other questions can simply be viewed in your profile.
2. Accept the best answer
If an answer solves your problem or at least answers the question, then you should also accept it. If you rarely or never do this, then it clearly shows in your profile, see the image at point 1.
3. Be polite and correct
A forum is not a chat. A friendly salutation, combined with correct spelling and complete sentences, increases the joy of reading. But the formatting shouldn't fall short either.
4. Don't ask anything that can easily be found on Google or in SAP OSS
Google is your friend. Many questions have already been asked at some point. And, above all, answered. Anyone who asks a question for the tenth time shouldn't be surprised if no one wants to answer. And for many questions and problems from the SAP environment there are official answers from SAP. The (SAP ONE Support Launchpad)[https://launchpad.support.sap.com/] is an extensive source for this.
A look into the (SAP Help)[https://help.sap.com] should also happen beforehand.
5. Format the content and above all the source code
In the SCN forum there are good options for formatting the content. With headings, emphasis and code fragments you can significantly increase readability. Posting source code as normal text is a cheek.
With the means of WYSIWYG, however, you can also format nicely and structure your questions.
6. Write down all relevant information
Often the necessary information for answering is missing. That's a shame, because then you first have to ask again. That costs time. So better to put a bit more information into a question than too little.
6.1. What is the context of the question
Which system, release level, programming language or framework is it actually about? For some questions you can only guess at the programming language used from the syntax. Does a question about CDS, for example, refer to HANA CDS or ABAP CDS?
6.2. What is your expectation or requirement?
This is an important point that is often skipped entirely. Details are important here. Best with concrete examples. Because only when the question is really clear can you answer sensibly.
6.3. How can the error or problem be reproduced
Step by step.
6.4. Add complete screenshots
People like to crop out the "relevant" parts. But important information is often lost in the process. Better to include complete screen shots. Depending on the system, with status bar, URL and everything that goes with it. Sometimes important information comes out of that. If you want to point at something, best to highlight it with a drawing program, e.g. with a red frame.
6.5. Add complete source code
An excerpt is usually not enough to understand everything.
What have you already tried?
If you have already tried out solution approaches yourself, you should also describe them. What were the errors or problems with them.
6.6. Add dumps and error messages in full
Please as complete as possible. Anyone who only sends an excerpt in which they themselves couldn't find a solution shouldn't be surprised if others can't find anything either. For SAP short dumps, please export everything as a file. It's a treasure trove of information and many problems can already be clearly recognized from it. For error messages always include the long text as well. Preferably in full as text and as a screenshot.
