Skip to content

contribute

Amy J. Ko edited this page Sep 24, 2024 · 48 revisions

Welcome! Our vision is 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:

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 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 for being kind. 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.

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). (Need to learn? See Firebase fundamentals).

It is entirely appropriate if most of your time is spent learning. Organize group tutorials, learn with each other.

Join GitHub

GitHub is where we discuss issues. All 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; try to reply within a few weekdays, even if it's just to say that you'll reply with more detail soon. Ghosting breaks collaboration.

Join Discord

Discord is where we help each other and coordinate our work. Post questions, resources, and event information in relevant channels in #chat, 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. Archive the channel once the issue is closed.

  • Join the Wordplay Discord and make sure you're on the #chat 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, suggest ideas in #chat.

Learn Wordplay basics

Before you can contribute, learn the Wordplay programming langauge.

  • 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. Alternatively, read its documentation and review the many examples in its galleries.
  • Create an account and make a few Wordplay programs. Get used to what's possible to create with it. As you do this, report what you find confusing or wrong as issues, so we know to improve them.

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:

Pick one or more of these, carefully read through the entire document, and ask questions about the role in the appropriate channel in Discord. Once you've chosen a 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!
Clone this wiki locally