2017-09-13 12:45:07 +00:00
|
|
|
# Contributing to status-go
|
|
|
|
|
|
|
|
|
|
First of all, thank you for taking time to add more value to Status, we really appreciate it!
|
|
|
|
|
|
2020-04-21 07:12:01 +00:00
|
|
|
If you just have a question, don't open an issue but rather ask us on our [Discord server](https://discord.gg/3Exux7Y)
|
2017-09-13 12:45:07 +00:00
|
|
|
## Starter Links
|
|
|
|
|
|
|
|
|
|
You just want to contribute something without reading tons of documentation, right? There're only a few useful links to start with.
|
|
|
|
|
|
2022-07-17 13:37:14 +00:00
|
|
|
How [status-mobile](github.com/status-im/status-mobile) uses us:
|
2017-09-13 12:45:07 +00:00
|
|
|
https://github.com/status-im/status-go/wiki/Notes-on-Bindings
|
|
|
|
|
|
|
|
|
|
Architecture: TBD in [#238](https://github.com/status-im/status-go/issues/238)
|
|
|
|
|
|
|
|
|
|
You can also discover more information in https://hackmd.io/s/SkZI0bXIb
|
|
|
|
|
|
|
|
|
|
## Workflow
|
|
|
|
|
|
|
|
|
|
1. Pick an [issue](https://github.com/status-im/status-go/issues) to work on and drop a line there that you're working on that.
|
|
|
|
|
2. Wait for an approve from one of core contributors.
|
|
|
|
|
3. Fork the project and work right in the `develop` branch.
|
|
|
|
|
4. Work on the issue and file a PR back into `develop`.
|
2017-12-14 08:55:44 +00:00
|
|
|
5. Wait until your PR is [reviewed](https://hackmd.io/s/B1AenvFU-) by 2 core developers and merged.
|
2017-09-13 12:45:07 +00:00
|
|
|
|
2017-12-14 08:55:44 +00:00
|
|
|
## Code Style
|
|
|
|
|
|
|
|
|
|
Please, note that we follow [Effective Go](https://golang.org/doc/effective_go.html) and
|
|
|
|
|
[CodeReviewComments](https://github.com/golang/go/wiki/CodeReviewComments) in our code.
|
2018-04-04 10:41:45 +00:00
|
|
|
|
|
|
|
|
## Keep history clean
|
|
|
|
|
|
|
|
|
|
1. Squash PR before merging.
|
|
|
|
|
You can do it either with GitHub API by merging with "Squash and merge" or locally if you want to preserve your signature.
|
|
|
|
|
It is ok to merge multiple commits with "Rebase and merge" if they are logically separate.
|
|
|
|
|
|
|
|
|
|
2. Preserve as much history as possible.
|
|
|
|
|
If you need to re-name file use `git mv` - it will preserve git history.
|
2024-04-08 15:47:44 +00:00
|
|
|
|
|
|
|
|
## Commit format
|
|
|
|
|
|
|
|
|
|
We use a slight variation of [Conventional commits](https://www.conventionalcommits.org/en/v1.0.0/).
|
|
|
|
|
|
|
|
|
|
We enforce the usage of `!` for breaking changes, or `_` for non-breaking. The rationale is that
|
|
|
|
|
if we don't enforce one or the other, often devs will forget to add `!` to breaking changes.
|
|
|
|
|
Forcing to add one or the other, will also hopefully force devs to make a decision with each commit.
|
