sslarch.github.io icon indicating copy to clipboard operation
sslarch.github.io copied to clipboard

New member process

Open joeroe opened this issue 4 years ago • 2 comments

In the current version of the website, new members can sign up by editing members.tsv, re-knitting index.Rmd and submitting a pull request. In the new version of the website (which I think we've decided in principle to use – see #9), they would have to create a new .md file in content/members/ and submit a pull request.

I've since learned that hugo can generated pages from data files (JSON or delimited text) so going back to something like the previous workflow is possible (without the re-knitting step of course). But it also occurs to me that both ways could be off-putting to potential members who aren't very comfortable with git, or just editing a live website, and give the impression that prior knowledge of the tools we're using is some sort of test for entry. I can think of a few other ways of doing it (assuming we go with the new hugo setup) and would like to think about which is the most accessible option:

  1. Create <new member>.md and submit a pull request
    • Pros: YAML is easy to understand and edit; you can "Add a file" directly on GitHub and it will guide you on how to submit a PR
    • Cons: No easy way to provide a template for new files on GitHub, as far as I know
  2. Edit <new_member_template.md> and submit a pull request
    • Pros: As for 1, plus easy to see what information is required
    • Cons: Would need some sort of automated workflow for regenerating the template after it's used
  3. Edit members.csv or members.tsv and submit a pull request
    • Pros: Easy to "Edit a file" directly on GitHub and easy to see what information is required
    • Cons: GitHub's editor doesn't do anything special with delimited files, so it's not hard to mess up the commas/tabs
  4. Edit members.json and submit a pull request
    • Pros: As for 3, plus GitHub's editor has syntax highlighting for JSON
    • Cons: JSON syntax isn't particularly human-friendly
  5. None of the above; use another signup method (e.g. by email) and rely on maintainers to update the website
    • Pros: No prior knowledge expected of new members
    • Cons: More work for website maintainers

Currently I think 3 is probably the friendliest. But whichever one we choose, I think it would also be a good idea to:

  1. Have step-by-step instructions on how to sign up on the website and in the README.md
  2. Provide an alternative route that doesn't require using git at all (e.g. filling in a form that creates a issue)

joeroe avatar Jan 22 '21 10:01 joeroe