There are many ways to contribute to Syntropy! You can contribute code, and make improvements to the documentation by suggesting any changes. This guide provides everything you need to get started. Our most common contributions include code, documentation, and community support.

Write code.
Improve tests.
Improve documentation.
Answer questions on our Discord
Participate in the discussion on our Discord
Investigate bugs and issues on GitHub.
Review and comment on pull requests from other developers.
Report an issue
Give a “thumbs up” 👍 on issues that are relevant to you.
Reference Syntropy in your blogs, papers, and articles.
Talk about Syntropy on social media.
… even just starring/forking the repos you like on GitHub!

We open-sourced some repos in the hope of sharing technology with the external community and encouraging collaboration between researchers and industry. Since then, Syntropy has grown into a thriving ecosystem of products, on a wide range of platforms. But our goal is still to make better, faster, and safer Internet connections accessible to anyone, anywhere.

Where to contribute?

Integration Repos

Agent

https://github.com/SyntropyNet/syntropy-agent

How to contribute?

We’re really happy you’re reading this because we need volunteer developers to help Syntropy grow and change the Internet! All public repos are available for your contribution here https://github.com/SyntropyNet/

Bugs

Did you find a bug?

If you find a bug in the source code, you can help us by submitting an issue to our GitHub Repository. Even better, you can submit a Pull Request with a fix.

Cosmetic patch

Reports for whitespace, format code, or making a purely cosmetic patch will be ignored.

Features

Adding a new feature

You can request a new feature by submitting an issue to our GitHub Repository.
If you would like to implement a new feature, please consider the size of the change in order to determine the right steps to proceed:

For a Major Feature, first, open an issue and outline your proposal so that it can be discussed.
This process allows us to better coordinate our efforts, prevent duplication of work, and help you to craft the change so that it is successfully accepted into the project.

Note: Adding a new topic to the documentation, or significantly re-writing a topic, counts as a major feature.
Small Features can be crafted and directly submitted as a Pull Request.

Changing existing feature

Submit the issue explaining what exactly you want to change in an existing feature and why.
Create a PR with descriptive content about why and what you want to change.

Testing

Make sure all the changes in code are reflected in well-written tests, followed by the standards of existing tests in the repo.

Submitting

Always write a clear log message for your commits.

Submitting an Issue

Before you submit an issue, please search the issue tracker. An issue for your problem might already exist and the discussion might inform you of workarounds readily available.

We want to fix all the issues as soon as possible, but before fixing a bug, we need to reproduce and confirm it. In order to reproduce bugs, we require that you provide minimal reproduction. Having a minimal reproducible scenario gives us a wealth of important information without going back and forth to you with additional questions.

A minimal reproduction allows us to quickly confirm a bug (or point out a coding problem) as well as confirm that we are fixing the right problem.

We require minimal reproduction to save maintainers' time and ultimately be able to fix more bugs. Often, developers find coding problems themselves while preparing a minimal reproduction. We understand that sometimes it might be hard to extract essential bits of code from a larger codebase, but we really need to isolate the problem before we can fix it.

Unfortunately, we are not able to investigate/fix bugs without a minimal reproduction, so if we don't hear back from you, we are going to close an issue that doesn't have enough info to be reproduced.

Submitting a Pull Request

Before you submit your Pull Request (PR) consider the following guidelines:

Search the repo for an open or closed PR that relates to your submission.
You don't want to duplicate existing efforts.
Be sure that an issue describes the problem you're fixing, or documents the design for the feature you'd like to add. Discussing the design upfront helps to ensure that we're ready to accept your work.
Fork the repo.
In your forked repository, make your changes in a new git branch:
```
git checkout -b my-fix-branch master
```
Create your patch, including appropriate test cases.
Follow our Coding Rules.
Run the full test suite and ensure that all tests pass.
Commit your changes using a descriptive commit message.
Adherence to these conventions is necessary because release notes are automatically generated from these messages.
```
git commit --all
```
Note: the optional commit -a command line option will automatically "add" and "rm" edited files.
Push your branch to GitHub:
```
git push origin my-fix-branch
```
In GitHub, send a pull request to themaster or main branch.

Reviewing a Pull Request

Syntropy team reserves the right not to accept pull requests from community members who haven't been good citizens of the community. Such behavior includes not following Code of Conduct and applies within or outside of Syntropy-managed channels.

Coding conventions

We optimize for readability:

We indent using two spaces (soft tabs)
We ALWAYS put spaces after list items and method parameters ([1, 2, 3], not [1,2,3]), around operators (x += 1, not x+=1), and around hash arrows.
This is open-source software. Consider the people who will read your code, and make it look nice for them.
All features or bug fixes must be tested by one or more specs (unit tests).

Why GO

Every programming language has pros and cons, but the motivation for GO is:

allows quick and easily refactor of code and making big changes fast. That's a huge benefit for projects that are in the active development stage;
is very effective and uses fewer resources if compared with scriptable languages;
compiles to a single binary without dependencies;
is a quite simple language and in this project, we like KISS principle.

Why don't you rewrite it in Rust

It may or may not happen in the future. But right now see Why GO and why not Rewrite It In Rust.

Translations

We’re more than happy to welcome all the languages, so all the resources can reach to many different destinations. You can help by translating the documentation and our Readme files on our public repositories.

If you have any questions, feel free to reach out to us in our Discord and we will be happy to assist you.