Contributing

First of all, thank you for helping! :) This page attempts to set some guidelines on how to contribute to the code base.

We will base our development guidelines on GitFlow. If you want to work on one of the issues, assign yourself to it or at least leave a comment that you are working on it and how.
If you have an idea for a new feature, make an issue first, assign yourself to it, then start working.
Please make sure you have read the Developer's Certificate of Origin, further down on this page!

1. Fork the main lookup repository on GitHub.
2. Clone this fork onto your machine (git clone <your_repo_url_on_github>).
3. From the latest revision of the master branch, make a new feature branch from the latest revision. Name the branch something meaningful, for example fix-RestApiParams (git checkout master -b fix-RestApiParams).
4. Make changes and commit them to this branch.

• Please commit regularly in small batches of things "that go together" (for example, changing a constructor and all the instance creating calls). Putting a huge batch of changes in one commit is bad for code reviews.
• In the commit messages, summarize the commit in the first line using not more than 70 characters. Leave one line blank and describe the details in the following lines, preferably in bullet points, like in 7776e31....

5. When you are done with a bugfix or feature, rebase your branch onto lookup/master (git pull --rebase origin master, where origin is the name of the official lookup remote). Resolve possible conflicts and commit.
6. Push your branch to GitHub (git push upstream fix-RestApiParams), where upstream is the name of your remote.
7. Send a pull request from your feature branch into lookup/master via GitHub.

• In the description (not in the title), mention the associated issue(s) (for example, "Fixes #123 by ..." for issue number 123, the # sign allows you to point to specific issues in lookup).
• Your changes will be reviewed and discussed on GitHub.
• In addition, Travis-CI will test if the merged version passes the build.
• If there are further changes you need to make, because Travis said the build fails or because somebody caught something you overlooked, go back to item 4. Stay on the same branch (if it is still related to the same issue). GitHub will add the new commits to the same pull request.
• Finally, when everything is fine, your changes will be merged into lookup/master

Please keep in mind:

• Files generated by the IDE shouldn't be added to the repository. You should remove them and add them to .gitignore.
• Try not to modify the indentation. If you want to re-format, use a separate "formatting" commit in which no functionality changes are made.
• If you already pushed a branch to GitHub, later rebased the master onto this branch and then tried to push again, GitHub won't let you saying "To prevent you from losing history, non-fast-forward updates were rejected". If (and only if) you are sure that nobody already pulled from this branch, add --force to the push command.
  "Don’t rebase branches you have shared with another developer."
  "Rebase is awesome, I use rebase exclusively for everything local. Never for anything that I've already pushed."
  "Never ever rebase a branch that you pushed, or that you pulled from another person"
• For Scala, we try to follow the Scala style guide within reason.

More tips:

• Guides to setup your development environment for [Intellij](Setting up IntelliJ IDEA) or [Eclipse](Setting up eclipse).
• Get help with the Maven build or another form of installation.
• Download some data to work with.
• How to run from Scala/Java or from a JAR.
• Having different troubles? Check the troubleshooting page or write a mail to the list [email protected].

Important: Developer's Certificate of Origin

By sending a pull request to the main lookup repository on GitHub, you implicitly accept the following:

    Developer's Certificate of Origin 1.1

    By making a contribution to this project, I certify that:

    (a) The contribution was created in whole or in part by me and I
        have the right to submit it under the open source license
        indicated in the file; or

    (b) The contribution is based upon previous work that, to the best
        of my knowledge, is covered under an appropriate open source
        license and I have the right under that license to submit that
        work with modifications, whether created in whole or in part
        by me, under the same open source license (unless I am
        permitted to submit under a different license), as indicated
        in the file; or

    (c) The contribution was provided directly to me by some other
        person who certified (a), (b) or (c) and I have not modified
        it.

    (d) I understand and agree that this project and the contribution
        are public and that a record of the contribution (including all
        personal information I submit with it, including my sign-off) is
        maintained indefinitely and may be redistributed consistent with
        this project or the open source license(s) involved.

(source: http://elinux.org/Developer_Certificate_Of_Origin)

Other ways to contribute

If you think you can contribute in any other way, please send us an e-mail at [email protected]. You could

• contribute a new language version
• contribute evaluation data
• contribute infrastructure
• donate

Disclaimer: this page is a copy of DBpedia Spotlight contributing page. Thanks that team to provide it to us.