(moved to the README.md) Contributing

The content below has been adapted and marged in the README.md

TODO: In near future, discard this wiki page.

(Copied from DBpedia-Spotlight, TODO: adapt for DBpedia)

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

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 extraction-framework 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 development branch from the latest revision. Name the branch something meaningful, for example fixRestApiParams (git checkout master -b fixRestApiParams).
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 extraction-framework/master (git pull --rebase git://github.com/dbpedia/extraction-framework.git). Resolve possible conflicts and commit.
6. Push your branch to GitHub (git push origin fixRestApiParams).
7. Send a pull request from your development branch into extraction-framework/master via GitHub.

• In the description, reference the associated commit (for example, "Fixes #123 by ..." for issue number 123).
• 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 extraction-framework/master.

Please keep in mind:

• Try not to modify the indentation. If you want to re-format, use a separate "formatting" commit in which no functionality changes are made.
• Never rebase the master onto a development branch (i.e. never call rebase from dbpedia-spotlight/master). Only rebase the development branch onto the master, if and only if nobody already pulled from the development branch!
• 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"
• In general, we prefer Scala over Java.

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 dbp-spotlight-users@lists.sourceforge.net.

Important: Developer's Certificate of Origin

By sending a pull request to the main dbpedia-spotlight 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 dbp-spotlight-users@lists.sourceforge.net. You could

• contribute a new language version: see the Internationalization page.
• contribute evaluation data
• contribute infrastructure
• donate