contribute

Welcome! It would be best if you were here to make programming accessible to everyone, regardless of language or ability. We're excited to have your help!

Project goals

To start, review our welcome slides! They provide crucial context for the motivation of the project. We'll present these at the first meeting of our quarterly meetups, but if you aren't attending those, missed the first meeting, or want to see what we'll present before the meeting, start here:

• Review our welcome slides

Note

Be sure to complete these slides so that you understand the project's goals.

Commit to our Code of Conduct

Before getting started, there are several key principles we expect you to follow when contributing to the project:

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 greatly 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 an immense commitment to learning new things. Learning is important, takes time, and 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 carefully. There is extensive and growing documentation about every aspect of this project. Not all of it is good, and sometimes it might be wrong, but it does exist. Please read it carefully first; if it doesn't answer your question, you can go to the person most likely to have the answer. When you encounter an error, you can just read the error message in detail and the documentation about the error message. Learn what it means, search for the error message online (without project-specific details), and try to learn its possible causes. Ask for help if you can't find the answer in the documentation.

• 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. That is the constant state of everyone. It is a work that requires constant learning. So, I would like you to look for help, first from documentation and then from contributors to the project. That includes me: I know more about this project than anyone, so if you don't come to me for help, you're not doing your job. 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. You can only use private questions if it is a confidential topic.

• ** Protect each other **. If you're ill, don't come to our gatherings in person. 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 for being kind. This has to be a place where everyone is safe, physically and emotionally. Good work can only happen if we are. We want everyone who engages here to leave feeling smarter, more capable, more welcome, and more valued.

• 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!

• Attend to details. 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.

Learning together

Contributing to this project will require lots of learning. Don't be surprised if you need to pause and spend some time learning a particular aspect of a tool, programming language, or framework. We view learning as a regular part of contributing, and we hope you will, too! There's no shame in taking responsibility for some work and learning as part of it.

Here are some of the things you might need to learn:

• Git and GitHub functionality. (Need to learn? See the GitHub tutorial).
• VS Code functionality. (Need to learn? See the VS Code tutorial.
• Details of JavaScript, HTML, and CSS syntax and semantics. (Need to learn? See the Modern JavaScript tutorial).
• TypeScript and the more general concept of static typing. (Need to learn? See the TypeScript tutorial).
• Svelte and SvelteKit concepts and tools. (Need to learn? See the Svelte tutorial).
• Firebase concepts and functionality (authentication and Firestore in particular). (I need to learn? See Firebase fundamentals).

If you know some of these will already, you'll be able to contribute more, but all contributions are valuable, however small and slow. We're just glad you're here.

It is entirely appropriate if most of your time is spent learning. Engage the community in this learning, learn together, and teach each other; self-organize study groups, share resources, ask questions on Discord and contribute answers if you have them. That requires some vulnerability, but the more vulnerable and supportive we are with each other, the faster we will all learn.

Suppose you are participating in the Wordplaypen meetups in Seattle. You can self-organize group tutorials. Amy and other contributors can explain concepts and give group demos, helping accelerate learning. We also encourage you to organize your group tutorials.

Join GitHub

GitHub is where we discuss issues. All the new problems, design proposals, and discussions about specific topics should go there, so there's a record of decisions for everyone to review, enabling newcomers to have all the context necessary to contribute to the problem.

It's also where we manage the project. See our project's Kanban board to check what issues are in our backlog, being actively worked on, or finished.

• If you don't have a GitHub account, create one, and make a note of your username.

Important

GitHub Be responsive to GitHub comments, especially if someone tags you. You must respond to requests within at least a few days so that others are allowed and waiting for your information. Do not ghost.

Join Discord

Discord is where we help each other and coordinate our work. Post questions, resources, and event information in relevant channels in #contributors, or more specific channels relevant to your topic.

We encourage you to create dedicated channels for issues (named [issue]-description, in the "Issues" category) to coordinate and collaborate as long as you ensure that critical insights and decisions are captured on GitHub. Could you archive the channel once the issue is closed?

• Join the Wordplay Discord and make sure you're on the #contributors channel.
• In Discord, update your server nickname in "Edit Server Profile" to "Your Name (GitHub-username)" (e.g., Amy's is "Amy J. Ko (amyjko) so people can find you on each platform.

Important

Don't use other platforms (e.g., some other Discord server, Slack, Teams, group chats, etc.) to communicate. Discord is where our community is; if you talk elsewhere, it fragments it. If you have ideas for how to make Discord better support your work, could you suggest ideas in #suggestions?

Learn Wordplay basics

Before you can contribute, there are several things you need to install and configure to run Wordplay on your device:

• Complete the Wordplay tutorial to learn the programming language and the interface. This is an essential step for any contribution, so you know what you're enhancing, fixing, localizing, etc.
• Create an account, explore gallery examples, and make a few Wordplay programs. Get used to what's possible to create with it.

It's okay if you don't feel like you've mastered the language after the tutorial. The important part is that you have a sense of the scope of content, functionality, and possibilities, so you have context for your work.

Choose a role

There are many ways to contribute to the project:

• Design
• Develop
• Verify
• Localize
• Curate
• Mentor

Pick one or more of these, carefully read through the entire document, and ask questions about the role in the appropriate channel in Discord. If it sounds like something you want to do or learn to do, then:

• Request Discord roles. Go to the #choose-roles channel on Discord and indicate the role(s) you've chosen so everyone on Discord knows your role.
• Add your GitHub username to your server name in Discord. This helps everyone associate you on Discord with your username here on GitHub.
• Read the guidelines for your role(s) the corresponding documents above and get started!