-
Notifications
You must be signed in to change notification settings - Fork 17
How to contribute to sparc app
SPARC app 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]. Alternatively, you may suggest changes, submit a feature request or report a bug using this feedback form on SPARC portal to contact us.
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-app/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]
- Pass CI, which is setup to run the tests via
yarn test - Approved by one or more contributors
- 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?
The tests should at a minimum ensure that the acceptance criteria are met and demonstrate it clearly.
Not currently enforced, but Pennsieve is currently running lint on save. These could be automatically enforced by Git Hooks.
- Heroku (Inactive)
Code is automatically deployed to staging when merged to master on Heroku. Staging also shows draft content in Contentful.
The staging site can be found in this link.
Tests can be written with Vue Test Utils
A developer can use the following steps and commands to ensure quality and working code.
- Run locally and ensure the feature works as intended
- Lint via
yarn lint - Run unit tests via
yarn test - (Optional) Deploy on an externally accessible instance and provide an URL for other developers to test out the new features or bug fixes.
- 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. For features/bug fixes that requires more attentions, a pull request can be opened as draft in the middle of the development which would allow more developers to involve in the development.
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.
To receive the set of environment variables, send an email with your public GPG key to [email protected] and you'll receive an encrypted file containing them.