Explore the wide variety of ways to contribute in Feature threads. To work on something that is core to Kamanja or for university work, contact us.
Providing Reports of what you liked and what you did not like. It is good to hear from users as well about how the project has helped them and to find out the details of their set up.
Create Feature Requests that explain what you are trying to achieve. Describe the features uses community benefits. The most popular requests help define the Kamanja roadmap.
Test the Code while it is being developed. This provides a wholistic view of hardware, software and other environmental items that can not be automated by the project team. A daily or weekly snapshot, installation and feedback is great!
Write Documentation that describes technical details and provides information for beginners. Also, proofreading for grammar, spelling, and sentence construction corrections are a big help.
Translation While many users understand English quite well, it is also true that many enjoy documentation that is written in their native language.
Answering questions and reacting to comment on the forums and updates - You may be surprised that you know more than you thought you did. And, the user on the other end will be very grateful for your help.
Answer Questions When you attempt to answer a question, it helps you better understand the project and it helps you write better bug reports, feature requests, and documentation. Users that get faster answers are then more attracted to the project and much more likely to stay and contribute and core project. We will also be looking at activity levels and looking for Moderators out of the participant pool .
Help design user interfaces, logos and website The community should and will dictate the evolution of the Kamanja website, improving the visual appearance of the project can greatly reduce support efforts and at the same time entice new users to try Kamanja.
Promote the project by organizing an events, by talking about it at your local user group, writing a blog post, and/or spreading updates via social media channels if you use them. Even if you think others must have heard about the project, don't assume. Hearing someone talk about their personal experience with a project is much stronger and involve others in a different way (versus browsing the project website and/or source code).
Provide Hardware if there is a need for access to specific builds or test servers, you can provide access to hardware in a datacenter directly to the developers or indirectly by running continuous integrations or testing yourself then providing results back to the project.
Thank the community – for their work and contributions to the cause you are working for and for the goals you are working towards.
Scala Style Guide – naming conventions http://docs.scala-lang.org/style/naming-conventions.html
Effective Scala - http://twitter.github.io/effectivescala/
Java Style - https://google.github.io/styleguide/javaguide.html
How to Fork, Branch, and Merge Code Contributions
Kamanja uses two branches to record the history of the engine as depicted in the following diagram: Kamanja Branching & Merging
The master branch stores the official release history and is always the stable version of the Kamanja engine. All commits in the master branch are tagged with a version number. Only a small group of committers have permissions to this branch.
The dev branch serves as an integration branch for features and bug fixes. Test automation scripts run daily on this branch to ensure that it builds and passes basic regression tests and an email alert is generated if anything fails.
In addition to the two main continuous master and dev branches, Kamanja uses following additional temporary branches as explained below:
Features & Fixes Branch
Any new feature or bug fix starts from the dev branch into its own branch. All of these branches are named appropriately to reflect the issue (feature or bug fix) they are resolving. For example, a branch that fixes the bug# 288 is named issue_288. If a branch resolves more than one issue, it should be named after the higher priority issue, and that issue should refer to other issues. Execute the following command to create a new branch: git checkout -b issue_288 dev
Once a developer has unit-tested the code and is ready to share the new feature, he/she needs to do the following:
- Before merging a feature branch into dev branch, it is required to rebase the feature branch on top of the dev branch to avoid resolving conflicts on merge time. Here is how it is done in isolation on the feature branch where you know what your changes are:
git pull --rebase origin dev
- Make the feature accessible to others by pushing it to his/her public repository:
git push -u origin issue_288
- Create a pull request to merge the feature branch into dev on GitHub. Also, if a developer needs help with a particular feature, all he/she needs to do is file a pull request. Interested parties are notified automatically, and they can see the question right next to the relevant commits.
Once Kamanja reviewers are ready to accept the pull request, one of the committers (must not be same as the originator of this pull request) merges the feature into the dev branch using the following commands:
- git checkout dev
- git pull
- git pull origin issue_288
- git push
When a feature or a set of features is complete, Kamanja creates a new branch for the anticipated next release from dev with the version number in its name such as release_v102. All release activity is performed on this branch, which is then merged into master once it is stabilized and well-tested. If there were any fixes or changes in this iteration, then it is also merged into dev at the end.
Hot Fixes Branch
This is the only branch that forks from master. It is merged back into both master and dev, and a new version is tagged at that time. These branches have names such as hot_issue_288.
UNIT TESTS USING SCALATEST
ScalaTest is a unit testing framework. It has a fairly comprehensive user guide found at: http://www.scalatest.org/user_guide It uses a variety of formats to make it easier to use no matter what style of unit testing you have experienced. You can see all the supported forms of unit testing at: http://www.scalatest.org/user_guide/selecting_a_style
Please review thoroughly for usage examples.
ScalaTest may be included as part of our project by adding the following library dependency to a build.sbt file: libraryDependencies += “org.scalatest” % “scalatest_2.10” % “2.2.1” % “test”
The benefit of using ScalaTest with sbt is that running the sbt test command runs any tests in the tests directories as normal and picks up on the various ScalaTest-driven tests in these directories without any additional work. Please read Unit Testing Guidelines.