that sounds great
the guidelines are much the same for any open source project.
before you start making changes, its advisable to contact the main developer (@johannes) , and 'discuss' what you plan/want to do... the reason are simple:
- they can tell you if someone is already work on it
- they can tell you what branch to work on
- they can tell you if there are plans already in this area, and what they might be, and if they might conflict
- they might be able to offer advice on how to implement the change, or possible consequences.
(obviously, some of this can be shortcut, to fix simple bugs... but even then its still often worth a quick PM to check)
in this particular case, you would be best doing any change on the 'experimental' branch, this is where all new development is being done... and its highly unlikely there will be a 1.0.13 based off master, as this development is pretty far along now.
the process for contributing changes is pretty simple:
- fork the axoloti repo
- make your changes on the correct branch
- create a pull request
note:before you issue the pull request, make sure you merge in the latest version from the branch you are working on, and
resolve any conflicts that may occur (and obviously test it thoroughly)
once you do this, either @johannes or I will review the pull request (PR) , and if it looks good we will merge it.
if there are improvements, or it conflicts in some way with proposed changes, then we will comment on the pull request.
(assuming its been discussed in advanced, then this should be a formality really)
there is an issue list on GitHub, though I'm not sure it covers everything esp. at this stage of development (on experimental) , but there is lots to do
there has been huge number of changes on the experimental branch, so there are a few things missing to reach feature parity with 1.0.12, and also bugs etc to be squashed - this is the current priority , to get it into a release state.
probably a good way to get into it, is checkout the experimental branch, and start using it... finding bugs, and either reporting (in issues) and fixing them if possible. (its much too early for user testing, but a good time for developers to test/resolve) ... you could also look into resizing the obj frame if you wish on that branch too.
hope that is kind of clear... its not as formalised as perhaps it might be, but when its only a couple of developers, its best to do these things through clear communication, rather than procedures
(sure it doesn't scale to teams of 10's of developers, but we are a long way away from that )