Currently, applications for collaborators are open ! Join our mailing list to keep up to date with Journey’s milestones.
What to expect from Journey as an organization
Journey faciliates the connection between highly highly skilled developers from underrepresented nations and organizations that are dedicated to maintaining open and inclusive standards.
We expect organizations to offer a place for growth of collaborators and we ask them to see this as a fellowship program rather than an colaboration period or contractor work.
Journey is not an employment agency and does not establish formal employment relationships. Organizations will engage collaborators on a contract basis, similar to Outreachy’s contract system. All payment arrangements should be made directly between the organization and the contractor. Journey will offer assistance to collaborators in establishing their own freelance entities if they do not already have one.
For an organization the process looks like the following:
- Initial conversation with Journey members so any doubts are explained
- Organizations should submit a project and set-up their contribution tasks
- Possible collaborators get in touch with mentors and start working in tasks
- After a month, mentors should go through contributor’s projects and choose the ones they want to work with for the rest of the three months period
Developing a project
Jouney mentors define a project for collaborators to work on during the three month period.
What makes a good project? (Credit to QEMU coordinator Stefan Hajnoczi’s talk at KVM Forum for these tips.) A project that is suitable for collaborators to work on is:
- Well-defined - The project has a well defined scope.
- Self-contained - Has few dependencies on uncompleted work. Does not require interacting with multiple open source communities who are not on-board with interacting with a collaborator.
- Uncontroversial - The community should agree that this project idea is acceptable (and ideally useful!) to be included in the community project.
- Incremental - The project should produce several deliverables during the colaboration period, rather than having only one large deliverable. This allows the project goals to be modified if the intern completes task faster or slower than expected. If the project does have one large deliverable, it’s recommended that the intern complete a design document. This allows the intern to hand off unfinished work to the next intern, or the community.
Only Journey mentors should propose projects. Journey does not accept projects proposed by a collaborator. Journey mentors are allowed to tailor a project to the applicant after selecting them as an intern.
Journey does not allow mentors to submit a project with a particular applicant in mind. All project mentors should be willing to work with any applicant during the contribution phase. This allows all Journey applicants a fair chance at obtaining an colaboration period based on their skills, rather than existing connections to a free software community.
Contribution period tasks
Journey mentors need to define a set of newcomer-friendly tasks (called “contribution period tasks”). Applicants will work on these tasks during the contribution period. The contribution period tasks for applicants are different than the work the intern will complete during the colaboration period.
The goal of contribution period tasks is for mentors to determine whether the applicant has the skills to be successful during the colaboration period. Working on contribution period tasks also help applicants get familiar with the mentor and the open source / open science community norms.
In order to be accepted as an collaborator, applicants need to complete at least one contribution period task. Therefore, it is very important for mentors to prepare a well-detailed list of contribution period tasks
Listing contribution period tasks
There are many places to list contribution period tasks for Journey applicants to work on.
- open source / open science community issue tracker
- welcome page on the open source / open science community website or wiki
- shared online document
- kanban board (useful to assign contribution period tasks and sort tasks into categories)
Most open source / open science communities try to tag issues that are designed for newcomers. A ’tag’ is a label that links to issues under the same topic. Tagging a group of issues specifically for Journey applicants (or all newcomers) ensures they won’t try working on an issue that is too complex or not well defined.
Here are some recommended tags for labeling contribution period tasks for Journey applicants:
- “newcomer friendly”
- “good first task”, “good first issue”, or “good first bug”
- “Journey”
It is best to define who the issue is aimed at (“newcomer” or someone working on their “first issue”). Avoid using the word “newbie” because it is often used in a negative manner (e.g. “n00b”). Additionally, the word “newbie” can be offensive for people who are not new to tech, but are new to open source. Using the word “newcomer” is more appropriate because it means someone is new to your project.
If you want to assign task labels, use terms like “less complex” and “more complex”. Everyone starts as a beginner on a project. Sometimes that means struggling for hours, days, or even weeks to solve your first issue. It can be disheartening to struggle for so long on an issue marked “easy”, “easy win”, “quick win”, or “bite sized”.
Example contribution period tasks
Contribution period tasks should test the skills the applicants will use during their colaboration period. Therefore, contribution period tasks for applicants will vary greatly from project to project. Here are some examples, depending on the type of colaboration period project:
- Testing: write a test case that reproduces a bug
- Programming: update one function to use a newer API, or refactor some code
- Documentation: identify a missing section of documentation and outline what should be in that section
- Translation: translate one paragraph of documentation from English to your native language
- Design: design an example illustration for the open source / open science community website
- Accessibility: identify one accessibility bug using Web Content Accessibility Guidelines (WCAG) 2.1 standard levels
- User research: introduce the open source software to a friend, and record their impressions and challenges while trying to complete a task
A contribution period task does not have result in code being merged into the project. For example, a user experience contribution period task could ask the applicant to use the open source software and write a short report on an aspect of the user interface that was confusing. That report could be uploaded to a file sharing service and shared with Journey mentors.
Small contribution period tasks
A small contribution period task is designed to introduce the applicant to your project. The goal is not the task itself, but to encourage the applicant to familiarize themself with the community norms, development processes, and asking questions.
For example, a good small contribution period task might be to install a local development environment, change some part of the user interface, and then add a screenshot of the changes to an open issue for Journey applicants. This will see whether the applicant can debug getting their development environment set up. They will likely get stuck, and need to reach out to ask for help. Mentors can see how the applicant asks questions, and responds to feedback. Contribution period tasks should be defined so that mentors can see how the applicant asks for help and their communication style.
Smaller contribution period tasks will often need a very thorough description. They will often have several paragraphs to explain why the task needs to be done, how to complete the task, and what resources the applicant should read.
Some applicants may “claim” a smaller task and then not complete it. You may want to limit the number of tasks one applicant can claim.
It’s good to have a lot of smaller tasks. You can also have smaller starter tasks that can be completed by multiple applicants (like a user experience survey or a graphic design proposal).
Medium contribution period tasks
Once an applicant has completed a few smaller tasks, they’ll want to have a medium-sized task. This task is a chance for them to prove they have the skills needed for your project.
A medium-sized task should test the skills that are necessary for an intern to be successful on this colaboration period project. This is because Journey does not allow mentors to select an intern on the basis of educational background. Mentors should consider all applicants, regardless of whether they have a university degree, they have completed a coding school, or they are completely self-taught. You will be selecting an intern based on the quality of their contribution period tasks alone. In order to ensure you select an applicant who can successfully complete the colaboration period, your tasks will need to test any skills you consider relevant to the colaboration period project.
Evaluating contribution period tasks
A strong applicant submits thoughtful contribution period tasks, and edits their work when feedback is given.
We encourage mentors to value communication first. Journey’s goal is to help collaborators learn and grow their open source skills. Growth cannot happen without communication and collaboration. We encourage mentors to value applicants who communicate during the contribution period.
We encourage mentors to value the quality of the applicant’s contribution period tasks, over the number of contribution period tasks that an applicant completes. It is risky to accept an applicant who submits many small contributions with little substance. These small contributions may not be enough to judge whether the applicant will be successful during the colaboration period.
It is also risky to accept an applicant who submits a large contribution at the last minute. This does not allow mentors enough time to judge the applicant’s skills. It also does not allow the applicant time to respond to feedback.
Avoiding mentor burnout during the contribution period
Set office hours
Journey is open to Brazilians. Unfortunately, that means you can get questions and contributions at any time of the day (or night!). It’s important that mentors protect their personal time to unwind and do self-care. In your project description, mention what times you are best available to answer questions. Try to set aside at least one hour per week day to answer questions.
The downside to this is that some applicants will not be able to get their questions answered during their normal working hours. You may find that some applicants even shift their work or sleep schedule to be available during your office hours. This can be added emotional labor for parents with children, or people who are currently working and trying to switch careers into tech.
On the other hand, you will need to set up regular check-in times with your intern. So being up front about when you are available to help will narrow the applicants down to ones that have a window to work with you. Some mentors have been able to make working with an applicant with a 12 hour timezone difference, and some mentors have struggled. You know yourself and your work habits. Make the best call for you, while still being open to working with Journey collaborators in many different timezones and countries.
Find unofficial volunteers
You can ask experienced contributors to your community to be “unofficial” volunteers. These volunteers could be past other collaborators within your community, or other community members. They don’t have to be official mentors, but they can help answer questions.
Unofficial volunteers can help people set up contribution environment and tools. They can help with common contribution tools, like git or other revision control software. Unofficial volunteers can also provide experience with community norms. Community norms could be something technical like what coding style to use. Community norms can also involve communication style, like how to effectively ask for help.
Unofficial volunteers can also serve as a connector to other community members or external open source contributors. They can help introduce applicants to people who works on specific parts of the project, or external open source contributors who are experts with a particular tool (like git).
Limit simple contributions
A simpler contribution could be something like fixing a spelling error in the documentation. A more complex contribution could be something like refactoring code, writing a documentation section, or doing research. Applicants have a tendency to make a lot of simpler contributions. They may feel confident making smaller changes, but less confident tackling medium complexity tasks.
You can limit the number of simpler contributions that each applicant can complete. Keep track of how many simple contributions applicants have claimed to work on. If an applicant has worked on or wants to claim a third or fourth simple contribution, encourage them to pick up a medium sized or more complex task.
Some communities have queues of simple, medium complexity, and highly complex tasks. Once an applicant completes 1-3 simple tasks, you can point them to the medium complexity task queue.
Withhold some contribution period tasks
You may want to save some smaller tasks for the last few weeks of the application period. Save those tasks and don’t put them in your task tracker until the last two weeks. This allows applicants who come in later in the application period to have a chance at completing a smaller starter task.
It’s important that mentors remain responsive to applicants who are completing tasks during this period. Mentors can be honest with the applicant if they already have an intern selection in mind (and that applicant has completed a final application). However, mentors shouldn’t ignore requests for help or requests for a starter task, as this leads to a bad experience for the applicants.
Have applicants complete similar tasks
You can ask all applicants complete the same tasks. This task could be something like taking a screen shot showing which shows they got the contribution environment working and made a change to your project. They could also work on a document, like a review of the usability of your project or a design document for a feature they would be working on during the project.
The upside of having applicants work on the same tasks is they can all commenting on the same GitHub issue, which allows you to keep the conversation in one place.
The downside of having applicants work on the same tasks is that some people might be intimidated by the other applicants’ work. It may also encourage applicants to copy other applicants’ work. If you ask applicants to complete the same task, be sure to have some other individualized tasks that test the applicants’ skills.
Encourage collaboration vs competition
Open source is about collaborating with others in a community. It’s important to encourage that collaborative mindset in your applicants. Otherwise they may be focused on a more competitive mindset, focusing only on how they can improve their changes of being accepted as an intern.
You can encourage applicants to help each other. Encourage them to engage with applicants or newcomers to the community who ask questions. Keep a shared document of common questions and answers that any applicant can add to. Once an applicant has completed a medium complexity task, encourage them to start reviewing other applicants’ contributions.
The upside of encouraging applicants to collaborate is you may lessen the workload for mentors.
There are several downsides, however. One is that applicants with impostor syndrome may feel shy about sharing answers to questions, even if they know the correct answer. Second, some collaborators may live in countries where they are taught to defer to teachers or people in authority. Answering a question that is directed at experienced developers may seem taboo or breaking a cultural norm.
Additionally, gender bias may come into play when you’re looking for collaborators that collaborate with each other. Women and non-binary people who were assigned female at birth (AFAB) are often socially conditioned to not speak up unless they are extremely confident in their answer. You may find that men and non-binary people who were raised with masculine cultural norms are more likely to speak up and answer questions. Gender bias and gendered social norms should be considered when making intern selections.
Close your project to new applicants
Journey applicants might wait until the last week or two of the contribution period to start making contributions. Sometimes this results in them finding a project that has few applicants. Sometimes this means they try to make contributions to a project where many people have already made a contribution. It’s important to encourage applicants who are seeking a project to contribute to projects with few applicants.
If you’re overwhelmed with applicants who are already finished with contributions, you can close your project to new applicants. This simply moves your project listing on the projects page to a section called “Closed to new applicants”. Current applicants will still be able to record contributions and submit a final application.
You can close your project to new applicants, just get in touch with Journey and we will close it to new applicants.
It’s a difficult decision as to when to close your project to new applicants. You may have many applicants who have completed a simple task, but you’re not sure if any of them have the skills to succeed in the colaboration period yet. You may want to wait to close your project to new applicants until at least one or two applicants have completed a medium-complexity task.
Don’t wait too long to close your project to new applicants! Waiting too long means that applicants will apply to a project they have no chance of being accepted for.