conduct

There are several key principles we expect all contributors to follow when contributing:

Note

Don't skim these. They're the most essential part of contributing.

Let's start with expectations. These are important because they set norms for behavior, communication, and conduct in this community. Please read each one carefully, and make sure to do each of them.

• Communicate. The success of a software project depends on individuals communicating their progress, needs, and knowledge frequently and clearly. All communication related to issues should be in GitHub, the corresponding GitHub issue, so any future contributor (and even yourself) can see the history of discussion and dialog. If you need to communicate about something unrelated to an issue (e.g., coordinating with collaborators), a group chat on Discord is best for more temporary collaborations and a channel for more permanent groups. When someone asks you about something, please reply within a few weekdays—ghosting is highly damaging to collaboration and the project. You can set practices to regularly check your GitHub and Discord notifications so you can reply to people trying to reach you.

• Learn. Making software requires learning. Learning counts as progress in this community, even if it doesn't immediately translate into contributions. Find others to learn with and get feedback and help from others who know skills.

• Read documentation. This wiki has documents nearly every aspect of this project; most of the technologies we use have extensive documentation. Read it all carefully; if it doesn't answer your question, use the #chat channel on Discord to get help.

• Seek help. Asking for help can be scary: it's a signal that you don't know something, and we understand why you might fear being judged for not knowing something. But with software design and development, not knowing something is normal. Start with documentation, then contributors, and especially maintainers, who know more about the project's implementation than others. If it's about a particular issue on GitHub, tag someone in a comment. If it's about something more general, post it on the appropriate channel in Discord. Default to posting publicly because it's almost certain that someone else has the same question. Only use private questions if it is a confidential topic.

• Protect each other. If you're ill, don't come to meetups. If you see bullying of any kind, stop it. If you see someone attacking another student for their identity, call them in and hold them accountable. This has to be a place where everyone is safe, physically and emotionally.

• Keep everything in GitHub (eventually). You're welcome to use other platforms and tools to do your work, but a GitHub issue should represent all work, and all work should eventually end up in GitHub. Create topics to describe your work, assign yourself to issues, and keep your work embedded using GitHub markdown. There should be no external links to content hosted elsewhere; such links break or become inaccessible, making them useless for future contributors.

• Engage. If you're a student at UW, I expect you to be an engaged part of the community. For those who signed up for credit at UW, we expect attendance at the weekly meetup. Join the UW CREATE and DUB mailing lists, attend our seminars and learn more about accessible computing and HCI. Maybe even fall in love with HCI, computing education, and accessibility research!

• Be precise. Don't take shortcuts or ignore design details; work on them or detail the work to be done later. This is important in any engineering and design work, which demands detail in both building and verification. Still, it also matters greatly for our project goals of decolonization, justice, and equity in programming. Details of the mundane are where many injustices often live because they are easiest to ignore.

• Be consistent. This project has a large number of established architectural and interaction design patterns. Most were consciously chosen to support some design goal; some may have been accidents or poorly thought through. Before you begin design or engineering work, study how things have been done and do them like that. If you want to deviate from things' work, pause, talk to others, and ensure that deviation is a good idea. Don't deviate just because it's the easier path.

• Be critical. This project only improves if you report things that aren't working. That includes things you think are design flaws, usability and accessibility problems, defects, complexities, and even this documentation. It's up to all of us to notice when something could be better. Report all issues here in GitHub.