Skip to content
GitShowcase Forum
SearchAsk a question

GitShowcase Forum guidelines for asking and answering

These guidelines keep the forum useful to read and safe to post in. A thread is public and searchable long after it is written, so write each one for the next developer who lands on it with the same problem. By posting you agree to follow these rules.

Write a question that can be answered

Questions that get answered fastest follow the same pattern.

  • Say what you are building and what you expected to happen.
  • Include versions. Runtime, framework, library, CLI and platform versions, plus the operating system or runner image if it could matter. "Latest" is not a version.
  • Quote the exact error. Copy the message and the stack trace as text, not a paraphrase and not a screenshot of text.
  • Show what you tried and what changed each time.
  • Trim to a minimal example. A twenty line config that fails beats a link to a whole repository.

Put code, config, logs and commands in fenced blocks with the language named, and keep long output to the relevant lines.

Never paste secrets or customer data

Do not post API keys, access tokens, session cookies, private keys, webhook signing secrets, passwords or connection strings. That includes a "partly hidden" key where enough characters remain to be useful, and a connection string with the password removed but the host, user and database name intact. Do not post customer data, real email addresses, logs with personal details or production database dumps. Replace values with obvious placeholders such as YOUR_API_KEY and db.example.com.

If you pasted one

Rotate the key first. Revoke it at the provider, issue a new one and update your deployment. Only then write to editorial@gitshowcase.com with the address of the post so moderators can hide it. Hiding a post does not make an exposed key safe: assume that anything posted publicly was copied within moments. Check your provider's usage logs for activity you do not recognize, and if the key sat in a public repository, treat it the same way.

  • Promote your own work only in Show Your Project for Feedback. In every other section, mention your project only when it directly answers the question, and say that it is yours.
  • No affiliate or referral links, and no links that pay the poster for a click or signup. Posts containing them are removed.
  • Disclose if you work for a vendor you recommend, or have been paid or given an account by one. A recommendation from an employee can still be correct, but readers should be able to weigh it.
  • Link to sources. A vendor document, changelog entry or spec is worth more than a claim. Say which version or date the source applies to.

Answering

Good answers explain the cause, not only the fix. Show the command or config that works and name the version you tested on. If you are guessing, say so. If advice depends on a plan, a region or a recent change, say that too, because limits and defaults move. Staff answers carry a staff label and aim to cite documentation and changelogs. Member answers are personal experience and are not checked before they appear.

Accepted answers

In question and answer sections, the person who asked can mark one reply as accepted. It rises to the top of the thread and tells later readers what solved it. Mark one only when it worked for you, and unmark it if it stops being true. Moderators can mark or clear an accepted answer when the asker has left. An accepted answer is not a guarantee: read the date and the versions before relying on it.

Be kind to people learning

Many people here are early in their careers. Answer the question that was asked, explain the term you would otherwise skip, and do not mock a gap in knowledge or a messy repository. Feedback in Show Your Project should be specific and actionable: say what works, then what to fix first and why. Harassment, insults and gatekeeping are removed.

You can discuss how licenses work in general. Posts are not legal advice, and no one here can tell you what is safe for your company or your contract. See the terms.

What moderators do

Moderators may edit, move, lock, hide or remove posts, redact secrets and personal details, limit an account or ban it. We try to explain what we did but do not always have to. We remove spam, promotion outside the allowed section, affiliate links, copied content, off topic posts and anything that exposes private data. To report a post, email editorial@gitshowcase.com with its address. Staff corrections are shown as visible notes in the thread rather than silent edits.

Questions about these rules are welcome on the contact page. To see where a topic belongs, read the about page.

Updated