Skip to content

Latest commit

 

History

History
179 lines (108 loc) · 9.77 KB

CONTRIBUTING.md

File metadata and controls

179 lines (108 loc) · 9.77 KB
Raw

Contributing to activist.org

Thank you for contributing to activist!

Please take a moment to review this document in order to make the contribution process easy and effective for everyone involved.

Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open-source project. In return, and in accordance with this project's code of conduct, other contributors will reciprocate that respect in addressing your issue or assessing patches and features.

If you have questions or would like to communicate with the team, please join us in our public Matrix chat rooms. We'd be happy to hear from you!

Contents

Development environment ⇧

To setup your development environment, first install Docker and Docker-Compose.

Note: If you are new to Docker, as an alternative activist recommends installing Docker Desktop. Docker Desktop comes with many Docker tools and a straightforward GUI (Graphical User Interface).

Then clone this repository with the below command:

git clone https://github.com/activist-org/activist.git

Enter the created directory and start your docker images with the following:

cd activist
docker-compose up
# Or with new dependencies:
# docker-compose up --build

You can visit http://localhost:3000/ to see the development build once the container is up and running.

Those new to any frameworks or technologies who want to work on their skills are more than welcome to contribute!

Style guide ⇧

Please see the activist style guide for details about how to follow the code style for the project. We made these guidelines to assure that we as a community write clean, cohesive code that's easy to write and review. Suggestions for the style guide are welcome.

Linting ⇧

For the backend pylint-django is installed via the required packages to assure that errors are reported correctly within a Django development environment.

Issues and projects ⇧

The issue tracker for activist is the preferred channel for bug reports, features requests and submitting pull requests. activist also organizes related issues into projects.

Note: Just because an issue is assigned on GitHub doesn't mean that the team isn't interested in your contribution! Feel free to write in the issues and we can potentially reassign it to you.

Be sure to check the -next release- and -priority- labels in the issues for those that are most important, as well as those marked good first issue that are tailored for first time contributors.

Bug reports ⇧

A bug is a demonstrable problem that is caused by the code in the repository. Good bug reports are extremely helpful — thank you!

Guidelines for bug reports:

  1. Use the GitHub issue search to check if the issue has already been reported.

  2. Check if the issue has been fixed by trying to reproduce it using the latest main or development branch in the repository.

  3. Isolate the problem to make sure that the code in the repository is definitely responsible for the issue.

Great Bug Reports tend to have:

  • A quick summary
  • Steps to reproduce
  • What you expected would happen
  • What actually happens
  • Notes (why this might be happening, things tried that didn't work, etc)

Bug reports are marked with the bug label in the issues.

Again, thank you for your time in reporting issues!

Feature requests ⇧

Feature requests are more than welcome! Please take a moment to find out whether your idea fits with the scope and aims of the project. When making a suggestion, provide as much detail and context as possible, and further make clear the degree to which you would like to contribute in its development. Feature requests are marked with the feature label in the issues.

Pull requests ⇧

Good pull requests — patches, improvements and new features — are a fantastic help. They should remain focused in scope and avoid containing unrelated commits. Note that all contributions to this project will be made under the specified license and should follow the coding indentation and style standards (contact us if unsure).

Please ask first before embarking on any significant pull request (implementing features, refactoring code, etc), otherwise you risk spending a lot of time working on something that the developers might not want to merge into the project. With that being said, major additions are very appreciated!

When making a contribution, adhering to the GitHub flow process is the best way to get your work merged:

  1. Fork the repo, clone your fork, and configure the remotes:

    # Clone your fork of the repo into the current directory
git clone https://github.com/<your-username>/<repo-name>
# Navigate to the newly cloned directory
cd <repo-name>
# Assign the original repo to a remote called "upstream"
git remote add upstream https://github.com/<upsteam-owner>/<repo-name>

  2. If you cloned a while ago, get the latest changes from upstream:

    git checkout <dev-branch>
git pull upstream <dev-branch>

  3. Create a new topic branch (off the main project development branch) to contain your feature, change, or fix:

    git checkout -b <topic-branch-name>

  4. Commit your changes in logical chunks, and please try to adhere to Conventional Commits. Use Git's interactive rebase feature to tidy up your commits before making them public.

  5. Locally merge (or rebase) the upstream development branch into your topic branch:

    git pull --rebase upstream <dev-branch>

  6. Push your topic branch up to your fork:

    git push origin <topic-branch-name>

  7. Open a Pull Request with a clear title and description.

Thank you in advance for your contributions!

Localization ⇧

Those interested in contributing to localization for the app are welcome to check related issues using the localization label in the issues.

Documentation ⇧

Documentation is an invaluable way to contribute to coding projects as it allows others to more easily understand the project structure and contribute. Issues related to documentation are marked with the documentation label in the issues.

Design ⇧

The designs for activist are made using Figma. Those interest can use the discussions to make suggestions for improvements. Design related issues are marked with the design label.

Note that the linked Figma file above is the public facing designs. Those interested in improving them or contributing designs for new features are invited to contact the team on GitHub and via other means. We'd love to see a sample of your work, and if everything looks good we'll schedule a time to get connected!

All branding elements such as logos, icons, colors and fonts should follow those that are set out in activist-org/Organization. As the project is fully open source, these elements are also open for discussion. Your efforts in making activist products professional with a distinct and cohesive identity are much appreciated.