Skip to content

Latest commit

 

History

History
82 lines (62 loc) · 3.76 KB

CONTRIBUTING.md

File metadata and controls

82 lines (62 loc) · 3.76 KB
Raw

Contributing Guidelines

Thank you for your interest in contributing to LISC! We welcome any contributions to the project that extend or improve code and/or documentation and/or tutorials!

If you have an idea you would like to contribute to LISC, please first check that it is in scope for the project, as discussed below.

If it seems related to the project, it is best to go and open an issue, suggesting your idea.

From there, you can follow the procedures and conventions described below to add your contribution to LISC!

Note that contributors to LISC are expected to follow the Code of Conduct.

Scope

LISC is a module for accessing and analyzing the scientific literature.

In terms of scope, it is currently focused on connecting to APIs that offer access to literature databases (currently: Pubmed) and offering simple analysis and plotting utilities for collected data.

The current scope of LISC is therefore focused on connecting existing tools and utilities. That is to say custom or new web scraping and/or natural language processing (NLP) functionality is likely to be considered out of scope for this project, but any work on adding / extending access to literature APIs and/or existing NLP tools are welcome!

Procedures

LISC is hosted and developed on Github.

To make a contribution:

  1. Make an issue on the LISC repository, stating your intention and getting feedback from maintainers
  2. Make a fork of the LISC repository
  3. Update the fork of the repository with any updates and/or additions to the project
  4. Check that any additions to the project follow the conventions described below
  5. Make a pull request from your fork to the LISC repository
  6. Address any feedback and/or recommendations from reviewers, until the contribution is ready to be merged

Conventions

  1. Code & Style

    • All code should be written in Python 3.4+
    • Code should follow the PEP8 style guide

  2. Documentation

    • Docstrings for public functions should be in Numpy docs format. At minimum, there should be a sentence describing what the function does and a list of parameters and returns.
    • Private functions should be indicated with a leading underscore, and should still include a docstrings including at least a sentence description what the function does.
    • If you add any new public functions, note this function in the doc/api.rst file, so that this function gets included in the documentation site API listing.

  3. Dependencies

    • Any dependencies outside of the standard Anaconda distribution should be avoided if possible.
    • If any more packages are needed, they should be added to the requirements.txt file.

  4. API & Naming Conventions

    • Try to keep the API consistent across LISC in naming and parameter ordering.
    • Try to keep naming conventions consistent with other modules:
      • Function names are in snake_case
      • Classes are in CamelCase

  5. Tests

    • All code within LISC requires test code that executes that code
    • These tests, at a minimum, must be 'smoke tests' that execute the code and check that it runs through, without erroring out, and returning appropriate variables.
    • If possible, including more explicit test code that checks more stringently for accuracy is encouraged, but not strictly required.
    • Before a pull request is merged, code coverage must demonstrate that new code is tested, and continuous integration running this test code must all pass

  6. Tutorials

    • If a new function or module is added, a quick tutorial demonstration of using this code should be added to the tutorials section.