Through Wikimedia Foundation, the Wiki Education Dashboard project often participates in Outreachy and Google Summer of Code (GSoC), as well as Google Code-In (GCI). We also welcome contributions from other new developers who want to help the Wikimedia community and build their software skills in the context of a professional codebase.
- Request a Slack invite, join the chat, and say hi.
- Set up a development environment. If you get stuck, first check the troubleshooting doc, and then ask Slack.
- Read the CONTRIBUTING file and this file, and browse the other docs.
- Open a PR to improve the setup instructions if you faced any difficulties that weren't covered in the docs.
- Find one issue you'd like to start with. Post a comment on GitHub, and/or let us know on Slack that you're working on it. (If someone else said they are working on it very recently, you should find a different issue. If someone said they were working on it more than a few months ago, it's likely not being worked on anymore.)
If you're thinking of applying to Outreachy and/or GSoC, please read this section!
Outreachy and GSoC are paid, competitive programs where successful applicants join the Wiki Education Program team full time for several months to work on a specific project with support from mentors. We typically see a large number of folks show up in the weeks before the application deadline, ready to try their hand at fixing issues and deciding whether to apply for this project. We try to handle this process in a way that is as respectful as possible of the time, energy, and goals of everyone involved.
The application period has two important roles: it lets us get to know you, the applicant; and it lets you get to know the project, its codebase, its development workflow, and its role in the Wikimedia ecosystem. If you're interested in applying, the first things you should do are to set up a development environment — and to join our Slack and say hi. After that, you should find a first issue to work on. (Please start with one, and wait until you've completed that to claim other issues.)
For your early contributions, it may take more time to explain and review your work than it would take us to do the work ourselves. This is okay; these are learning opportunities for you, and that balance will shift over time if you continue contributing.
Once you've finished a few issues, start thinking about the project idea for your application. Read whatever you can find that relates to it — both the technology involved and the Wikimedia community processes and programs. Ask questions and talk with us about what you've learned. Then create an issue on Phabricator for your proposal, and begin writing up your understanding of the project, along with the issues you've completed. You can flesh this out gradually, as you continue working on issues. Ask for feedback and keep improving it, and then add a project timeline that reflects your understanding of the technical and other tasks involved, in broad strokes.
Advice for Outreachy & GSoC hopefuls:
- The earlier you start contributing, the better chance you'll have. Learning the project takes time.
- Please ask questions and seek help when you're stuck!
- Review the pull request process before opening your first PR.
- If you're trying to judge how to spend your time — whether to put in more work on this project, or start making contributions somewhere else to improve your chances — feel free to talk with us about it. We don't make any decisions before the final applications are complete, but we can give you a frank assessment of your chances.
A competitive applicant will have completed a series of code contributions, starting from small and simple things, and moving to more complex and varied issues. The volume of your contributions is not the important part; we're not trying to pit applicants against each other to extract as much free work as possible, we're trying to understand what it would be like to work with you on a big project.
We're looking for evidence of your technical and communication skills. Can you work effectively with JavaScript, Ruby, and CSS? Do you write efficient and understandable code? Do you ask good questions? Do you communicate clearly in your commit messages and your GitHub interactions? Do you follow the conventions of the codebase? We're also looking for evidence that you're becoming comfortable with the codebase. Do your later contributions show that you understand how different parts of the system work together, and how changes will affect users? Depending on the specific project, do you have additional skills that will be needed, such as visual design or user research?
A competitive applicant will also put together a project plan that demonstrates a clear understanding of both the project concept — what is it that the project aims to accomplish and why — and how to translate that project into technical tasks in the context of the Wiki Education Dashboard codebase. The project idea that we provide as a starting point may be very vague, and part of the process of preparing the application is to get as much of an understanding of that project idea as you can, and turn that understanding into a plan. (User research to learn more about exactly what Dashboard users need out of a particular project or feature, is often a good thing to incorporate into your project timeline; if the details of exactly what to build aren't clear from the project idea, that probably means there are many open questions that we don't yet have answers to.)
We also welcome applicants to come up with their own project ideas — which is an especially good way to show your understanding of the big picture of the Dashboard and its role in the Wikimedia ecosystem.
Some things that make an applicant look good:
- Clean code and clear Git histories
- Well-isolated individual Git commits with detailed comments that explain the context and the thought process behind the code
- Working on one issue at a time
- PRs that have already been tested locally, and include screenshots or videos to compare before/after
- Helping other contributors
- Noticing bugs and/or code quality problems and opening good issues for them
Here are some examples of strong applications that we accepted:
- https://phabricator.wikimedia.org/T177507
- https://phabricator.wikimedia.org/T189873
- https://phabricator.wikimedia.org/T189991
- https://phabricator.wikimedia.org/T147727
During the internship period, we try to establish a cadence of frequent communication and steady, small contributions. We usually have a short video check-in meeting once or twice per week — including all active interns and at least one mentor — for you to share what you've done since the last check-in, what you're working on now, and anything you're stuck on. Ideally, you'll be pushing up new code at least daily, and your contributions will be merged and deployed as often as possible once they are ready.
Your project plan will guide you through the main goals of the project, but it's often just a rough guess and may evolve considerably. We'll do our best to provide a good learning experience, give you the chance to make a meaningful contribution, and ensure a supportive environment. You'll do your best to accomplish the project goals (and hopefully surpass them) and build your skills.
After your internship is over, we hope you'll stick around and keep contributing as a volunteer (but of course, that's completely up to you). Some of our interns have: returned for a second internship; returned as mentors; and become involved in other aspects of the Wikimedia technical and research ecosystem. You'll get in touch if we can help with advice or letters of recommendation. We'll brag about your future accomplishments.