Welcome contributors! schema_automator is a open-source project.
Before you get started please be sure to review the Contributing Guidelines and the Code of Conduct.
Take a look at the project's README.md for instructions on setting up a dev environment. We recommend using Poetry for setting up your virtual environment.
We try to conform to PEP-8 style guidelines, but we do not enforce them yet. This might changes in the future.
But we do recommend NumPy-style docstrings for any method you write. This facilitates automated generation of documentation.
All tests are located in tests folder.
For running tests, we use pytest.
If you run into any issues or find certain functionality not documented/explained properly then feel free to raise a ticket in the project's issue tracker. There are issue templates to capture certain types of issues.
We appreciate your enthusiasm and welcome contributions to this project.
We recommend using GitHub Fork and Pull workflow which involves the following principles,
Prior to adopting the workflow, a developer will perform a one-time setup to create a personal Fork of the repository and will subsequently perform their development and testing on a task-specific branch within their forked repository. This forked repository will be associated with that developer's GitHub account, and is distinct from the main (upstream) repository.
Changes will never be committed directly to the master branch on the main repository. Rather, they will be composed as branches within the developer's forked repository, where the developer can iterate and refine their code prior to submitting it for review.
Each set of changes will be developed as a task-specific branch in the developer's forked repository, and then a pull request will be created to develop and propose changes to the shared repository. This mechanism provides a way for developers to discuss, revise and ultimately merge changes from the forked repository into the main repository.
Once a pull request has been merged, the task-specific branch is no longer needed and may be deleted or ignored. It is bad practice to reuse an existing branch once it has been merged. Instead, a subsequent branch and pull-request cycle should begin when a developer switches to a different coding task.
You may create a pull request in order to get feedback, but if you wish to continue working on the branch, so state with "DO NOT MERGE YET" in the PR title OR mark the pull request as a Draft OR label the pull request with a 'Do Not Merge' label.
We recommend making a new ticket for each bug that you encounter while working with KGX. Please be sure to provide sufficient context for a bug you are reporting. There are Issue Templates that you can use as a starting point.
We welcome request for enhancements and you can make these requests via the issue tracker. Please be sure to provide sufficient context to what the enhancement is trying to address, its utility, and how it's likely to be useful to you and the broader community.
Core developers should follow these rules when processing pull requests:
- All PRs should originate from a fork
- Always wait for tests to pass before merging PRs
- Use "Squash and merge" to merge PRs