Skip to content

Latest commit

 

History

History
237 lines (158 loc) · 11 KB

CONTRIBUTING.md

File metadata and controls

237 lines (158 loc) · 11 KB
Raw

CONTRIBUTING

Thank you so much for thinking of contributing to the ocelot.social project! It's awesome you're here, we really appreciate it. :-)

Getting Set Up

Instructions for how to install all the necessary software and some code guidelines can be found in our main Readme or in our documentation.

To get you started we recommend that you join forces with a regular contributor. Please join our Discord instance to chat with developers or just get in touch directly on an issue on either Github or Zenhub:

We also can have pair programming sessions for you! We feel this is often the best way to get to know both the project and the team. Most developers are also available for spontaneous sessions.

Development Flow

We operate in two week sprints that are planned, estimated and prioritised on Zenhub. All issues are also linked to and synced with Github. Look for the good first issue label if you're not sure where to start!

We try to discuss all questions directly related to a feature or bug in the respective issue, in order to preserve it for the future and for other developers. We use Discord for real-time communication.

This is how we solve bugs and implement features, step by step:

  1. We find an issue we want to work on, usually during the sprint planning but as an open source contributor this can happen at any time.
  2. We communicate with the team to see if the issue is still available. (When you comment on an issue but don't get an answer there within 1-2 days try to mention @Ocelot-Social-Community/core-team to make sure we check in.)
  3. We make sure we understand the issue in detail – what problem is it solving and how should it be implemented?
  4. We assign ourselves to the issue and move it to In Progress on Zenhub.
  5. We start working on it in a new branch and open a pull request prefixed with [WIP] (work in progress) to which we regularly push our changes.
  6. When questions come up we clarify them with the team (directly in the issue on Github).
  7. When we are happy with our work and our PR is passing all tests we remove the [WIP] from the PR description and ask for reviews (if you're not sure who to ask there is @Ocelot-Social-Community/core-team which pings all core developers).
  8. We then incorporate the suggestions from the reviews into our work and once it has been approved it can be merged into master!

Every pull request needs to:

  • fix an issue (if there is something you want to work on but there is no issue for it, create one first and discuss it with the team)
  • include tests for the code that is added or changed
  • pass all tests (linter, backend, webapp, code coverage, end-to-end)
  • be approved by at least 1 developer who is not the owner of the PR (when more than 10 files were changed it needs 2 approvals)

Contribution Flow For Open Source Contributors

See contributing in main README.md

The Team

There are many volunteers all around the world helping us build this network and without their contributions we wouldn't be where we are today. Big thank you to all of you!

You can talk to our core team on Discord. And on Github you will mostly run into our core developers:

  • Ulf (@ulfgebhardt)
  • Moriz (@Mogge)
  • Wolle (@Tirokk)
  • Alex (@ogerly)
  • Hannes (@elweyn5803)
  • Mathias (@mahula)
  • Markus (@maeckes#1133)

Meetings and Pair Programming Sessions

Times below refer to German Time – that's CET (GMT+1) in winter and CEST (GMT+2) in summer – because most ocelot.social Community core team members are living in Germany.

Daily standup

  • every Monday–Thursday 11:30 am (german time see above 👆🏼)
  • in our Discord Office Cube
  • all contributors welcome!
  • everybody shares what they are working on and asks for help if they are blocked

Philosophy

We practice collective code ownership rather than strong code ownership, which means that:

  • developers can make contributions to other people's PRs (after checking in with them)
  • we avoid blocking because someone else isn't working, so we sometimes take over PRs from other developers
  • everyone should always push their code to branches so others can see it

We believe in open source contributions as a learning experience – everyone is welcome to join our team of volunteers and to contribute to the project, no matter their background or level of experience. To support your learning experience we founded the charity association busFaktor() e.V..

We use pair programming sessions as a tool for knowledge sharing. We can learn a lot from each other and only by sharing what we know and overcoming challenges together can we grow as a team and truly own this project collectively.

As a volunteer you have no commitment except your own self development and your awesomeness by contributing to this free and open-source software project. Cheers to you!

Programming

Localization

Quotation Marks

The following characters are different from the programming quotation mark:

" or \"

Please copy and paste the following quotes for the languages:

Docker – More Closely

Apple Silicon Platform

ATTENTION: For using Docker commands in Apple Silicon environments!

Environment Variable For Apple Silicon Platform (M1, M2 Chips)

If you encounter trouble building the docker containers on an Apple M1 chip you can try to explicitly define the target platform docker builds and pulls images for:

# set env variable for your shell
$ export DOCKER_DEFAULT_PLATFORM=linux/amd64

Or alternatively use a YAML docker compose overwrite file with platform: linux/amd64.

Analyzing Docker Builds

To analyze a Docker build, there is a wonderful tool called dive. Please sponsor if you're using it!

The dive build command is exactly the right one to fulfill what we are looking for. We can use it just like the docker build command and get an analysis afterwards.

So, in our main folder, we use it in the following way:

# in main folder
$ dive build --target <layer-name> -t "ocelotsocialnetwork/<app-name>:local-<layer-name>" --build-arg BBUILD_DATE="<build-date>" --build-arg BBUILD_VERSION="<build-version>" --build-arg BBUILD_COMMIT="<build-commit>" <app-folder-name-or-dot>/

The build arguments are optional.

For the specific applications, we use them as follows.

Backend

Production For Backend
# in main folder
$ dive build --target production -t "ocelotsocialnetwork/backend:local-production" backend/
Development For Backend
# in main folder
$ dive build --target development -t "ocelotsocialnetwork/backend:local-development" backend/

Webapp

Production For Webapp
# in main folder
$ dive build --target production -t "ocelotsocialnetwork/webapp:local-production" webapp/
Development For Webapp
# in main folder
$ dive build --target development -t "ocelotsocialnetwork/webapp:local-development" webapp/