A general introduction: What does it mean to be a Open Source Maintainer.
- Read the blog posts from GSOC 2017: Lorenzo Chris Akshay
- Having a general understanding of RDF: Wikipedia - Google Scholar: especially the concept of representing data in triples.
- Having a general understanding of Linked Data
- Having a general understanding of JSON-LD
- Read the old HYDRA Draft and updated specifications. Very important is the current work done for Draft’s use-cases
- Read this seminal paper about Web APIs. This other paper explains different use cases for graphs applied to databases.
- Read Hydra-CG gitbook
- Read hydrus WIKI. Run
hydrusand try to set up a basic API. Read the documentation
- If you want to have fun with a more dynamic demo, run hydra-flock-demo
- There are different rooms in Gitter in which to interact with other contributors:
- Read the other blogposts in our Medium Publication
- Get familiar with Docker container engine and its best practices to deploy virtualized environments.
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
- 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
- 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
mastercan only receive merge from
- Everything should work and be tested for Python 3.5.2 and above.
- In general, no permission is needed to work on the code. Fork
developbranch 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.
- If you are working on a new idea/core modification it’s important that it adhere to the HYDRA Draft. We don’t add anything to the API documentation that is not defined in the Hydra spec.
- 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
- Problem solving with algorithms in Python
- Inside Python Virtual Machine
- How to design programs
hydrusis developed in
flaskbecause 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”