Expand asking for help guidance

Author: alexeygrigorev

courses/zoomcamp-logistics/asking-questions.md

@@ -36,6 +36,26 @@ Try to narrow the problem first. You do not need to solve it alone. A few minute
 
 It is normal for technical problems to take time. If you are stuck after trying the steps above, ask in Slack.
 
+## If You Cannot Find the Problem
+
+Sometimes the hard part is not fixing the problem. The hard part is figuring out where it starts. In that case, write down what you know:
+
+- The last step that worked.
+- The first step that failed.
+- What you expected to happen.
+- What actually happened.
+- What changed since it last worked: code, data, dependency versions, environment variables, Docker image, notebook kernel, cloud resource, or operating system.
+
+Then try to make the problem smaller:
+
+1. Run the command again from a clean terminal and copy the full output.
+2. Remove unrelated code or steps until you have the smallest example that still fails.
+3. Check whether the problem happens in the course example code or only in your own code.
+4. Check whether the problem happens after restarting the service, container, notebook kernel, or machine.
+5. Compare your command, file path, environment variables, and versions with the lesson instructions.
+
+If you still cannot identify the cause, say that in your question. "I do not know where the problem is yet, but this is the last step that worked and this is the first failing command" is a useful starting point.
+
 ## Asking in Slack
 
 Start a new message in the course channel with a short problem summary. Then put details in a thread so the main channel stays readable.

general/guidelines/asking-for-help.md

@@ -26,12 +26,41 @@ Examples of meta questions to avoid:
 
 When something doesn't work and you need help figuring it out, we'll be happy to help.
 
+Before posting, try to narrow the problem. You do not need to solve it alone, but helpers need enough information to understand where you are stuck.
+
+Check:
+
+- The exact error message.
+- The command, query, notebook cell, or action that produced it.
+- The last step that worked.
+- The first step that failed.
+- What you expected to happen.
+- What actually happened.
+- What changed recently: code, data, dependency versions, environment variables, Docker image, credentials, cloud resource, or operating system.
+
+If you do not know where the problem is, say that clearly and share what you already checked. A useful question can start with: "I do not know which part is failing yet. The last step that worked was ..., and the first failing command is ..."
+
 To get the best assistance quickly, follow these recommendations:
 
 - Use threads for errors. First describe the problem briefly in the main channel, then put the actual error message and code in a thread.
 - Copy-paste text, don't screenshot. Don't take screenshots of your code or terminal output. Instead, copy-paste the error message and code as text. Use code blocks (three backticks) to format your code. Text is searchable, easier to read, and allows helpers to copy your code if needed.
 - Never photograph your screen. Don't take pictures of your code with a phone. It's even harder to read than screenshots. Always copy-paste text. In rare cases when you need to show what happens on your screen visually (like a UI issue), a screenshot is acceptable, but code and errors should always be text.
 
+Include:
+
+- What you are trying to do.
+- The relevant context: course, project, tool, dataset, operating system, or service.
+- The exact command or action you tried.
+- The full error message as text.
+- The smallest relevant code snippet or a link to the repository when the issue depends on your code.
+- What you already tried and what happened.
+
+Use triple backticks for commands, code, and error output:
+
+<pre><code>```
+paste the error here
+```</code></pre>
+
 ## Don't tag instructors
 
 Don't tag the cohort lead or other instructors in your question. They have notifications enabled and will see questions in the course channel without being tagged. Tagging an instructor signals that the question is for them specifically. That makes other participants less likely to jump in, even though they are often the fastest source of an answer. Posting in the course channel without a tag is the right move.