Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update contrib and add gitattributes #33

Merged
merged 2 commits into from
Dec 22, 2021
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .gitattributes
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
*.ipynb linguist-documentation
21 changes: 13 additions & 8 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,20 +4,25 @@ We want to make contributing to Theseus as easy and transparent as possible.

### Developer Guide

- Fork the repo and make a branch from `develop`. See the hybrid [workflow model](#workflow-model) we follow.
- Fork the repo and install with development requirements.
```bash
git checkout -b <username>.<appropriate_branch_name> develop
git clone <link_to_fork> && cd theseus
pip install -e ".[dev]"
```
- Make a branch from `main`. See the [workflow model](#workflow-model) we follow.
```bash
git checkout -b <username>.<appropriate_branch_name> main
````
- Make small, independent, and well documented commits. If you've changed APIs, update the documentation. Add or modify unit tests as appropriate. Follow this [code style](#code-style).
- See [pull requests](#pull-requests) guide when you are ready to have your code reviewed to be merged into `develop`. It will be included in the next release on `main` following this [versioning](#versioning).
- Make small, independent, and well documented commits. If you've changed the API, update the documentation. Add or modify unit tests as appropriate. Follow this [code style](#code-style).
- See [pull requests](#pull-requests) guide when you are ready to have your code reviewed to be merged into `main`. It will be included in the next release following this [versioning](#versioning).
- See [issues](#issues) for questions, suggestions, and bugs.
- If you haven't already, complete the [Contributor License Agreement](#contributor-license-agreement) and see [license](#license).

---

## Workflow Model

We follow a hyrbid between [Gitflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) and [Trunk-based](https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-based-development) models. From the former we adopt hosting latest stable release on `main` branch and feature development on `develop` branch, and from the latter we adopt small and frequent merges of new features into `develop`.
We follow the [Trunk-based](https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-based-development) model. Small and frequent PR of new features will be merged to `main` and a tagged release will indicate latest stable version on `main` history.

## Code Style

Expand All @@ -30,11 +35,11 @@ pip install pre-commit && pre-commit install && pre-commit run --all-files

- We encourage more smaller and focused PRs rather than big PRs with many independent changes.
- Use this [PR template](.github/PULL_REQUEST_TEMPLATE.md) to submit your code for review. Consider using the [draft PR](https://github.blog/2019-02-14-introducing-draft-pull-requests/) option to gather early feedback.
- Add yourself to the `Assignees`, add at least one core Theseus team member to `Reviewers`, link to any open issues that can be closed when the PR is merged, and add appropriate `Labels` and `Milestone`.
- Add yourself to the `Assignees`, add at least one [core Theseus team](THANKS.md) member to `Reviewers`, link to any open issues that can be closed when the PR is merged, and add appropriate `Labels` and `Milestone`.
- We expect the PR is ready for final review only if Continuous Integration tests are passing.
- Keep your branch up-to-date with `develop` by rebasing as necessary.
- Keep your branch up-to-date with `main` by rebasing as necessary.
- We employ `squash-and-merge` for incorporating PRs. Add a brief change summary to the commit message.
- After PR is approved and merged into `develop`, delete the branch to reduce clutter.
- After PR is approved and merged into `main`, delete the branch to reduce clutter.

## Versioning

Expand Down