Buy this book on Lulu.

This book is sold at cost. If you would like to support this project, you can send $5 (or any other amount) via PayPal. All money will be used to pay for third-party editing and some much-needed graphic design work.


Copyright © 2017-18 Greg Wilson.
All content made available under the Creative Commons - Attribution License.

CC-BY License

Generated 2018-07-19.

C) Joining Our Community

This appendix describes how you can become part of our community by using, sharing, and improving this material.

C.1) Contributor Covenant

The contributor covenant laid out below governs contributions to this book. It is adapted from the Contributor Covenant version 1.4; please see Appendix D for a sample code of conduct for use in classes and other learning situations.

Our Pledge

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, education, socioeconomic status, nationality, personal appearance, race, religion, or sexual identity and orientation.

Our Standards

Examples of behavior that contributes to creating a positive environment include:

  • Using welcoming and inclusive language
  • Being respectful of differing viewpoints and experiences
  • Gracefully accepting constructive criticism
  • Focusing on what is best for the community
  • Showing empathy towards other community members

Examples of unacceptable behavior by participants include:

  • The use of sexualized language or imagery and unwelcome sexual attention or advances
  • Trolling, insulting/derogatory comments, and personal or political attacks
  • Public or private harassment
  • Publishing others’ private information, such as a physical or electronic address, without explicit permission
  • Other conduct which could reasonably be considered inappropriate in a professional setting

Our Responsibilities

Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.

Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this covenant, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.

Scope

This covenant applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.

Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at [gvwilson@third-bit.com](mailto:gvwilson@third-bit.com). All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.

Project maintainers who do not follow or enforce the covenant in good faith may face temporary or permanent repercussions as determined by other members of the project’s leadership.

C.2) Using This Material

This material has been used in many ways, from a multi-week online class to an intensive in-person workshop. It’s usually possible to cover large parts of Chapters [s:models][s:process], Chapter 8, and Chapter 10 in two long days.

In Person

This is the most effective way to deliver this training, but also the most demanding. Participants are physically together. When they need to practice teaching in small groups, some or all of them go to nearby breakout spaces. Participants use their own tablets or laptops to view online material during the class and for shared note-taking (Section 9.7), and use pen and paper or whiteboards for other exercises. Questions and discussion are done aloud.

If you are teaching in this format, you should use sticky notes as status flags so that you can see who needs help, who has questions, and who’s ready to move on (Section 9.8.1). You should also use them to distribute attention so that everyone gets a fair share of the instructor’s time (Section 9.8.2), and as minute cards to encourage learners to reflect on what they’ve just learned and to give you actionable feedback while you still have time to act on it (Section 9.8.3).

Online in Groups

In this format, 10–40 learners are together in 2–6 groups of 4–12, but those groups are geographically distributed. Each group uses one camera and microphone to connect to the video call, rather than each person being on the call separately. We have found that having good audio matters more than having good video, and that the better the audio, the more learners can communicate with the instructor and other rooms by voice rather than via text online.

The entire class does shared note-taking together, and also uses the shared notes for asking and answering questions. (Having several dozen people try to talk on a call works poorly, so in most sessions, the instructor does the talking and learners respond through the note-taking tool’s chat.)

Online as Individuals

The natural extension of being online in groups is to be online as individuals. As with online groups, the instructor will do most of the talking and learners will mostly participate via text chat. Good audio is once again more important than good video, and participants should use text chat to signal that they want to speak next (Appendix F).

Having participants online individually makes it more difficult to draw and share concept maps (Section 3.5) or give feedback on teaching (Section 8.5). Instructors should therefore rely more on exercises with written results that can be put in the shared notes, such as giving feedback on stock videos of people teaching.

Multi-Week Online

This was the first format used, and I no longer recommend it: while spreading the class out gives people time to reflect and tackle larger exercises, it also greatly increases the odds that they’ll have to drop out because of other demands on their time.

The class meets every week for an hour via video conferencing. Each meeting may be held twice to accommodate learners’ time zones and schedules. Participants use shared note-taking as described above for online group classes, post homework online between classes, and comment on each other’s work. (In practice, comments are relatively rare: people strongly prefer to discuss material in the weekly meetings.)

C.3) Contributing and Maintaining

This book is a community resource: contributions of all kinds are welcome, from suggestions for improvements to errata and new material. All contributors must abide by the contributor covenant presented above; by submitting your work, you are agreeing that it may incorporated in either original or edited form and release it under the same license as the rest of this material (Appendix A). If your material is incorporated, we will add you to the acknowledgments (Section 1.6) unless you request otherwise.

  • The source for this book is stored on GitHub at https://github.com/gvwilson/teachtogether.tech. If you know how to use Git and GitHub and would like to change, fix, or add something, please submit a pull request that modifies the LaTeX source in the tex directory. If you would like to preview your changes, please read the instructions in the BUILD.md file in the root directory of the project.
  • If you simply want to report an error, ask a question, or make a suggestion, please file an issue at https://github.com/gvwilson/teachtogether.tech. You need to have a GitHub account in order to do this, but do not need to know how to use Git.
  • If you do not wish to create a GitHub account, please email your contribution to mailto:gvwilson@third-bit.com with either “T3” or “Teaching Tech Together” somewhere in the subject line.. We will try to respond within a week.

Please note that we also welcome improvements to our build process, tooling, and typography, and are always grateful for more diagrams; please see the file BUILD.md in the root directory of the book’s GitHub repository at https://github.com/gvwilson/teachtogether.tech for more information. Finally, we always enjoy hearing how people have used this material: please let us know if you have a story you would like to share.

A Teaching Commons

Section 13.4 defined a commons as something managed jointly by a community according to rules they themselves have evolved and adopted. Open source software and Wikipedia are both successful examples; the question is, why don’t teachers build lessons collaboratively in the same way? People have proposed a variety of reasons, but I don’t think any of them hold up to close scrutiny.

Software Carpentry is proof by implementation that a teaching commons can produce and maintain high-quality lessons that hundreds of people can use [Wils2016]. I hope you will choose to help us do the same for this book. If you are new to working this way:

Start small.

Fix a typo, clarify the wording of an exercise, correct or update a citation, or suggest a better example or analogy to illustrate some point.

Join the conversation.

Have a look at the issues and proposed changes that other people have already filed and add your comments to them. It’s often possible to improve improvements, and it’s a good way to introduce yourself to the community and make new friends. (To make this as easy as possible, we tag some issues and proposed changes as “Suitable for Newcomers” or “Help Wanted”.)

Discuss, then edit.

If you want to propose a large change, such as reorganizing or splitting an entire chapter, please file an issue that outlines your proposal and your reasoning and tag it with “Proposal”. We encourage everyone to add comments to these issues so that the whole discussion of what and why is in the open and can be archived. If the proposal is accepted, the actual work may then be broken down into several smaller issues or changes that can be tackled independently.