Identify who owns the problem
First determine whether this concerns your code, documented usage or a project-specific problem. A public question and a ticket for maintainers need different recipients. Read contribution rules and existing questions. A technical channel does not replace contractual product support or the private procedure intended for a sensitive report.
Prepare an actionable description
Summarise the expected and actual behaviour. Record versions and steps needed to reproduce the problem with fictional data. Avoid code screenshots when text can be copied and tested. Remove secrets, personal identifiers and confidential excerpts. If a complete reproduction is unavailable, clearly describe the missing pieces instead of presenting a hypothesis as a diagnosis.
Choose between an answer and tracking
Stack Overflow may suit a precise programming question within its scope. GitHub can track a task or bug in the relevant repository. An issue does not guarantee acceptance or a fix. Check whether the project expects a discussion, form or another channel, then answer requests for detail in the same space rather than creating duplicates.
Close with an understandable outcome
If you find the cause, add information that explains the solution and its limitations. A workaround is not necessarily a project fix. Retain the affected version and distinguish completed work from open requests. A summary helps the team reuse the answer without copying the whole conversation or presenting a local trial as universal validation.
Compare roles and documented points
Roles are editorial options. Factual points have specific sources; they are not a complete service verification. The table can scroll horizontally on a small screen.
| Platform | Role to test | Documented point | Useful check |
|---|---|---|---|
| Stack Overflow | Ask a reusable programming question within the site’s scope. | Questions must concern programming within the site’s scope and be written in English. Source for this point ↗ | Prepare the question in English and explain your attempts. |
| GitHub | Track a problem or task within its project. | Issues track ideas, tasks or bugs in a repository, with organisational metadata. Source for this point ↗ | Read the expected contribution channel and existing tickets. |
Choose a trial by task
- I need to understand a specific code behaviour.
- Look for existing answers and prepare a reproducible question.
- The problem concerns an identified project.
- Read its instructions and prepare a ticket in the expected channel.
- The report includes a secret or sensitive risk.
- Use the official private procedure and remove sensitive details from public content.
Fictional example: follow the journey
Fictional example: an association finds that a booking tool mishandles a date. It reproduces the issue with a fictional booking, checks the version and existing tickets, then contacts the project through its stated channel. It does not show participants’ data in a screenshot.
Your check before choosing
0 / 6
Useful questions
Does an issue replace a Stack Overflow question?
Its role depends on the problem. A ticket tracks project work; a question seeks a reusable technical answer. Follow each space’s instructions.
Can a bug be declared fixed after a trial?
Describe the version, conditions and observed outcome. Success in one local case does not prove that every use is fixed.
Apply the comparison
- Document a project in your portfolio
- Preserve decisions made in a conversation
- Build a FAQ that answers real questions
- Put the first two profiles side by side
- Record observations from your trial
Useful terms for this journey
Sources and scope
Primary documents consulted on 10 October 2026 for the table’s points. Processes and scenarios are editorial proposals without claimed personal testing or commercial ranking. Confirm current features, plans and permissions before use.