Skip to content

Latest commit

 

History

History
138 lines (106 loc) · 8.05 KB

CONTRIBUTING.md

File metadata and controls

138 lines (106 loc) · 8.05 KB
Raw
layout title
page
Contributing to UofT Coders

Welcome to the Contributing guideline for UofT Coders. Thanks for taking the time to contribute!

The following is a set of guidelines for contributing to the UofT Coders community, whether it be by teaching a lesson, fixing the website, helping to plan and organize our various events, or taking on a leadership role.

Table of Contents

  1. About UofT Coders

  2. How You Can Contribute

About UofT Coders

UofT Coders was formed to share and learn about coding techniques and best practices for computing and analysis in research. We hold weekly sessions in the format of code-alongs, coworking sessions or journal clubs/discussions. To see our previous and upcoming events, you can visit our Events repo or website. To learn more about our group, you can read our constitution.

Code of Conduct

We adhere to a Code of Conduct and by participating, you agree to also uphold this code. Please report any unacceptable behaviour to uoftcoders@gmail.com. If you feel that a member of the executive team has been violating the Code of Conduct, please email groups.officer@utoronto.ca to report.

How You Can Contribute

Leading a Lesson

The Mozilla Study Group handbook here and here has several very good points about making a lesson. This section summarizes bits of the handbook, but also adds pieces that are missing from it. Check out the lesson bank too.

Creating the Content

  • Minimal use of slides: The most effective sessions are ones that are very hands-on. We strongly encourage live-coding as a teaching method; it's best to keep slides to a minimum or avoid them completely.
  • Keep in mind beginners: Make few assumptions about the knowledge of the audience, unless specified that this is an intermediate level lesson, requiring prior knowledge. Keep it simple. Don't attempt to cover too much material in a single session.
  • Use Built-in Datasets: Use built-in sample datasets instead of requiring attendees to download files.
  • Code Review: The lesson code is posted to GitHub along with a pull request to UofTCoders/studyGroup repository at least 1 full day prior to the lesson date to allow for review. See Submitting a Pull Request

More on Live-Coding

Live-coding is a hands-on method of teaching coding to a group in which the instructor shares their screen with the group and types all commands on their computer while the group follows along. Live-coding is a very effective teaching technique: it forces the instructor to go slowly and ensures that participants get to try out every command being used. It allows learners to experience common errors themselves and debug them in a supportive environment, to explore variations on material as they go, and to immediately check their understanding by trying things hands-on.

Live-coding is a technique used by Software Carpentry. Software Carpentry has lots of great resources explaining the why and how of live-coding:

To see live-coding in action in the UofT Coders group, watch a portion of the Intro to R livestream taught by Ahmed, or look over the code that was covered in an R lesson created by Luke.

Teaching in Class

  • Arrive early: Come 10 minutes before the lesson starts to set up.

  • Introduce yourself: Start by introducing yourself and perhaps why you're teaching this lesson.

  • Stay on time: Keep mindful of the time, lessons are 50-60 minutes long.

  • Start from the very beginning: Briefly explain all aspects of the what you are doing when live-coding including:

    • show how to open the program or IDE (e.g. RStudio/Jupyter Notebook/Shell or Terminal/etc)
    • how to run code (e.g. press Shift+Enter in the Jupyter Notebook)
    • if this is an intro lesson, explain the concept of an IDE or shell
    • importing modules and packages such as import numpy as np or library(dplyr)

  • Live-coding: Use of slides is minimal, majority of lesson involves writing the code WITH the audience during the lesson

  • Stay on topic: There is only one hour, if a question arises that is off-topic, you can always suggest discussing afterwards.

  • Check in with participants: We distribute coloured sticky notes to each participant so that they can flag problems with one colour and success with another colour. Use these indicators to stay aware of your pacing and where the group is at, and/or verbally ask how everyone is doing and leave time for questions.

Fixing and updating the website

There are two ways of fixing or adding to the website, either by:

  • Creating an Issue describing the problem or enhancement. This is technically not doing anything yourself, just recommending something to be done.
  • Submitting a Pull Request from a clone of this repo. This way takes a bit more work and requires knowledge of Git and likely HTML. But we would appreciate any help! No harm in giving it a try! That's a beauty of using Git, it's hard to mess up and break something.

If you want to view the website before submitting a Pull Request to make sure your changes are as you expect, you'll need to:

  • Install Jekyll by following these instructions.
  • To build the site locally, run jekyll serve.
  • The built site can also be viewed at your forked version (https:://yourusername.github.io/studyGroup).

Other Ways to Get Involved

Helping Out at Our Events

We hold various sessions that incorporate code-alongs, and having the help of more advanced users to help out the beginners is very much appreciated.

  • If you see a session topic that is more beginner than your current level, we highly encourage you to attend anyway and help answer questions or provide more one-on-one support during lessons.
  • You can also lend a hand at our co-working sessions to people who have come to work on their own projects.
  • We do a call for helpers for all our Software Carpentry workshops, and we definitely wouldn't be able to run these without the help of volunteers like you!

Taking On A Leadership Role

The planning and organization of our the group and our various events are done by our executive council. We hold elections every April to elect the executive council members, however, we are always open to suggestions on new roles and positions for interested members of the UofT Coders community who wish to take on more a leadership role. To read more about these positions, please see our Council Roles document.