Sledge is an open source project so we always welcome your ideas, and appreciate your efforts trying to make Sledge a better project for the community.
Before contributing to this repository, you must have discussed the changes you wish to make and things you wish to add, via email, github issue template for our repo or any other effective method, with the administrator or owners of Sledge.
You are advised to follow our CODE-OF-CONDUCT as a guide to any interactions you make with/on this repository.
The issue tracker is the channel for bugs reports, feature request on Sledge.
- To engage in the pull request process, you may fork our repo, clone the repo you forked and using your git software configure remote handling of the repo you cloned from the fork.
# after the fork
git clone https://github.com/<your-username>/sledge.git
# after clone
cd sledge
# add upstream
git remote add upstream https://github.com/framestd/sledge.git
# if it's been a while you cloned, update
git checkout master
git pull upstream master- Create a new topic branch to contain your changes or fix
git checkout -b <topic-branch-name>- Commit changes bit by bit recording what changes you made with your commit message. Do not commit a whole lot of cahnges at once except it is a similar change in all. Follow this commit guidelines
- Merge or rebase the upstream dev branch into your topic branch
git pull [--rebase] upstream master- Push your topic branch to your fork
git push origin <topic-branch-name>- Open a Pull Request with a resonable title and description against the master branch.
NOTE: submitting your work makes us believe that you agree to license your work under the same license of this project
By submitting your work you assure us you ensured the following:
- You removed install or build dependencies.
- You updated the README.md, and in a very concise and comprehensible language, described for the changes you made: things pertaining to usage, what to use, what not to use, if required code snippet for usage.
- This project follows the Semantic Versioning rules
major.minor.patch. Update or Increase the version number wherever required, and follow the versioning rules and regulations defined at Semver.org: Backwards incompatible API changes would cause a bump in the major, backwards compatible changes, adding a new feature should cause a bump in the minor, bug fixes would cause a bump in the patch. Although we do not allow API changes so changes can only cause bump in either minor or patch. In case you need clarification. If you think an API change is very important you may describe with reasons why you think it's important via email toframestd.org AT gmail DOT com. - You must have edited the docs to document changes. Do not edit *.html files in the docs folder, instead edit the *.frame files in the
docs/src/pages directory, edit similar panes in the panes directory and build using this same software you are about to submit. - You must have tested your work and see that it works as desired.
API would mean Application Programming Interface.
Authors would mean anyone contributing to the API.
Our API is split into two
- Private API
- Public API
This consists only of methods, attributes and classes serving a specific function private to the code or the author(s) of the application. These methods, classes and attribuutes are those not exposed to end users, and only used by developers. The Private API is the one always called on by the Public API. In our python source code we made efforts to prefix private interfaces with one or two underscores _ or __ to denote private.
This consists of methods, attributes and classes serving a specific function public to everyone. The public API can be considered high level which accesses private API—low level to do a lot of jobs.
With respect to the compliance defined above, the API referred to is the public API. The public API is also split into two:
- Command Line API (CLAPI)
- Python Programming API