Before implementing your ideas, it is recommended first to create a corresponding issue and discuss the plan to be approved;). Also consider first to help with issues marked with help_needed
label ;)
-
Find an existing relevant issue or add a new one to this project.
-
Discuss its need and possible implementation. And once approved...
-
Clone your fork of the project
git clone https://github.com/[my-github-username]/selene.git
-
Install poetry via
pip install poetry
-
cd selene
-
poetry install
-
poetry shell
-
Create your feature branch (
git checkout -b my-new-feature
) -
Stage appropriate changes (via
git add
),and commit:
git commit -am "[#$ISSUE_NUMBER] $COMMIT_MESSAGE"
,(example:
git commit -am "[#321] TEST: improve tests structure"
)where
- ISSUE_NUMBER is the number of issue this commit relates to
- COMMIT_MESSAGE is...
<type>: <subject> <body>
where
<type>
is one of:- NEW: (new feature for the user, not a new feature for build script)
- FIX: (bug fix for the user, not a fix to a build script)
- DOCS: (changes to the documentation)
- STYLE: (formatting, missing semi colons, etc; no production code change)
- REFACTOR: (refactoring production code, eg. renaming a variable)
- TEST: (adding missing tests, refactoring tests; no production code change)
- CHORE: (updating build tasks etc; no production code change)
<subject>
- summary of "what and why?" (not "how?")
- is in present tense,
in the imperative (e.g.change
overchanges
orchanged
),
<= 50 symbols - has no period in the end
<body>
- More detailed explanatory text if needed. Wrapped to 72 characters.
- Focused on what and why over how.
- Separated from
<subject>
with a blank line - Further paragraphs come after blank lines.
- Bullet points are okay, too.
- Typically, a hyphen or asterisk is used for the bullet, followed by a single space. Use a hanging indent.
credits: these commit message conventions based on sources from:
-
Push to the branch (
git push origin my-new-feature
) -
Create a new Pull Request
To get more information about contributing, you can (and should) read our Code conventions and Release workflow pages.