Step 1: Register as a Volunteer

December 30, 2025 · View on GitHub

Before doing anything else, you must register as a volunteer.

Step 2: Read through and Agree to the Code of Conduct

Before opening an issue, commenting, etc you must read and agree to the Code of Conduct.

Step 3: Finding an Issue to Work On

External Hackathon Participants

Techtonica Volunteers

Find any unassigned open issue.

All Contributors

  • If you find an issue that sounds interesting to you and you have the knowledge to complete it...
    • Confirm no one is already assigned to it has in-progress work
    • Confirm no one has commented already asking to be assigned - assignments are assigned to the first commenter
  • Leave a comment stating the following:
    • Formally ask to be assigned to the issue (feel free to follow it up with a slack message).
    • Formally acknowledge that you agree to the Code of Conduct.
    • Include confirmation that you have filled out the Volunteer Google Form
    • Include any clarification questions you may have after reading the description. Specific questions work better, e.g. "Which file should change?" rather than asking a broader question such as requesting "an explanation" or "more details"
  • Once you have been assigned on the issue, do not request assignment to any other issues until you have opened a Pull Request. If you changed your mind and would rather work on a different one, comment on the originally assigned issue to request to be unassigned
  • Create a pull request of the changes requested by completing the prompted pull request template.

🎗️ Please note, all repo support will be provided on weekdays, U.S. Pacific Timezone. The quickest means of support would be to join the Slack #curriculum channel.

Working on your Issue

  • Comment on the issue directly from the TO-DO column, that means it is available, even if there's an "assignee". If you have a question (feel free to follow it up with a Slack message).
  • In the issue, you should find a link for a lesson outline and for corresponding slides.
  • People are welcome to team up on an issue. If you see someone is already assigned but you want to help, leave the other assignee a message on the issue about collaborating.
  • Please note any time sensitive due dates or labels! Any amount of help is appreciated, but if the deadline approaches and you won't be able to complete it, please leave a comment about your progress and unassign yourself from the issue so someone else can pick it up. If you forked the repo, go ahead and make a pull request with what you have, and transfer ownership of a copied slideshow to info@techtonica.org.
  • To create an topic outline, fork the repo or commit directly onto the main branch. Here is a topic outline template that explains what we need for each section.
  • To edit a slideshow, you'll need to request edit permission by clicking View Only > Request Edit Access, or message info@techtonica.org. If you are logged into an account ending in @gmail.com, you can simply make a copy, edit, and transfer ownership to info@techtonica.org when you finish. Either way, save on top of the sample template used in the slide, and cut any slides you find unnecessary.
  • To make a video, one effective solution has been to record your screen as you explain the lesson slides. An alternative can be a video found online that covers all the objectives of the lesson in a way suited to beginners.
  • Here is an example of a great lesson trio: MongoDB Slides, MongoDB Lesson Outline, MongoDB Video.

Slack Communication

If you are in Techtonica's slack space, please communicate about curriculum related work or requests in the #curriculum channel. If you are not in the Techtonica slack community and would like to be added, after having completed the volunteer form, please kindly search your email for You can join our Slack by clicking here or send info@techtonica.org an email.

Completed Curriculum Work

Place a "completed" label on the issue once you've completed it, make a pull request to Techtonica/curriculum main, and leave comments about your work if you like.

  1. Run npm install at the project root.
  2. Run npm run validate-links to find potentially dead links.
  3. Check links against our list of false positives to weed out the real dead links that need fixing.
  4. Fix links and submit a pull request.
  5. Search & check links from github.com & codepen.io manually. These sites block bots, so we are unable to test them effectively with our tool.

Best Practices

These best practices are very important when working on a development team. Having code reviews from a team means that there will potentially be multiple request for changes from several reviewers. It helps everyone in the code review to understand what has been addressed, iterated on, what remains outstanding, and even gives opportunity to provide any missing context to one another.

GitHub Issues

  • Leave a comment to request an issue for assignment.
  • Communicate status updates about work on issue frequently throughout each sprint week.
  • Communicate any blockers or work dependencies on the issue why ensuring that relevant stakeholders are aware.
  • Communicate when their work is complete with reference to relevant PRs.

Pull Request

When addressing requests for changes it is best practice to do so in a visible and tangible way. You can do this by:

  • Acknowledging each request for change (i.e. feedback was marked with an emoji reaction to show its accepted).
  • Provide a written response to the request for changes in one of the following ways:
    1. summary comment addressing each individual request for change stating how and where (the commit hash referenced) you made the change
    2. reply to each comments generated via GitHub in your generated request for change
    3. share an alternative thought with explanation of why you do not wish to implement the request for change or ask any clarifying questions
  • Once actively stating how you've addressed a request for change alongside referencing the hash in which the change was made, mark the comment as "resolved".
  • Connect the GitHub issue being addressed in the “Development” section
  • Assign yourself as the PR “Assignee”
  • Request a staff, peer, and mentor reviewer
  • The PR title should be descriptive enough to give an at a glance understanding of what you're working on