Skip to content

CONTRIBUTING.adoc

Latest commit

 

History

History
73 lines (53 loc) · 3.72 KB

CONTRIBUTING.adoc

File metadata and controls

73 lines (53 loc) · 3.72 KB
Raw

Contributions

Contributions are very welcome - code, docs, whatever they might be! If this is your first contribution to an Open Source project or you’re a core maintainer of multiple projects, your time and interest in contributing is most welcome.

If you’re not sure where to get started, raise an issue in the project.

Ideas may be discussed, purely on their merits and issues. Our Code of Conduct (CoC) is straightforward - it’s important that contributors feel comfortable in discussion throughout the whole process. This project respects the Linux Kernel code of conduct.

Suggestion: More than 3 lines - talk to someone first

If you’re planning on making a change that’s more than a 3 lines, please talk to someone first (raising a GitHub issue is the best way to do that). This is so that you don’t waste your time on something that might not be accepted. It’s also a good way to get some feedback on your idea and make sure you’re on the right track.

Rule: A PR should be one logical change

Please try to keep your pull requests small and focused. It’s almost impossible to review PRs that change lots of files for lots of different reasons. If you have a big change, it’s probably best to break it down into smaller, more manageable chunks, otherwise it’s likely to be rejected.

If you’re not sure, ask!

Don’t be afraid to ask for advice before working on a contribution. If you’re thinking about a bigger change, especially that might affect the core working or architecture, it’s almost essential to talk and ask about what you’re planning might affect things. Some of the larger future plans may not be documented well so it’s difficult to understand how your change might affect the general direction and roadmap of this project without asking.

The preferred way to communicate is probably via Discord or GitHub issues.

Dev environment setup and clean build

# Step1: setup compile env
# - Fedora
dnf install git go protobuf-compiler make pre-commit -y
# - Windows with chocolatey
choco install git go protoc make python nodejs-lts -y && pip install pre-commit

# Step2: clone and setup repo
git clone https://github.com/OliveTin/OliveTin.git
cd OliveTin
pre-commit install
pre-commit install --hook-type pre-push

# Step3: compile binary for current dev env (OS, ARCH)
# `make proto` installs pinned protobuf tools in GOPATH/bin/ and uses buf to
# generate the protobuf / Connect RPC stubs.
make proto
make
./OliveTin

Go codestyle checks (`make -wC service codestyle`) use golangci-lint. Install it
with `make -wC service go-tools` if `golangci-lint` is not already on your PATH.
Lint rules live in `service/.golangci.yml`.

Getting started to contribute;

The project layout is reasonably straightforward;

  • See the Makefile for common targets. This project was originally created on top of Fedora, but it should be usable on Debian/your faveourite distro with minor changes (if any).

  • End-user documentation (AsciiDoc for docs.olivetin.app) lives in docs/ as an Antora component; the published site is built from the separate docs.olivetin.app repository.

  • Run make docs-check after changing documentation or the service configuration schema.

  • The API is defined in protobuf+Connect RPC - you will need to make proto.

  • The Go daemon is built from the cmd and internal directories mostly.

  • The webui is just a single page application with a bit of Javascript in the webui directory. This can happily be hosted on another webserver.

Mechanics of submitting a pull request

When you are ready for a PR, please see the pull request template.