guidelines for PR submitters to include preview?

[tdhock]

Hi @kbodwin

For animint gallery updates, https://github.com/animint/gallery?tab=readme-ov-file#add-your-data-viz-to-the-gallery we have adopted a policy that the PR submitter should fork the repo, re-build the gallery, then submit a PR from their fork of the gh-pages branch, and include a link to the rendered version of their fork.

I was wondering if you think this workflow would be helpful for The Raft?

• first I would fork to tdhock/The-Raft@gh-pages
• then I would write a new post and run quarto build
• then I would push to my fork
• then I would submit a PR from tdhock/The-Raft@gh-pages to this repo, rdatatable-community/The-Raft@gh-pages

The advantage of this approach is that the rendering/building work is moved away from the PR reviewer team, and to the PR submitter (makes reviewing the PRs easier in my experience).

If this makes sense to you, I can submit a PR to update https://github.com/rdatatable-community/The-Raft?tab=readme-ov-file#contributing-to-this-blog

Also I see on this repo there is both a main and a gh-pages branch, is that necessary? In https://github.com/animint/gallery we made the gh-pages branch default to avoid confusion (main/master is not used / not necessary).

[tdhock]

even better, we could migrate from github pages to netlify for deploying the raft.
I recently set this up for a quarto project, and it is actually pretty easy.
The yml config is here https://github.com/animint/animint-manual-en/blob/main/.github/workflows/build-book.yml

slides which explain the setup are here (in French): https://docs.google.com/presentation/d/1WpRZs9qz9wm1yik_MLj8tIJyWuL5-IBPYKLhOHZ9X4Y/edit?slide=id.g36589d6a5bc_0_59#slide=id.g36589d6a5bc_0_59

the main advantage of netlify over github pages is that you get a preview web site (different url from your main site) for every PR.