CONTRIBUTING.md

Contributing to ROAR

Welcome to ROAR! We're excited you're here and want to contribute.

Imposter's syndrome disclaimer¹: We want your help. No, really.

There may be a little voice inside your head that is telling you that you're not ready to be a contributor; that your skills aren't nearly good enough to contribute. What could you possibly offer a project like this one?

We assure you - the little voice in your head is wrong. If you can write code at all, you can contribute code to open-source. Contributing to open-source projects is a fantastic way to advance one's coding skills. Writing perfect code isn't the measure of a good developer (that would disqualify all of us!); it's trying to create something, making mistakes, and learning from those mistakes. That's how we all improve, and we are happy to help others learn.

Being a ROAR contributor doesn't just mean writing code, either. You can help out by writing documentation, tests, or even giving feedback about the project (and yes - that includes giving feedback about the contribution process). Some of these contributions may be the most valuable to the project as a whole, because you're coming to the project with fresh eyes, so you can see the errors and assumptions that seasoned contributors have glossed over.

Practical guide to submitting your contribution

These guidelines are designed to make it as easy as possible to get involved. If you have any questions that aren't discussed below, please let us know by opening an issue!

Before you start, you'll need to set up a free GitHub account and sign in. Here are some instructions.

Already know what you're looking for in this guide? Jump to the following sections:

• One ROAR, many repositories
• Joining the conversation
• Contributing through Github
• Understanding issues
• Making a change
• Structuring contributions
• Licensing

ROAR Repositories

ROAR is a web application with many interacting components:

• a dashboard web app (repo, issues)
• Firebase cloud functions (repo, issues)
• standalone web applications for each ROAR assessment. For example,
  • ROAR-SWR (repo, issues)
  • ROAR-SRE (repo, issues)
  • ROAR-PA (repo, issues)
  • and many more
• ROAR-firekit, an external library that allows the dashboard and ROAR apps to communicate with our Firestore databases (repo, issues)
• ROAR-utils, an external library that contains common utilities used by the ROAR assessments (repo, issues)

Each of these components is housed in it's own GitHub repository, some of which are public and others private. If the links above don't work, it is probably because the repository is private and you do not have access.

If you are an experienced ROAR developer and know which repository you want to work with, you can use that repository's issue tracker and pull request system to contribute your own enhancements or bug fixes. However, when you are first getting started, it can be difficult to determine which repository houses the code that you want to work with. To help, we also maintain a "parent directory" repository that contains links to each of the ROAR repositories. It also has its own issue tracker, where you can discuss ROAR without having to know anything about its repository structure.

Joining the conversation

ROAR is primarily maintained by a collaborative research group. But we welcome contributions from people outside our group and we make sure to give contributors from outside our group credit in presentations of the work. In other words, we're excited to have you join! Most of our discussions will take place on open issues. We actively monitor this space and look forward to hearing from you!

Contributing through GitHub

git is a really useful tool for version control. GitHub sits on top of git and supports collaborative and distributed working.

If you're not yet familiar with git, there are lots of great resources to help you git started! Some of our favorites include the git Handbook and the Software Carpentry introduction to git.

On GitHub, You'll use Markdown to chat in issues and pull requests. You can think of Markdown as a few little symbols around your text that will allow GitHub to render the text with a little bit of formatting. For example, you could write words as bold (**bold**), or in italics (*italics*), or as a link ([link](https://youtu.be/dQw4w9WgXcQ)) to another webpage.

GitHub has a really helpful page for getting started with writing and formatting Markdown on GitHub.

Understanding issues

Every project on GitHub uses issues slightly differently.

The following outlines how the ROAR developers think about these tools.

Issues are individual pieces of work that need to be completed to move the project forward. A general guideline: if you find yourself tempted to write a great big issue that is difficult to be described as one unit of work, please consider splitting it into two or more issues.

Issue Labels

Issues are assigned labels which explain how they relate to the overall project's goals and immediate next steps.

The current list of issue labels are here and include:

• These issues contain a task that is amenable to new contributors because it doesn't entail a steep learning curve.

  If you feel that you can contribute to one of these issues, we especially encourage you to do so!

• These issues point to problems in the project.

  If you find new a bug, please give as much detail as possible in your issue, including steps to recreate the error. If you experience the same bug as one already listed, please add any additional information that you have as a comment.

• These issues are asking for new features and improvements to be considered by the project.

  Please try to make sure that your requested feature is distinct from any others that have already been requested or implemented. If you find one that's similar but there are subtle differences, please reference the other request in your issue.

In order to define priorities and directions in the development roadmap, we have two sets of special labels:

Label	Description
	Estimation of the downstream impact the proposed feature/bugfix will have.
	Estimation of effort required to implement the requested feature or fix the reported bug.
	Estimation of the urgency of the requested feature or bug fix.

These labels help triage and set priorities of the development tasks. For instance, consider a bug that prevents users from completing assessments, has been reported to affect most users, and will be an easy fix because it is a known old problem that came back. Such an issue will typically be assigned the following labels , and its priority will be maximal since addressing low-effort high-impact issues delivers the maximum turnout without increasing the churn by much. Of course, the implementation of long-term goals may include the scheduling of . Finally, issues are less likely to be addressed.

Making a change

We appreciate all contributions to ROAR, but those accepted fastest will follow a workflow similar to the following:

1. Comment on an existing issue or open a new issue referencing your addition.
   This allows other members of the ROAR development team to confirm that you aren't overlapping with work that's currently underway and that everyone is on the same page with the goal of the work you're going to carry out.
   This blog is a nice explanation of why putting this work in up front is so useful to everyone involved.

2. Fork the repository that you want to edit to your profile.
   This is now your own unique copy of the repository. Changes here won't effect anyone else's work, so it's a safe space to explore edits to the code! On your own fork of the repository, select Settings -> Actions-> "Disable Actions for this repository" to avoid flooding your inbox with warnings from our continuous integration suite.

3. Clone your forked repository to your machine/computer.
   While you can edit files directly on github, sometimes the changes you want to make will be complex and you will want to use a text editor that you have installed on your local machine/computer. (One great text editor is vscode).
   In order to work on the code locally, you must clone your forked repository.
   To keep up with changes in the repository, add the "upstream" repository as a remote to your locally cloned repository. For example, to add the upstream ROAR dashboard repository, type

   git remote add upstream https://github.com/yeatmanlab/roar-dashboard.git

   Make sure to keep your fork up to date with the upstream repository.
   For example, to update your main branch on your local cloned repository:

   git fetch upstream
   git checkout main
   git merge upstream/main

4. Install a development version of the software so that your local changes are reflected in your local tests
   In most cases, you can install a development version of by navigating to the root of your repository and then typing

   npm install

5. Create a new branch to develop and maintain the proposed code changes.
   For example:

   git fetch upstream  # Always start with an updated upstream
   git checkout -b fix/bug-1222 upstream/main

   Please consider using appropriate branch names as those listed below:

   Branch name	Use case
   fix/<some-identifier>	for bugfixes
   enh/<feature-name>	for new features
   tst/<feature-name>	for new or updated tests
   doc/<some-identifier>	for documentation improvements
   sty/<some-identifier>	for changes to coding style only
   ref/<some-identifier>	for refactoring existing code
   ci/<some-identifier>	for continuous integration changes
   maint/<some-identifier>	for repository maintenance

6. Make the changes you've discussed, following the ROAR coding style.
   Try to keep the changes focused: it is generally easy to review changes that address one feature or bug at a time. In many of our repositories, you can test your changes locally using

   npm run lint
   npm run test

   Once you are satisfied with your local changes, add/commit/push them to the branch on your forked repository.

7. Submit a pull request.
   A member of the development team will review your changes to confirm that they can be merged into the main code base.
   Pull request titles should begin with a descriptive prefix (for example, ENH: Add adaptive testing):

   • FIX: bug fixes
   • ENH: enhancements or new features
   • TST: new or updated tests
   • DOC: new or updated documentation
   • STY: style changes
   • REF: refactoring existing code
   • CI: updates to continous integration infrastructure
   • MAINT: general maintenance
   • For works-in-progress, add the WIP prefix in addition to the descriptive prefix. Pull-requests tagged with WIP: will not be merged until the tag is removed.

8. Have your PR reviewed by the development team, and update your changes accordingly in your branch.
   The reviewers will take special care in assisting you to address their comments, as well as dealing with conflicts and other tricky situations that could emerge from distributed development.

ROAR coding style

Most ROAR repositories use prettier and eslint to format code contributions to a common style. Pull requests will automatically be checked for compliance durint review.

When you run npm install, it should initialize initialize Husky pre-commit hooks to automatically format your local changes for style compliance before you commit them. This is the easiest way to ensure that your much appreciated contribution is not delayed due to formatting or style compliance. If you know what you're doing and want to explicitly skip these pre-commit hooks, follow these directions.

Documentation

We ask that you document your contributions by following these standards:

1. Document as you code by writing comments in your code to explain "why" something is done a certain way, not just "what" the code does. This is especially important for complex logic or decisions that might not be immediately obvious to someone new to the codebase.

2. Write clear and descriptive commit messages. They are the first line of documentation and provide a history of changes and the reasoning behind them.

3. Use JSDoc comments to document modules, namespaces, functions, classes, methods, and interfaces. For all functions, classes, and methods, document the parameters, return types, exceptions, and any side effects.

4. Update the ROAR developer documentation if necessary. We maintain centralized ROAR developer documentation in a separate repository. This allows us not only to centralize documentation of each ROAR project, but also to document the interactions between different ROAR components. We ask that all code contributors update the centralized ROAR developer documentation if necessary.

5. Be direct. Use the active voice and present tense. Avoid jargon, colloquialisms, and unnecessarily complex words. The goal is to be understood by as wide an audience as possible.

6. Explain technical terms. When you must use technical terms, briefly explain them or link to a good external explanation.

7. Keep it short and sweet. More documentation isn't always better. Be concise. Aim to provide maximum value with minimum words to respect the reader's time.

Licensing

Nearly all ROAR repositories are licensed under the Stanford Academic Software License for ROAR:tm:. By contributing to ROAR, you acknowledge that any contributions will be licensed under the same terms as those listed in the repository.

Notes for core developers and maintainers

Pull Request Reviews

As a core developer, your insights and feedback are invaluable to maintaining the high quality and consistency of our project. The review process is not only about ensuring code quality but also about fostering a collaborative and welcoming community. Here are some guidelines to help you conduct effective and constructive pull request (PR) reviews:

1. Timeliness

   • Respond promptly: Aim to review PRs within a reasonable timeframe, ideally within 48 hours during the workweek. This helps maintain project momentum and keeps contributors engaged.

   • Communicate delays: If you are unable to review within the expected timeframe, inform the contributor, so they know their work hasn't been overlooked.

2. Thoroughness

   • Review completely: Ensure you have a clear understanding of the PR's purpose and changes. Review all changes thoroughly, not just the parts that might be most relevant to your expertise.

   • Test locally: When possible, checkout the PR branch and test the changes locally. This can help catch issues that are not immediately visible through code review alone.

3. Constructive Feedback

   • Be kind and respectful: Remember that behind every contribution is a person who has invested time and effort. Approach your review with kindness and respect. Offer constructive feedback and avoid harsh criticism.

   • Suggest improvements: If you see areas for improvement, provide clear, actionable suggestions. Include code snippets, links to documentation, or examples when possible.

4. Clarity and Precision

   • Be specific: When requesting changes, be specific about what needs to be addressed and why. This helps contributors understand your feedback and how to act on it.

   • Ask questions: If something is unclear, ask questions rather than making assumptions. This can lead to better understanding and sometimes even simpler solutions.

5. Encouragement and Acknowledgment

   • Praise good work: Acknowledge and praise good work. Recognition can be incredibly motivating and encourages further contributions.

   • Encourage discussion: Encourage contributors to discuss their approach, especially if there are multiple ways to solve a problem. Open dialogue can lead to innovative solutions and stronger community bonds.

6. Security and Compliance

   • Check for security flaws: Always be on the lookout for potential security vulnerabilities in contributions. If you suspect a security issue, flag it immediately following the project's security protocol.

   • Ensure compliance: Verify that contributions comply with the project's licensing and contribution guidelines. This includes checking for proper attribution of third-party code and ensuring that all dependencies are compatible with the project's license.

Releases

Most ROAR repositories publish three different kinds of releases:

• Development releases are published with temporary unique URLs for each submitted pull request (PR).

• Staging releases are published on every commit to the main branch. For example, the roar-dashboard repoitory publishes these to roar-staging.web.app.

• Production releases are published on every version tag.

In order to publish a production release, you must run

npm version <major|minor|patch>

and the npm scripts should take care of the rest. Do this on the main branch with a clean working directory after all of the changes that you would like to incorporate have been merged.

So a typical release workflow would be

1. Merge all the PRs with changes you'd like to release into the main branch.

2. Test the consolidated changes on the staging release.

3. Once satisfied, publish the production release on the main branch using npm version <major|minor|patch>.

4. After all of the npm scripts and GitHub actions have completed, there will be a new version tag on GitHub. Using the GitHub web console, create a new release from that tag, complete with release notes.

Footnotes

1. The imposter syndrome disclaimer was originally written by Adrienne Lowe for a PyCon talk, and was adapted based on its use in the README file for the MetPy project. ↩