Contributing guidelines for adding input files to /shared

Open
#357 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Stale
Domain
documentation

Research direction

Start by locating the contributing guidelines and reading the cited discussion in #347, along with scripts/link-data.sh. Document how contributors should store and obtain files, when to use the script or S3, and how pull requests should explain development and review steps. Done means the guidance covers the relevant paths without requiring readers to infer the workflow.

Written by the indexing model from the issue text.

Description

contributing

As we develop procedures for contributions, we should add more explicit suggestions for how files should be managed and how we would expect development/review to proceed when new files need to be added for a notebook or module.

Some of this discussion was in comments to #347, where I started to outline where files can be stored and how they will be referenced, but more is needed.

Below are some of the relevant quotes from @jaclyn-taroni

I think the contributing guidelines need a little more information about how you envision folks will develop material. Where are we supposed to put files? What should we do to get the correct files? https://github.com/AlexsLemonade/training-modules/pull/347#pullrequestreview-594769500

What's missing for me in here (but I would say it is implicit) is what I need to do if I have new files, i.e., when I am working on pathway analysis changes, the single point of truth is /shared so that's where I should put them during development and then I add them to scripts/link-data.sh. https://github.com/AlexsLemonade/training-modules/pull/347#discussion_r579683159

How do I get the files I need to perform development? Do I run the scripts/link-data.sh or do I get them from S3? https://github.com/AlexsLemonade/training-modules/pull/347#discussion_r579683454

Could an interim solution be some suggestions about multiple paths (as in series of steps, not file paths!) one could take depending on the situation? Rather than couch it as "here's exactly what to do." (Might add something about telling reviewers how to test in PRs, too.)

You may be able to tell that I am imagining a situation where I emerge from a meeting about something else entirely and want to run something I am reviewing myself. 😅

Dominant language
HTML
Stars
80
Forks
35
Avg merge
7h
Merged PRs (30d)
3

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from AlexsLemonade/training-modules

All issues in AlexsLemonade/training-modules

Similar issues

More Documentation issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.