All contributions are welcome to improve Arkindex, whether they are code, translations, design suggestions, small fixes, etc.
If you want to discuss some ideas, send us an email at team (at) teklia.com
!
We use GitLab to track issues (either bugs, or new features).
You can browse Arkindex's existing issues:
Please ask first if you can work on an issue, by simply commenting on it. Be aware that some issues may be way more complex than others.
Issues should have a priority label:
If nothing is set, assume P2 by default.
To start working on a patch, you must first create a git branch, based on the current master
branch:
# Start from master
git checkout master
# Update master to latest available revision
git pull origin master
# Create a new branch
git checkout -b my-new-branch
Each new commit will then be stored on that new branch named my-new-branch
.
To name your branch, use a name:
-
to link words,Here are some examples of suitable branch names:
remove-model-x
when the goal is to remove a Django model named X
fix-invalid-chars-search
when the patch fixes a bug related to searchbump-dependency-y
add-super-feature
feature-z
Please avoid:
External contributors cannot push directly on Arkindex's repositories. You will need to create a fork of the repository under your own namespace, then open a Merge Request on the original repository. To learn more, check out GitLab's forking workflow documentation.
The goal is for your code to be merged into master
once the following steps are completed:
test
ended in successchecks
ended in successIn order for your contribution to be approved, you need to create a Merge Request (also called MR) on GitLab.
When pushing your code from your local branch, you will notice some output in the console with a link towards gitlab.teklia.com
: it will allow you to create a Merge Request (or view the previously created one) in 2 clicks.
Once your work is ready, configure your Merge Request as follows:
master
branch of the upstream repository, not of your own fork.Closes #XYZ
if you fully solve the mentioned issue,Ref #XYZ
if you only want to link your Merge Request to the issue.If you are not confident the work being published is yet ready for review, you can prefix your Merge Request name with Draft:
; that will tell the reviewer to wait a bit before diving into your code. Do not forget to remove that prefix once your code is ready.
The reviewer may leave some comments directly on the Merge Request, asking you for updates. Please resolve all of them (or discuss them if you disagree), publish some commits fixing the issues, and then ask for a new review. Rinse and repeat until the reviewer approves and merges your code!
As other developers are working on Arkindex, sometimes features/bugfixes/etc that impact the same areas of code as your own merge Request will land on master before your Merge Request does. You may get conflicts here, and need to solve them using a rebase.
It is your responsibility, as a developer, to maintain your code in a mergeable state: no conflicts and up to date with the latest master
.
To update using rebase, while working on your branch:
# Retrieve the latest updates from master
git fetch origin master
# Now the remote reference to origin/master has been updated, you can rebase on top of it
# Be aware that the local reference to master is not yet updated, it is only updated with git pull
git rebase origin/master
The git rebase
operation will ask you to manually solve conflicts (if any). Please follow this guide or ask us for help if you are lost.
If you have reached this step, congratulations and many thanks! Your code has been approved and should already be merged, as that is the responsibility of the reviewer.
Your work will be shipped in the next Arkindex release along with latest features, bugfixes and other contributions.