Skip to content

Latest commit

 

History

History
244 lines (183 loc) · 14.4 KB

CONTRIBUTING.md

File metadata and controls

244 lines (183 loc) · 14.4 KB
Raw

Contributing

The Epiverse-TRACE is an open source project, and we welcome contributions of all kinds: new documentation, fixes to existing material, bug reports, and reviews of proposed changes are all welcome.

Contributor Agreement

By contributing, you agree that we may redistribute your work under our license. In exchange, we will address your issues and/or assess your change proposal as promptly as we can, and help you become a member of our community. Everyone involved in Epiverse-TRACE agrees to abide by our code of conduct.

How to Contribute

The easiest way to get started is to file an issue to tell us about a spelling mistake, some awkward wording, or a factual error. This is a good way to introduce yourself and to meet some of our community members.

  1. If you do not have a GitHub account, you can send us comments by email. However, we will be able to respond more quickly if you use one of the other methods described below.

  2. If you have a GitHub account, or are willing to create one, but do not know how to use Git, you can report problems or suggest improvements by creating an issue. This allows us to assign the item to someone and to respond to it in a threaded discussion.

  3. If you are comfortable with Git, and would like to add or change material, you can submit a pull request (PR). Instructions for doing this are included below. For inspiration about changes that need to be made, check out the list of open issues.

Note: if you want to build the website locally, please refer to The Workbench documentation.

Where to Contribute

  1. If you wish to change this tutorial, add issues and pull requests here.
  2. If you wish to change the template used for workshop websites, please refer to The Workbench documentation.

What to Contribute

There are many ways to contribute, from writing new exercises and improving existing ones to updating or filling in the documentation and submitting bug reports about things that do not work, are not clear, or are missing. If you are looking for ideas, please see the list of issues for this repository.

Comments on issues and reviews of pull requests are just as welcome: we are smarter together than we are on our own. Reviews from novices and newcomers are particularly valuable: it's easy for people who have been using these tutorials for a while to forget how impenetrable some of this material can be, so fresh eyes are always welcome.

What Not to Contribute

Our tutorials already contain more material than we can cover in a typical workshop, so we are usually not looking for more concepts or tools to add to them. As a rule, if you want to introduce a new idea, you must (a) estimate how long it will take to teach and (b) explain what you would take out to make room for it. The first encourages contributors to be honest about requirements; the second, to think hard about priorities.

We are also not looking for exercises or other material that only run on one platform. Our workshops typically contain a mixture of Windows, macOS, and Linux users; in order to be usable, our tutorials must run equally well on all three.

Contribution roles

For a tutorial your role could be of a Developer, Reviewer, or Maintainer. Our goal is to keep an homogeneous package environment among Developers and Reviewers of a “feature branch” different to main. This implies that:

  • We will use sandpaper::use_package_cache() in the R project.
  • The Developer will need to register the package version to use in a renv.lock file.
  • The Reviewer will need to restore environment defined by Developer, if needs to build the website locally.

Developer:

You can follow these steps:

  • Update the set of workbench packages:
install.packages(c("sandpaper", "varnish", "pegboard", "tinkr"),
  repos = c("https://carpentries.r-universe.dev/", getOption("repos")))

To contribute with a new episode:

  • Create a new feature branch. Write in there your contribution.
  • Create an Issue to report the start of your WIP feature branch. Add the WIP label to it. This aims to keep one contributor per feature branch.
  • Create a new episode with sandpaper::create_episode_md("Episode Name")

If you need to work with the most recent versions of packages:

  • Use sandpaper::update_cache(). This will:
    • Fetch updates from CRAN or GitHub,
    • Update the renv.lock file with package specific versions, and
    • Update the cache. This is located in a folder called renv/library/ in the same directory of the renv.lock, only visible locally.
  • Push the updated renv.lock file to the GitHub “development branch”.

If you need to work with a specific stable version of a package:

  • Use sandpaper::pin_version(). This will:
    • Update the renv.lock file with the specific version,
    • Update the cache.
  • Push the updated renv.lock file.

If you need the version of a package that is not programmatically loaded, i.e., is loaded as part of the dependency tree of an specific package:

  • Create an episodes/install.R file that lists the installation scripts for the packages in your lesson.
  • Run the episodes/install.R file to install the list of packages.
  • Run sandpaper::update_cache(). Before you accept the update, verify that the expected version number is listed as an update. After this, review the renv.lock file if this modified the file as expected.

To merge your new episodes:

  • Make a Pull request (PR). You can follow the stesp on using GitHub.

Reviewer:

You can follow these steps:

  • Install the set of workbench packages:
install.packages(c("sandpaper", "varnish", "pegboard", "tinkr"),
  repos = c("https://carpentries.r-universe.dev/", getOption("repos")))
  • Clone the repository or Pull to update the branch to review on Rstudio.
  • Checkout or Switch to the branch to review.
  • Use sandpaper::manage_deps() to align the packages in your cache with the ones in the renv.lock file (defined by the Developer).
    • You may need to manually install certain packages used in the lesson - please check the output in case sandpaper::manage_deps() fails. This can be resolved on a trial and error basis.
  • Render lesson with sandpaper::build_lesson(). This will open an HTML tab in your browser to review. This HTML format is how the website is going to look like online.
  • Make any edit suggestion to the .Rmd files inside the episodes/ folder of the branch under review. For big changes, create an issue first.

If you have issues at the Render step, follow these two steps:

  • Verify or wait until the branch is under Pull Request (PR) with all checks passed.
  • Access to the md-outputs-PR-## branch on GitHub to read the .md files for each episode.

Consider that:

  • The number ## is equal to the PR number.
  • .md files contain generated lesson content for review with knitted text, code, and figures.
  • These .md files generate the .html of the website and look similar to how it's going to look like online.

Maintainer:

You can follow this reference:

Writing guidelines

To write a new episode, follow these guidelines

  • Add new .Rmd files to the episode/ folder.
  • Add file name to the config.yaml under episodes: in the order you want the tutorials to appear in.
  • Add required data sets to the episodes/data/ folder.
  • Add glossary terms to learners/reference.md.
  • Add commonly used links to links.md.
  • Add a visible callout for prerequisites at the beginning following the ETK modules notation.
  • Add an introduction section with the expected summative assessment.
  • Add diagrams using Diagrammer with greek letters for parameters to visually represent mathematical models.
  • Use callouts for complementary concepts and function arguments details.
  • Request a review via PR.

Using GitHub

If you choose to contribute via GitHub, you may want to look at How to Contribute to an Open Source Project on GitHub. In brief, we use GitHub flow to manage changes:

  1. Create a new branch in your desktop copy of this repository for each significant change.
  2. Commit the change in that branch.
  3. Push that branch to your fork of this repository on GitHub.
  4. Submit a pull request from that branch to the upstream repository.
  5. If you receive feedback, make changes on your desktop and push to your branch on GitHub: the pull request will update automatically.

NB: The published copy of the lesson is usually in the main branch.

Each lesson has a team of maintainers who review issues and pull requests or encourage others to do so. The maintainers are community volunteers, and have final say over what gets merged into the lesson.

Rebase

  • If you need to get the latest commits in the main branch to use them in your development, we recommend rebasing your feature branch. Rebase will keep the commit history linear. First, make sure that you are the only contributor in the feature branch, then:
    • In the local repository, follow all these five steps:
      1. Switch to the main branch: git checkout main
      2. Pull the main branch: git pull
      3. Switch to your feature branch: git checkout feature
      4. Rebase your feature branch onto main branch: git rebase main
      5. Push your rebased featured branch using the --force option (this must be a forced update): git push --force
    • In the remote repository, only if you are in a PR:
      • Update your PR branch with Update with Rebase.
      • To pull changes to your local repository from an updated PR branch with rebase in the remote, run: git pull --rebase

Other Resources

The Epiverse-TRACE is a global organisation with volunteers and learners all over the world. We share values of inclusivity and a passion for sharing knowledge, teaching and learning. There are several ways to connect with The Epiverse-TRACE community listed at https://github.com/epiverse-trace/ including via social media, slack, newsletters, and email lists. You can also reach us by email.