Starting-Material.md

Starting contributing

1. Read the blog posts from GSOC 2017: Lorenzo Chris Akshay
2. Having a general understanding of RDF: Wikipedia - Google Scholar: especially the concept of representing data in triples.
3. Read the old HYDRA Draft and updated specifications
4. Read this seminal paper about Web APIs
5. Read hydrus WIKI. Run hydrus and try to set up a basic API. Read the documentation
6. If you want to have fun with a more dynamic demo, run hydra-flock-demo
7. There are different rooms in Gitter in which to interact with other contributors:

• Demos room: talk about creating new demo implementations
• Improving hydrus room: issues, solutions and ideas
• Beginners: experienced contributors help newcomers

General guidelines to contributing

About OpenSource and Github

• Read this how-to about Github workflow here if you are not familiar with
• Read all the texts related to contributing for an OS community
• Read this how-to about writing a PR and this other how-to about writing a issue

Asking for help

• If you find a problem, first ask for help in the chat, then consider opening a issue.
• Please check existing or closed issues or PRs when thinking about opening a new one.

Opening a Pull Request

• Every PR should follow the PR template. PR template for hydrus can be found here.
• Code in PRs should be accurately compliant with PEP-8, checking code with pylint is fine.
• Every method in the PR should have a compelling docstring in the format:

def test_method(arg1, arg2, ...):
    """
    Description of what the method performs.

    Generic Notes to consider when running the method if any

   :param arg1: what kind of value is expected
   :param arg2: what kind of value is expected
   :return : what is returned or `None`
   """

• Every module is and should in future provide type annotations using mypy
• Before opening a PR be sure that all the tests pass successfully. If any is failing for non-related reasons, annotate the test failure in the PR comment.
• Any change should be PRed first in develop, master can only receive merge from develop.
• Everything should work and be tested for Python 3.5.2 and above.

Others

• In general, no permission is needed to work on the code. Fork develop branch and keep your downstream branch updated; when done submit a PR and ask for reviewing. PR is the natural place for code comparison and corrections. Code for issues with multiple PRs will be integrated at reviewing time.

Worth knowing

• Writing a proposal for GSOC
• OpenAPI framework
• A Web API ecosystem through feature-based reuse
• Triple Pattern Fragments
• List of useful papers here
• Python design patterns

Design annotations

• hydrus is developed in flask because the applications we had in mind were mostly related to IoT and sensors, so it was supposed to be lightweight and functional. By the way we can consider also more structured options like having versions that works with Django or Pyramid.
• Read the issues labeled as "wiki"

---

• Back to Index