Skip to content

Latest commit

 

History

History
130 lines (84 loc) · 5.93 KB

CONTRIBUTING.md

File metadata and controls

130 lines (84 loc) · 5.93 KB
Raw

Contribute to Atri framework

Thanks for your interest in contributing to the Atri framework. ✨

This page will give you a quick overview of how to get involved.

Table of contents

Issues and bug reports

First, do a quick search to see if the issue has already been reported. If so, it's often better to just leave a comment on an existing issue, rather than creating a new one. Old issues also often include helpful tips and solutions to common problems.

If you're looking for help with your code, consider posting a question on the GitHub Discussions board.

How to submit an issue?

When submitting an issue, please include the following:

  • descriptive title
  • your environment (operating system, Python version, Atri version)
  • issue label (refer labels for an overview of how we tag our issues and pull requests.)
  • Video or GIF to further explain the issue (optional)

Creating an Atri app

  1. Installation

Follow the installation guide to satisfy prerequisites and install Atri engine.

  1. Create your first Atri app

Follow the instructions here to create a simple app to get a quick introduction to the framework.

  1. Create your app

Now you are set to create powerful multi-page, responsive apps. You can review the apps built by our team to get inspiration.

  1. Deploy your app using Atri CLI or manually

Once your app is ready, you can deploy it either using Atri CLI or manually. You can follow the instructions provided in our Docs. Deployment using GitHub pages is preferred since it won't incur any cost.

  1. Submit Pull Request (PR)

Open a Pull Request with a clear title, description, demo GIF, deployed link and GitHub link.

Congratulations! You have successfully created an Atri app. Your Pull Request will now be reviewed by the maintainers and once merged, your app will be added to the made-with-atri folder.

Contributing to the code base

Please review the existing issues, pick the one that you are interested in working on and ask the admins to assign that issue to you.

If you are a newcomer, you can consider getting started with "good first issues".

How to submit a Pull Request (PR)?

A pull request should remain focused in scope and avoid containing unrelated commits. You will need npm >= 8.11.0 , node >= v16.16.0 and yarn >= 1.22.18.

Ask before submitting a pull request by creating an issue. The feature/refactored code etc. might not be aligned with current goals of the project.

Please adhere to the coding conventions used throughout a project (indentation, accurate comments, etc.) and any other requirements (such as test coverage).

Adhering to the following process is the best way to get your work included in the project:

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

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

  2. Follow the steps to build and start the development servers from this GitHub discussion.

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

    git checkout main
git pull upstream main

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

    git checkout -b <topic-branch-name>

  5. Commit your changes in logical chunks. Please adhere to these git commit message guidelines or your code is unlikely be merged into the main project. Use Git's interactive rebase feature to tidy up your commits before making them public.

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

    git pull [--rebase] upstream main

  7. Push your topic branch up to your fork:

    git push origin <topic-branch-name>

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

Cutting a release

  1. Tag all merged pull requests that go into the release with the relevant milestone. Each merged PR should also be labeled with one of the labels name tag: ... to indicate what kind of change it is. Make sure all the breaking changes are correctly labelled with tag: breaking change.

  2. Close the milestone and create a new one for the next release.

IMPORTANT: By submitting a patch, you agree to allow the project owners to license your work under the terms of the GPL v3.0 License.