Failure Company
Participation guidelines

Build in your own time.
Leave a path for others.

We stay connected through public repositories, issues, and pull requests. No separate chat group or daily attendance. Bring what you know, ask for what you need, and make it easier for someone else to join in.

Explore community activity →Browse the GitHub topic ↗
01 / Make your project discoverable

Start with a repository.

An unfinished project is welcome. Give people enough context to understand it.

  1. Create or choose a public project

    Use a repository you own or have permission to manage. Keep credentials, private information, and former employers’ code out of it.

  2. Add the topic failure-company

    On your repository’s main page, edit the About section and add the topic. You do not need to star a repository to participate.

  3. Make the README useful

    Explain who the project helps, what works today, how to run it, and what help you would appreciate. State the license and contribution expectations clearly.

  4. Keep the next step visible

    Open a focused issue for a task or question. Use labels such as “help wanted” or “good first issue” when they accurately describe the task.

02 / Work asynchronously

Ask clearly. Give people time.

One request, enough context

Describe what you tried, what happened, and what help would unblock you. Link to the relevant code or demo and say what a useful response looks like.

Agree before a large change

Check existing issues first. Offer a small contribution, discuss the approach, and agree on scope. Testing, writing, design, and review are valuable contributions too.

Make availability explicit

Say when you usually check replies. No immediate responses are expected. If you need to step away, leave a short handover so someone else can continue.

A useful request for help

“I’m building [tool] for [person/problem]. [Feature] works, but I’m stuck on [specific issue]. I’ve tried [approaches]. Could someone help with [small request]? Here’s [link]. I usually check replies [availability].”

03 / Share what you learn

Progress is worth sharing.

Posting on social media is optional. Working quietly counts too.

  • Use #FailureCompany on X or LinkedIn. Share a demo, a lesson, a question, or an approach that failed. Include the repository link when there is one.
  • Keep the useful details with the project. Put decisions and actionable feedback in GitHub issues or pull requests so people can find the context later.
  • Choose what you make public. Credit collaborators and ask before sharing their information. You never need to explain personal circumstances to participate.

Social highlights are curated. A public submission repository has not been announced yet; using the hashtag does not guarantee a feature.

04 / Care for the people doing the work

Respect, credit, and clear agreements.

Give feedback on the work without attacking the person. Agree on time, ownership, credit, and any payment before collaborating. Participation is voluntary; a community project should never quietly become an expectation of unpaid commercial work.

Project maintainers decide what to merge. If a conversation becomes abusive, disengage and use the platform’s reporting tools. Respect requests to stop contacting someone.

Discoverable doesn’t mean reviewed.

The founder will scan tagged repositories as time permits. GitHub projects appear automatically by topic; social posts are selected separately. Neither listing nor participation guarantees a review, endorsement, job, or placement.

See what’s taking shape →