Scheduling early transition to Workbench

[tobyhodges]

Short version: are you are willing to volunteer your lesson for early transition to The Carpentries Workbench
infrastructure?

---

Longer version below:

As I hope you are already aware, @zkamvar and the rest of the Curriculum Team are preparing to roll out the new lesson infrastructure, The Carpentries Workbench, across all of The Carpentries official lessons in early May 2023. This means that all Data Carpentry, Library Carpentry, and Software Carpentry lesson repositories will be modified to adopt the new infrastructure at the end of this month.

As you might imagine, coordinating a rollout like this involves a large amount of time and effort, and one thing that will really help us to keep to the schedule and avoid disruption for the community is to be able to prepare some lessons for
transition before the 1st May deadline.

With this in mind, I invite you to volunteer to schedule an early transition for theis lesson repository. If you expect to have time to adopt the Workbench version of the lesson repository in the next couple of weeks, please reply to let me know. As lesson Maintainers, these are the things you will need to be prepared to do for the transition:

1. Be prepared to quickly merge pull requests from Zhian. These pull requests will help update the lesson and aid the transition process.
2. Close any outstanding pull requests. Your repository currently has very few or zero open PRs, but we cannot rule out the possibility that someone will open more in the time between now and when the transition takes place. Open PRs will be invalidated when the transition takes place.
3. Preview the lesson (in the https://github.com/fishtree-attempt organisation) when it is available. Zhian will open an issue in your repository, tagging you when the preview is available. You should reply on that issue if you notice any problems with the Workbench version of the lesson site and repository in the preview.
4. Just before the transition happens, the repository will be temporarily set as read-only and an issue will be opened (see an example from the Maintainer Onboarding curriculum: Transition to Workbench carpentries/maintainer-onboarding#69)
5. After the transition, delete and recreate any forks and local clones you have of the repository and then confirm that you have done so (you will be given specific instructions in an issue).

If you are willing and able to help us ensure a smooth rollout of the Workbench, please reply to let me know that you are happy to volunteer your lesson for early transition. If there is a specific date you would like the transition to take place (or that we should avoid), please also mention that.

[gcapes]

Sure, let's give it a try!

[zkamvar]

Thank you for participating in the early transition to The Workbench. I have been able to render a preview of your lesson at https://fishtree-attempt.github.io/make-novice.

I am tracking issues for your lesson in carpentries/lesson-transition#75. I will be updating the preview next week as I work on any remaining issues.

Please inspect the preview and make note in carpentries/lesson-transition#75 if you see anything that needs to be fixed (e.g extra templating, narrow tables, or malformed text).

[tobyhodges]

Hi @gcapes we are getting ready for an early transition for this lesson, and we have prepared a schedule for early lesson transitions.

Please check that document to see the date we have planned for transitioning this lesson, and adjust the sheet if a different date would be more convenient for you (no more than three lessons per day, please!). The README sheet gives more information. If we don't hear from you, we will go ahead with the transition on the date shown in that document.

[gcapes]

I'm not available on the currrently scheduled day, but the README says there shouldn't be anything to do on the day itself. So I think we can leave things as they stand, and I'll pick it up the day after the transition.

[zkamvar]

Hello all, I will be running some final tests and then will transition this lesson in a few hours. When I make the transition, you can expect three comments on this issue letting you know that the transition has started (example of comment 1), the transition has completed (example of comment 2), and the link to the map of updated commits (example of comment 3).

During this period, your write access will be revoked, but it will be restored if you follow the instructions in the first comment. Thank you all for your support and patience!

[zkamvar]

This lesson will be converted to use The Carpentries Workbench
To prevent accidental reversion of the changes, we are temporarily revoking
write access for all collaborators on this lesson:

• @gcapes (push)

If you no longer wish to have write access to this repository, you do not
need to do anything further.

1. What you can expect from the transition 📹: https://carpentries.github.io/workbench/beta-phase.html#beta
2. How to update your local clone 💻: https://carpentries.github.io/workbench/beta-phase.html#updating-clone
3. How to update (delete) your fork (if you have one) 📹: https://carpentries.github.io/workbench/faq.html#update-fork-from-styles

If you wish to regain write access, please re-clone the repository on your machine and
then comment here with I am ready for write access :rocket: and the
admin maintainer of this repository will restore your permissions.

If you have any questions, please reply here and tag @zkamvar

[zkamvar]

The deed is done. The infrastructure takes a few minutes to bootstrap and cache the packages for the lesson build. Once the build is done, I will switch github pages to deploy from the gh-pages branch and you will have your workbench lesson.

Thank you all for your enthusiasm and your patience!

[zkamvar]

The Workbench version is now live: https://swcarpentry.github.io/make-novice/

In addition, here is map of commits that were changed during the transition

[gcapes]

I am ready for write access 🚀

[zkamvar]

granted! 🎉

[zkamvar]

Since you are the only maintainer, I believe this issue can be closed. Thank you for your work maintaining this lesson (among others)!

A fun note: this was the lesson I used for my instructor checkout

[gcapes]

@zkamvar
$ git push origin main

remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Changes must be made through a pull request.
To github.com:swcarpentry/make-novice.git
 ! [remote rejected] main -> main (protected branch hook declined)
error: failed to push some refs to '[email protected]:swcarpentry/make-novice.git'

Sometimes (fairly often on the shell lesson) it's useful to do a manual merge of a PR. It looks like there's branch protection rules such that I can only merge by PR. I find this quite limiting, and an unnecessary restriction. What's the thinking behind this, and can it be changed back?

[zkamvar]

Sometimes (fairly often on the shell lesson) it's useful to do a manual merge of a PR. It looks like there's branch protection rules such that I can only merge by PR. I find this quite limiting, and an unnecessary restriction. What's the thinking behind this, and can it be changed back?

This change was implemented for three main reasons:

1. it prevents people from accidentally borking the transition
2. it aligns with Github flow (that we teach in maintainer onboarding and which GitHub gently reminds folks to do)
3. several maintainers in other lessons have explicitly requested this because they found that it was too easy to make mistakes with the default branch unprotected

That being said, for lessons where maintainers are unanimous in agreement, we can lift the protection. Since you and the other maintainers (your future self and your past self) are in agreement, I have lifted the protections.

[gcapes]

Thanks!