This document outlines a curriculum for teaching open source software development to college students. It covers topics like communications tools, version control, lectures, career panels, and workshops for making contributions. It emphasizes the importance of inclusivity and addressing barriers to participation. Lessons learned include testing environments thoroughly, helping people ask for and provide help, emphasizing all types of contributions, and modeling failure over just success. The document promotes diversity in open source and getting involved with the OpenHatch organization.

1. Diversity, outreach, and
teaching free software to
college students

4. A day in the life of
Open Source Comes to Campus

5. Laptop Setup

6. Communications Tools
●
Mailing Lists
●
IRC
●
Issue Trackers
–
Navigating trackers
–
Reading issues
---->
●
Version Control

7. Practicing Git
Lecture
Demo
Activity

8. Career Panel

9. Lunch!

10. Contributions Workshop
Lots of bugs
from lots of
projects
Lots of bugs from a
few projects
Lots of bugs
from mentors'
projects

11. http://bit.ly/osctc-curriculum
https://openhatch.org/wiki/Open_Source_Comes_
to_Campus/Curriculum
(In addition to a curriculum, we also provide help with publicity, staffing, logistics,
and finding funding. Check out http://campus.openhatch.org.)

12. 5 stories
and the lessons we learned from them

13. “lots of downloads, need an approved account to have access… had to
create own database on localhost… tears clouding vision”
Lesson #1: Test development environments thoroughly!
http://opensource-events.com
(“essentials” at http://campus.openhatch.org/projects.html)
Setup sprints

15. Lesson #2: Help people ask for help (and help people give it).
- small group activities where progress/confusion is more clear
- mentor guide
- post-it notes

16. Contains:
● Principles to keep in mind when working with
students
● “Everything is a learning experience”
● “Approach everyone”
● “Autonomy of students”
● Signs a person is struggling
● Questions you can ask students to provoke
conversation
● Common problems:
● Including practical issues, like what to do when
a student comes in late.
● Also includes psychological issues, like the
tendency of students to assume fault for failure.

17. Software Carpentry's post-it note method.

18. Lesson #3: Some people are worried about bothering open source projects.
●
●
●
●
●
Create space for students to express their worries and hesitations.
Explicitly address common worries so students know they're not alone.
Showcase the unique contributions newcomers can make:
● Only a newcomer can view a project with fresh eyes.
● Newcomers can help improve documentation and make projects more
welcoming by giving feedback when they get stuck.
● #openhatch Setup Sprints
Be enthusiastic, welcoming, and sincere. If you don't find joy in teaching
and helping, maybe outreach isn't for you.
Find projects for your events that are willing to put in the effort to be
accessible.

19. Lesson #4: Emphasize the value of all different kinds of contributions.
●
●
●
●
Make sure there are a variety of non-programming tasks to do at events,
including: improving documentation, reproducing bugs, testing fixes, drawing
prototypes, designing logos, translation, responding to user questions, and more.
Have mentors who specialize in non-programming tasks.
De-emphasize programming in your publicity materials, and explicitly welcome
non-coders.
Non-code contributions to OpenHatch *today*:
● Carol Willing helping at the OpenHatch booth in the exhibitor hall.
● Britta Gustafson tweeting to publicize this talk.
● Asheesh Laroia and Mark Holmquist answering questions in #IRC.

20. Lesson #5: It's more important to role-model failure than success.
●
●
●
Make sure you and your mentors are comfortable admitting when you don't
know something, and narrating your attempts to find a solution. When you
figure out what went wrong, make sure students understand, too.
Don't use negative self-talk, instead show curiosity and enjoyment. Mistakes
are awesome learning experiences.
There are activities that can elicit failure from mentors, for instance:
● Mel Chua suggests standing up in front of a group and asking them to give
you a topic you know nothing about to research. For instance, at OSCTC,
we've said, “Give us a free software project to learn about.”

21. Increasing Gender Diversity
●
●
●
●
Work with women's groups to run events
● Social network effects
● Signaling
Code of Conduct
● Signaling again
● You may need it
● Ada Initiative has templates
Emphasize:
● The event is for newcomers. Any level of knowledge is welcome: “Don't know what free
software is? Come and find out!”
● The event is not just for programmers. “You do not need to know how to program to
contribute to free software.”
Diversity of projects, not just people:
● Science majors
● Humanitarian FLOSS projects, civic tech/open government
● Hardware, art, education, medicine
● Most fields have better gender diversity than FOSS (some have the opposite problem!)

22. Other kinds of diversity...
gender - women, genderqueer, agender, non-gender conforming, masculinity-femininity
spectrum, fixed/fluid state
biological sex - transgender, intersex
sexuality - lesbian, gay, bisexual, queer, pansexual, asexual
relationship orientation - polyamorous, open
race and ethnicity
nationality, country/region of origin - country of personal or familial origin
citizenship status - immigrant/documentation status
language - people whose first language is not English (or the otherwise dominant
language of the region), people who communicate through sign language, people who
communicate through assistive devices or software
religion/spirituality/affiliation
political party/movement affiliation - political party, feminist,
elective dietary choices - vegetarian, vegan, Kosher, Halal, straight edge, teetotaler
physical appearance - height, weight, shape, hereditary disfigurement/injury,
mod/surgical history, cultural "beauty" spectrum
chronic disease - diabetes, cancer, Crohn's, epilepsy, migraines, allergies
mental illness or disorder - schizophrenia, depression, eating disorder, addiction, bipolar
disorder
developmental/neurological delay - retardation/cognitive impairment, dyslexia, ADHD,
speech impediment, brain injuries
physical disability - impaired mobility, sight-/hearing-/sensory-impaired
veteran/military status

23. Other kinds of diversity (continued)
experience with violent conflict - refugee/asylum seeker
personal violence/trauma survivor - child soldiers, abuse survivors, former cult
members
biological age - both actual and perceived/assumed
dependent status - you are or you have: children/elderly/immobilized
parental status - you are or you have: biological/adopted/foster children,
guardianship
relationship status - single/partnered/married/divorced/multiple partnered
economic status - current and former
access to healthcare
access to travel/mobility
access to education
access to technology - includes type of technology, bandwidth, screen size,
availability/ownership
professional experience level
education level - level of formal education completed, whether or not a person
has graduated from college/university, self-taught
(Thanks to Cori Johnson and Ashe Dryden for compiling this list.)

24. An exercise
●
●
What is the last contribution to a free software
project that you made?
Write down what you needed to know in order
to make that contribution.

25. ●
●
●
●
●
●
To pick the issue:
● That the project exists, and enough of what it does to know that I want to
contribute to it.
● Where to find the issue tracker and source code, and how to navigate the
tracker/repository.
To understand the issue:
● That a probability has to be between zero and one.
● That floating point numbers can cause rounding errors*.
● How to read the documentation for np.clip so I can implement it correctly.
To make the change:
● How do I set up the development environment/install SciPy? How do I use
git/github/version control?
● Which files (and functions, and lines) contain the relevant code*?
● Do I need to change the documentation, and where?
To test the change:
● How can I tell how the change affected performance*?
● How do I run the SciPy unit tests?
● How do I alter the SciPy unit tests to reflect this change*?
To contribute the change:
● How does Git/github work (again)? How do I submit a pull request? How do
you amend a pull request in response to feedback?
● What are the formatting practices (PEP 8, SciPy-specific conventions)*?
How to ask for help.

26. For each item...
●
Is this issue-specific? Project-specific? Free
software-specific?
●
Do you already know a good resource to teach this?
●
Do you have an idea for a new way to teach this?
●
Is this a technical skill? Does it require social
interaction? Might it intersect with diversity issues?
Who in the outreach community might be able to help
you with this?

27. Non-CS majors and non-CS
professionals are much less
likely to be experienced with unit
testing.
●
●
●
General question, maybe
teach “how to search the
web for the right
tool/module”.
To test the change:
● How can I tell how the change affected performance*?
● How do I run the SciPy unit tests?
Project-specific, SciPy has good
● How do I alter the SciPy unit tests
documentation on this.
to reflect this change*?
How does testing even work? I want a
good general resource for this.
To contribute the change:
● How does Git/github work (again)? How do I submit a pull
request? How do you amend a pull request in response
to feedback?
OpenHatch has good documentation for the first two
● What are the
questions. We should add info for the third!
formatting practices (PEP 8, SciPy-specific conventions)*?
How to ask for help.
Minority
groups may
have extra
trouble.
OpenHatch teaches the technical side (mailing lists, IRC)
but we could do a better job addressing psychological
hurdles (shyness, fear of being a burden, etc.) What
resources already exist? Who could I ask? Educators
like Mel Chua, Heidi Ellis might be able to help.
SciPy has
good docs for
this.

28. Share your knowledge
(not just your code)
●
●
Put your email address on the sheet at the
front of the room, and I will scan and share
them with everybody.
(If you want to be anonymized when I share
them, that's cool, just write a note on the
sheet.)

29. Summary
●
●
●
Everything is a learning experience!
● For organizers & mentors as well as attendees.
● Role model failure; encourage feedback.
Diversity leads to diversity.
● Diverse organizers → greater accessibility, diverse attendees
● Diversity of contributions! Diversity of projects!
Find unspoken assumptions and address them.
● Address psychological barriers.
● Run activities to address gaps in skill/knowledge.
● Document, document, document.

30. Get involved with OpenHatch
●
●
●
●
Help organize an event, or volunteer at one.
● Email hello@openhatch.org
Make your project an OpenHatch-affiliated Project:
● http://campus.openhatch.org/projects.html
Contribute to our projects:
● http://bit.ly/oh-contribute
Join our mailing lists and/or hang out on IRC:
● http://bit.ly/contact-open-hatch