Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
57 lines (35 loc) · 2.6 KB

CONTRIBUTING.md

File metadata and controls

57 lines (35 loc) · 2.6 KB

How to contribute to this project

Vibe Coding

Since the original author had never written a single line of Rust before this, everything here — including this README — must either be Vibe Coded directly or passed through the free tier of ChatGPT.

If you're unfamiliar with Vibe Coding, get familiar with Vibe Coding.

If OpenAI shuts down ChatGPT, we’ll rewrite this README and commit whatever is still available.

Unwanted design patterns

Please don't break the Vibe with any development methodologies, including but not limited to:

  • Waterfall
    If you want everything planned before writing your feature, you're killing the Vibe. There’s no room for spontaneity — and by the time your spec is signed off, the Vibe is gone.

  • Agile
    Have you ever felt the Vibe in a Jira ticket? How can you adapt quickly to user expectations when you're not even sure they’ve caught the Vibe?

  • Scrum
    Sorry but telling lies about how much progress you supposedly achieved in every daily meeting, or memorizing a handful of ceremonies which all look the same kind of crying over how this is all horrible should be something every project should avoid. It's even hard to joke about this one.

  • TDD
    To test it, you must measure it; to measure it, you must write it.
    Vibe Testing is allowed — but only as part of Vibe Coding. Write your code first, then ask ChatGPT to throw together some unit tests.

  • WOP (Workaround-Oriented Programming)
    WOP is fear-based, and fear kills the Vibe.
    Worse: to do WOP, you need actual knowledge of the language — and that violates our values. Don’t fear what you don’t know. Just follow the Vibe.

  • XGH (Extreme Go Horse)
    This will inevitably end up in the codebase, but please pass it through ChatGPT first.
    Honestly, it’s easier to just ask the LLM to write it than to write nonsense and beg for forgiveness. And of course, to XHG you need to know a little about the language too.

Opening Issues

If you think there’s a real bug, submit it to the actual Pro Client.

Only open issues here if:

  • this client behaves differently from the official one, and
  • that difference is worse

There is no expectation or guarantee — or hope — that it will ever be better.

Opening Pull Requests

Fork it, PR it.

Maintainers will review your submission to evaluate signs of properly written code — which may result in rejection.

We may also forward your PR to ChatGPT to validate any code that feels a little too suspicious.

Getting in touch with the maintainers

Don't.