hut101

This page details information for REG coaches wanting to participate in hut101.

The process

1. Identify a project

   Find a suitable issue on an open-source repository, and create a new issue on the hut101 repository (which will automatically add it to the hut101 project board).

   Note that you should have an issue on the original project’s repository (to track the task itself), and a separate issue on the hut101 repository (to track the fact that it’s a hut101 project).

   See the section below for some tips on choosing a suitable project.

2. Wait for student sign-ups

   Student participants will sign up by commenting on your GitHub issue. You should aim to get in touch with them within the next 2 weeks to set up an initial call.

3. Set expectations

   In the call, you and the student will establish the background, level of support needed, agree on timescale and contact hours. This will vary depending on difficulty of the the project itself and the current technical ability of the student, but it is strongly recommended that you aim for something that the student will be able to do in approximately 2 weeks / 2–3 contact hours.

4. Student works on the project

   The student will begin working on the code in their own time. You should review their code as needed throughout this process.

5. Code review

   When the PR is ready, the student will change the PR to ready to review and contact you to let you know they’ve done this. You should then formally review the PR (or someone else on the project can review it if they would like).

   You may need to go back and forth a few times to ensure the contribution is up to standard but please be kind, considerate and helpful with your feedback! At the same time, don’t be afraid to ask for changes if something isn’t right.

6. Wrap up

   Once all fixes/suggested changes have been addressed and you are happy with the quality of the contribution, merge the PR.

7. Feedback

   You may wish to set up a follow up call with the student to review and evaluate the process; this gives them an opportunity to give feedback too.

What makes a good project?

• It’s self-contained: it shouldn’t block other work if it doesn’t get done.
• There’s a clear solution: it’s something that you should know how to accomplish.
• Remember that students will know much less about the language, tooling, and overall project context than you. On top of that, this is unlikely to be their full-time work. If it’s something that takes you more than a couple of hours to do, that’s probably too ambitious.
• It’s on a repository that you’re familiar with. In general, it would be best if it’s a Turing project as that really gets into the ‘research software’ aspect; however, don’t let that limit you, any open-source project is fine.

Useful links

• FAQs
• Code review (The Turing Way): https://book.the-turing-way.org/reproducible-research/reviewing
• The Turing Way: https://book.the-turing-way.org/