Contribute to a library
Each library has its own repository, its own conventions and its own contributing guide. Where to start, for each one.
Each library is a repository of its own, written the way its language expects, by the people who use it there. A change to what a function does starts in the shared contract; everything else (a bug in one library, its code, its tests, its release) starts in that library's repository, under its own contributing guide.
- JavaScriptContributing guidegithub.com/brazilian-utils/javascriptWhat it still misses
- PythonContributing guidegithub.com/brazilian-utils/pythonWhat it still misses
- GoOpen an issuegithub.com/brazilian-utils/goWhat it still misses
- RubyOpen an issuegithub.com/brazilian-utils/rubyWhat it still misses
- RustContributing guidegithub.com/brazilian-utils/rustWhat it still misses
- .NETOpen an issuegithub.com/brazilian-utils/dotnetWhat it still misses
- ErlangOpen an issuegithub.com/brazilian-utils/erlangWhat it still misses
- Your language?Not here yet? The contract, the test cases and the tooling are already written. A library in a new language starts with one function.Start a library in a new language
What goes where
- A function that a library lacks, or a case it fails. The gap is already listed on the library's page and, usually, as an issue in its repository with the reference code. Fill a gap in a library walks through it.
- A change in what a function does, in every library at once: a new rule, a new case, a new function. That is a change to the contract: Change the contract.
- A library in a new language. Start a library in a new language.
- A library's example on this site. The examples come from the library's own
docs/usage/files: Usage files.
Edit on GitHub
Last updated on
