contribute

Welcome! You must be here to make programming accessible to everyone in the world, 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 meeting, start here:

• Review our welcome slides

Note

Don't skip these slides. It's crucial that everyone understand's 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 important part of contributing.

Let's start with expectations. These are important, because they set norms for your behavior, communication, and conduct in this community. Read each one carefully, and pledge to yourself to do each of them.

• Communicate. The success of a software project depends greatly on individuals communicating their progress, their needs, and their 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 reaches out to you about something, reply, at least within a few weekdays. Ghosting his highly damaging to collaboration and to the project. Set practices to regularly check your GitHub and Discord notifications so that 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 translate immediately into contributions. Find others to learn with, 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. Read it carefully first, and if it doesn't answer your question, then go to the person to is most likely to have the answer. And when you encounter an error, read the error message in detail and read documentation about the error message. Learn what it means, search for the specific 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 documentation.

• Seek help. Asking for help can be scary: its 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 kind of work that requires constant learning. So I expect you to seek help, first from documentation, then from contributors in the project. And that includes me: I know more about this project than anyone, and 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 on the in 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 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 to be kind. This has to be a place where everyone is safe, physically, and emotionally. Good work can't happen if we aren't. 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 all work should be represented by a GitHub issue, and all work should eventually end up in GitHub. Create issues to represent your work, assign yourself to issues, and keep all of your work embedded in issues, 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 signed up for credit at UW, we also expect attendance to 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 for later. This is not only important in any engineering and design work, which demands attention to detail in both building and verification, but it also matters greatly for our projects goals of decolonization, justice, and equity in programming. Details of the mundane are where many are where injustice often lives, because it's easiest to ignore.

• Be consistent. This project as a large number of established architectural and interaction design patterns. Most of them were very consciously chosen to support some design goal; some may have been accidents or not well thought through. Before you begin design or engineering work, study how things have been done, and do them like that. And if you find yourself wanting to deviates from other other things work, pause talk to others, and make sure that the 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, spend some time learning a particular aspect of a tool, programming language, or framework. We view that learning as a normal part of contributing, and 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). (Need to learn? See Firebase fundamentals).

Obviously, 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.

In fact, 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, and 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.

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

Join GitHub

GitHub is where we talk about issues. All new issues, design proposals, and discussion about specific issues 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 issue.

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 note of your username.

Important

GitHub be responsive to GitHub comments, especially if someone tags you. It's crucial that you respond to requests within at least a few days, so that others aren't blocked, waiting for information from you. Do not ghost.

Join Discord

Discord is where we help each other and coordinate our work. Post in relevant channels with questions, resources, and event information.

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 key insights and decisions are captured on GitHub. 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, and if you talk elsewhere, it fragments the community. If you have ideas for how to make the Discord better support your work, suggest ideas in #suggestions.

Learn Wordplay basics

Before you can contribute, there are several things you need to install and configure in order 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 examples in the galleries, 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 documents, 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
• If you did not specify your requested roles in the application above, DM Amy on Discord and request invites to your chosen GitHub role teams, to get required permissions. You can also request invitations on the teams pages directly.
• Read the guidelines for your role(s) the corresponding documents above and get started!