How to contribute to sparc api ?

Where do I see the issues being worked on?

SPARC api uses Wrike for the project management. In order to contribute, a developer should reach out to the SPARC team by sending an email to [email protected]

What kind of git workflow(s) do we expect developers to follow?

Git Feature Branch Workflow

Who will review Pull Requests (PR)?

PRs are reviewed by peers. At least one reviewer approval is necessary for a PR to be merged. If you're unsure who to ask for a review, pick at least two people from the contributors list that have contributed recently: https://github.com/nih-sparc/sparc-api/graphs/contributors If you cannot select a reviewer, you probably need to be added to the nih-sparc organization in github. To do so, you can contact [email protected]

What are the criteria for a PR to be accepted?

• Pass CI, which is setup to run the tests via nosetests
• Approved by one or more contributors

Questions that each PR should be able to answer include but are not limited to:

• Does this code meet the existing project's coding style and/or standards?
• Does the project have the necessary unit and/or integration tests written?
• Is there documentation capturing how to regression test this feature?
• Does this code impact any existing modules and/or tests?
• Are performance benchmarks required?
• How will data flows be validated?
• Does this require any updates to existing architecture designs?

What are the requirements for tests?

The tests should at a minimum ensure that the acceptance criteria are met and demonstrate it clearly.

Is there any code style guide?

We follow Pep8 style guide https://www.python.org/dev/peps/pep-0008/

How do we check coverage of tests?

• Heroku

How is staging managed?

Code is automatically deployed to staging when merged to master on Heroku. Staging also shows draft content in Contentful.

How should a developer test their code prior to submitting a PR?

Tests can be written in python.

A developer can use the following steps and commands to ensure quality and working code.

1. Run locally and ensure the feature works as intended
2. Run black . and isort tools to clean your code
3. Run unit tests via nosetests

Should a PR be created at the start of a tranche of work or the end?

• A feature branch is typically created at the beginning of the work, and a PR is created at the end when ready to be reviewed and merged.

How should github issues be used vs Wrike tickets (especially given the closed Wrike tickets vs the openness of the code itself)

We currently do not use github ticket system. If feedback is provided through github, we will create a ticket in wrike and maintain open communication on the github ticket.

Useful links

The API documentation for Pennsieve Discover: https://docs.pennsieve.io/reference