Skip to content

Latest commit

 

History

History
253 lines (166 loc) · 14.2 KB

CONTRIBUTING.md

File metadata and controls

253 lines (166 loc) · 14.2 KB
Raw

Contributing to easygraph

First off, thanks for taking the time to contribute!

The following is a set of guidelines for contributing to easygraph on GitHub. These are mostly guidelines, not rules. Use your best judgement, and feel free to propose changes to this document in a pull request.

Table of contents

How to contribute

How to contribute

Reporting bugs

This section guides you through submitting a bug report for easygraph. Following these guidelines helps maintainers and the community understand your report, reproduce the behavior, and find related reports.

Before creating bug reports, please check this list to be sure that you need to create one. When you are creating a bug report, please include as many details as possible. Fill out the required template, the information it asks helps the maintainers resolve the issue faster.

Note: If you find a Closed issue that seems like it is the same thing that you're experiencing, open a new issue and include a link to the original issue in the body of your new one.

Before submitting a bug report

  • Check that your issue does not already exist in the issue tracker.

How do I submit a bug report?

Bugs are tracked on the official issue tracker where you can create a new one and provide the following information by filling in the template.

Explain the problem and include additional details to help maintainers reproduce the problem:

  • Use a clear and descriptive title for the issue to identify the problem.
  • Describe the exact steps which reproduce the problem in as many details as possible.
  • Provide specific examples to demonstrate the steps to reproduce the issue. Include links to files or GitHub projects, or copy-paste-able snippets, which you use in those examples.
  • Describe the behavior you observed after following the steps and point out what exactly is the problem with that behavior.
  • Explain which behavior you expected to see instead and why.

Provide more context by answering these questions:

  • Did the problem start happening recently (e.g. after updating to a new version of easygraph) or was this always a problem?
  • If the problem started happening recently, can you reproduce the problem in an older version of easygraph? What's the most recent version in which the problem doesn't happen?
  • Can you reliably reproduce the issue? If not, provide details about how often the problem happens and under which conditions it normally happens.

Include details about your configuration and environment:

  • Which version of easygraph are you using?
  • Which Python version easygraph has been installed for?
  • What's the name and version of the OS you're using?

Suggesting enhancements

This section guides you through submitting an enhancement suggestion for easygraph, including completely new features and minor improvements to existing functionality. Following these guidelines helps maintainers and the community understand your suggestion and find related suggestions.

Before creating enhancement suggestions, please check this list as you might find out that you don't need to create one. When you are creating an enhancement suggestion, please include as many details as possible. Fill in the template, including the steps that you imagine you would take if the feature you're requesting existed.

Before submitting an enhancement suggestion

  • Check that your issue does not already exist in the issue tracker.

How do I submit an Enhancement suggestion?

Enhancement suggestions are tracked on the official issue tracker where you can create a new one and provide the following information:

  • Use a clear and descriptive title for the issue to identify the suggestion.
  • Provide a step-by-step description of the suggested enhancement in as many details as possible.
  • Provide specific examples to demonstrate the steps..
  • Describe the current behavior and explain which behavior you expected to see instead and why.

Contributing to documentation

One of the simplest ways to get started contributing to a project is through improving documentation. easygraph is constantly evolving, this means that sometimes our documentation has gaps. You can help by adding missing sections, editing the existing content so it is more accessible or creating new content (tutorials, FAQs, etc).

Note: A great way to understand easygraph's design and how it all fits together, is to add FAQ entries for commonly asked questions. easygraph members usually mark issues with candidate/faq to indicate that the issue either contains a response that explains how something works or might benefit from an entry in the FAQ.

Issues pertaining to the documentation are usually marked with the Documentation label.

Contributing to code

Picking an issue

Note: If you are a first time contributor, and are looking for an issue to take on, you might want to look for Good First Issue labelled issues. We do our best to label such issues, however we might fall behind at times. So, ask us.

the code base, join us on our Discord Server.

Local development

You will need easygraph to start contributing on the easygraph codebase. Refer to the documentation to start using easygraph.

Note: Local development of easygraph requires Python 3.8 or newer.

You will first need to clone the repository using git and place yourself in its directory:

git clone [email protected]:python-easygraph/easygraph.git
cd easygraph

Note: We recommend that you use a personal fork for this step. If you are new to GitHub collaboration, you can refer to the Forking Projects Guide.

Now, you will need to install the required dependency for easygraph and be sure that the current tests are passing on your machine:

pytest

easygraph uses the black coding style and you must ensure that your code follows it. If not, the CI will fail and your Pull Request will not be merged.

Similarly, the import statements are sorted with isort and special care must be taken to respect it. If you don't, the CI will fail as well.

To make sure that you don't accidentally commit code that does not follow the coding style, you can install a pre-commit hook that will check that everything is in order:

pre-commit install

You can also run it anytime using:

pre-commit run --all-files

Your code must always be accompanied by corresponding tests, if tests are not present your code will not be merged.

Run the Tests Locally

  • Install tox and pyenv
  • Use pyenv to install python 3.6 to 3.10, and make sure that python3.6, python3.7, ..., python3.10 is in your $PATH.
  • Run tox to run the tests across python 3.6 to 3.10.
  • To only run tox on python3.9 and 3.10, run tox -e py39,py310.

Pull requests

  • Fill in the required template
  • Be sure that your pull request contains tests that cover the changed or added code.
  • If your changes warrant a documentation change, the pull request must also update the documentation.

Note: Make sure your branch is rebased against the latest main branch. A maintainer might ask you to ensure the branch is up-to-date prior to merging your Pull Request if changes have conflicts.

All pull requests, unless otherwise instructed, need to be first accepted into the main branch (master).

Issue triage

If you are helping with the triage of reported issues, this section provides some useful information to assist you in your contribution.

Triage steps

  1. Attempt to reproduce the issue with the reported easygraph version or request further clarification from the issue author.
  2. Ensure the issue is not already resolved. You can attempt to reproduce using the latest preview release and/or easygraph from the main branch.
  3. If the issue cannot be reproduced,
    1. clarify with the issue's author,
  4. If the issue can be reproduced,
    1. comment on the issue confirming so
    1. if possible, identify the root cause of the issue.
    2. if interested, attempt to fix it via a pull request.

Git Workflow

All development work is performed against easygraph's main branch (master). All changes are expected to be submitted and accepted to this branch.

Release branch

When a release is ready, the following are required before a release is tagged.

  1. A release branch with the prefix release-, eg: release-1.1.0rc1.
  2. A pull request from the release branch to the main branch (master) if it's a minor or major release. Otherwise, to the bug fix branch (eg: 1.0).
    1. The pull request description MUST include the change log corresponding to the release (eg: #2971).
    2. The pull request must contain a commit that updates CHANGELOG.md and bumps the project version (eg: #2971).
    3. The pull request must have the Release label specified.
  1. Tag the branch with the version identifier (eg: 1.1.0rc1).
  2. Merge the pull request once the release is created and assets are uploaded by the CI.

Note: In this case, we prefer a merge commit instead of squash or rebase merge.

Bug fix branch

Once a minor version (eg: 1.1.0) is released, a new branch for the minor version (eg: 1.1) is created for the bug fix releases. Changes identified or acknowledged by the easygraph team as requiring a bug fix can be submitted as a pull requests against this branch.

At the time of writing only issues meeting the following criteria may be accepted into a bug fix branch. Trivial fixes may be accepted on a case-by-case basis.

  1. The issue breaks a core functionality and/or is a critical regression.
  2. The change set does not introduce a new feature or changes an existing functionality.
  3. A new minor release is not expected within a reasonable time frame.
  4. If the issue affects the next minor/major release, a corresponding fix has been accepted into the main branch.

Note: This is subject to the interpretation of a maintainer within the context of the issue.