How to propose the best project for Outreachy?
The project submission deadline for Outreachy is rapidly approaching: prospective mentors only have until March 4 to come up with projects for the summer cohort (May to August 2022). For those who don't know:
Outreachy (previously the Free and Open Source Software Outreach Program for Women) is a program that organizes three-month paid internships with free and open-source software projects for people who are typically underrepresented in those projects.
As a past mentor and one of the current coordinators of the OpenStack community in Outreachy, I would like to give a few tips for the mentors on how to get (and give!) the most of the program by picking a right project.
It's more about giving
The program is, first and foremost, an effort to bring more justice to the world, as well as make our industry healthier and more sustainable long-term. Depending on how you look at it, participating may not bring you substantial immediate benefits. You should treat it as an opportunity to help, rather than to solve any pressing problems for your project.
That's not to say that your project won't reap any short-term benefits. In addition to hopefully getting something done, working with interns allows gaining a fresh perspective on your project, especially when it comes to documentation, development environment and other aspects crucial for onboarding. It's also an opportunity for you to learn and grow personally.
Be honest with timing
Each round lasts only 3 months. The first month will very likely be spent onboarding your intern, making them familiar with all the processes and practices. The remaining two months is not much, when you think about it. If the task involves a design work (see also community agreement first), you'll have no more than one month left for the actual implementation.
Don't forget about holidays and other planned and unplanned absences. For example, the winter round is interrupted by Christmas in countries that celebrate it. Even worse, your holidays and holidays of your intern will not necessarily match. Then there are summer vacations, exams, sudden sicknesses, and so on. Realistically, getting 2 months of actual work is the best, not the average case.
And while extending a program a few weeks is always a possibility, you must not plan around it! This option is to make up for a prolonged sickness or anything else your intern may struggle with, not for insufficient planning on your side.
In other words: the work may not be finished by the end of the round, and it is not an exceptional situation (nor a reason to delay the intern's payment).
Stretching is healthy
One strategy to cope with the issue described in be honest with timing is to carefully split your task into roughly three parts:
The core of the project. Which part of it will bring some displayable value, while not taking no more than one month of average effort?
For example, if you're working on new API, can the frontend work (i.e. the actual API endpoint) be implemented without having a working backend? Can you skip all fields and parameters except for the most critical ones? Does it make sense to not implement updating a resource, only creating, reading and deleting?
MVP (minimum viable product). This is the complete work without any extras, just the bare minimum. MVP means something that can already be used, although possibly with severe limitations. This phase is where you expect some basic documentation and automated testing beyond just unit tests.
Using the API example, having the endpoints and at least one working backend may be the MVP. It may still feature only the most critical fields and parameters.
Stretch goals. Everything else ends up in this category: optional features, additional testing, detailed documentation.
The core is what must be done, the MVP is what should be done and stretch goals are nice to get done.
Stay in shallow waters
What can be more exciting than rework your database code to use a different backend or an ORM library?
Well, many things.
Just as small children explore the world by touching (and even tasting) things around them, so newcomers learn technologies and projects by interacting with them. Concentrate on aspects that can be tried and tested by interns, rather than making them work on something, that may only become visible after months of subsequent work. Remember: positive motivation is crucially important, people need to see the results of their effort.
Be careful with technologies that are not accessible for interns. Examples include significant computing power (roughly speaking, more than their laptop can provide), paid software, specific hardware or operating systems. If anything like that is unavoidable, it's on you to provide your interns with access during the whole internship. Worst case, their computer won't be powerful enough even for 1 virtual machine - think about your options in this case.
Avoid busy work
In a similar vein, do not assign busy work to your interns (also applies to your junior colleagues outside of Outreachy). Refactoring existing or filling in missing unit tests, fixing grammar errors in documentation, clearing the backlog of minor issues are the tasks we all hate to do. So do interns. Technical debt is a team responsibility, not something to put on the shoulders of those with a less senior title.
On top of that, the participants will want to boast their achievements during the program on their CV, it's partly your job to make them stand out.
Community agreement first
Imagine: you get your project approved, your intern is selected and ready to work, and all of a sudden the community rejects your idea altogether. While it may be a useful experience for your intern to try advocating for a new feature or another change, the risk of rejection is often too high. Completely changing the project will cause a lot of frustration and lost time. Unless you have the power to speak for the whole community, seek agreement first.
A prerequisite for a consensus is to specify your project in enough details for the community to reasonably discuss. In case of a feature work, it may mean writing an RFE with a solid justification and an outline of the implementation. As a bonus, you'll be able to reuse the text in your proposal.
Speaking of community, make sure to gain support of at least a couple of people with commit/approval rights, even if one of them is you. Few things are more frustrating for an intern than finishing a work item just to let it sit for weeks without attention. Be honest with timing - review is also a part of it.
Are you ready?
Once you've worked through all the potential issues I've mentioned, try to have a rehearsal of the early weeks of the internship, even if only in your head. The questions to ask yourself include:
Is your documentation clear enough for newcomers?
Do you even have a contributor guide for newcomers?
Hint: if you assume that the interns are familiar with Git and a Unix-style shell, mention it in your requirements! But if you assume familiarity with Windows, mention it as well: the author of this post hasn't seen this operating system in years.
Does your contributor guide explains in clear terms how to keep in touch with the community? Is this process friendly for beginners?
Hint: you shouldn't be the only point of contact for the intern - learning to interact with a community is very useful on its own.
Hint: you may need to explain what IRC is, or even provide a link to a web client.
Is there a straightforward procedure to set up a working environment?
Rest assured: if you present an intern with several dozens of non-trivial steps, they will make one tiny mistake, and you will spend hours trying to find it. Bash and Ansible are your friends.
Do you have a complete list of documents to read during their first week? Are you sure it's possible to read and more or less understand in one week?
What is the starting point?
Hint: see stretching is healthy, the core is where your intern should begin.
Write everything down and you're ready to invite interns to your project!