goodfirstissue — a gateway into y/our community
Engagement and onboarding of new contributors can be a struggle, especially in self organised spaces where there’s heavy reliance on volunteering hours and no top down management structure.
For teams and organisations that are looking to expand it is important to communicate explicitly and clearly how new contributors can:
- navigate the system — think responsive ecosystem mapping, what does y/our organisation look like?
- easily access support
- find a series of goodfirstissues to get involved
What’s a goodfirstissue?
goodfirstissue is a tag used by opensource projects on github and gitlab to highlight easy entry tasks for new contributors. It is a valuable tool that allows new contributors to dip their feet in on their terms, picking and choosing where and how to get involved and providing value to the community as a whole.
There are some elements that need to be clear:
- a detailed description of what needs to be done
- what skills are needed to complete the task
- a seamless process by which the task can be submitted and reviewed if necessary
- there must be an element of trust
- a way to easily reverse changes if need be
- a culture of feedback and support
Freedom to make mistakes allows for contributors to be confident that whatever they do will not do any permanent damage, this allows them to do the best they can without fear.
Having a system by which contributors are given some trust at outset and offering opportunities to build up that trust using clear and explicit behaviors allows for better integration process,
I am in teams where the active contributors are overstretched. In the best case scenario the active contributors are either invited in by a contact which becomes a support anchor and in the worse case scenario a new contributor arrives into the working space (slack in my example) unaccompanied and is likely to become overwhelmed with the sheer volume of channels and messages. Since everyone who posts seems to know what they are doing where it seems at face value that things are generally under control they see little to no space for their engagement. However, even a short chat with other active contributors reveals that the work load is way more than what the current active contributors have capacity for but there are no explicit invitations to participate other than the general invite. When there is an invitation to participate then there is often no time to follow up which results in people becoming alienated and quickly leaving the space.
How can team culture be changed in order for mentoring to become an established practice?
One of David Holmgren’s permaculture principles is “Integrate rather than segregate”, each role, team and environment has a variety of tasks that can be transformed into bite-sized goodfirstissues, get those new contributors integrated into the team as soon as possible.
For teams that are overstretched already it could be a struggle to make time to create goodfirstissues, mentor & accompany new contributors but what if mentoring was part of the culture instead of an afterthought? What if it was an integral part of y/our role — how would you show up?
Synchronous and Asynchronous work and communication patterns
Work activities can happen synchronously, when two or more active contributors meetup to work and talk through work items. A variation to this is co-working time where contributors agree to be online at the same time available if needed for synchronous work if needed but mostly doing asynchronous work. This pattern allows people to focus on their work, ask other contributors questions which can be answered without too much delay.
Asynchronous work happens at an independent rate and time by the contributors and leaving messages to other contributors to answer in their own time. This pattern is useful for teams with clearly defined tasks, time zones at different ends of the scale and with team agreements as so what are acceptable time for a response.
A mixture of both synchronous and asynchronous is normally the best approach for building trust and rapport between contributors. Getting to know the time capacity for new contributors will help establish which patterns would work best for them.
What are some examples of goodfirstissues?
A communications coordinator who puts together a monthly newsletter could create goodfirstissues such as:
- collect latest news from the different teams and projects (completely asynchronous possible)
- quality check the newsletter (spelling, grammar, links check — again completely asynchronous possible)
- make illustrations to design some cool pics / icons for different updates
A project manager who keeps track of multiple projects and sets up processes could create goodfirstissues such as:
- review a specific process/es to sense check and make sure external parties truly understand what is going on by turn complex processes into simple statements that can be communicated to an external audience
An engagement designer who takes care of all things engagement at different levels and on different platforms could set up goodfirstissues:
- submit feedback about new contributors own experience of onboarding that can be used to improve the system (could be asynchronous)
We can’t / won’t take on more meetings… are mentorship and goodfirstissues possible without an added time investment?
If additional meetings are a challenge then integrate them into existing meetings, keep meetings brief, focused and if it helps you can use a framework such as used by parabol for example:
- check-in — for people unfamiliar to you it may be useful to start with the basics: name, location, what brings you here
- focus point — why are we here / agenda setting
- go through the agenda points — be mindful of the time / set tasks or action points there and then if some come up
I would also add a checkout. Time is precious, connection with team mates that truly respect each other’s time and sensitivity around time helps to build trust. When you do have more time check-ins and check-outs can be longer or shorter as the team flexes into the expanding and contracting time capacity.
If the discussion has come to a close before the allocated time end there’s always the option to end the meeting and see the leftover time as an efficiency award without the need to drag the meeting on longer than it needs to be.
If the work is purely asynchronous then it is important to state that in the description of the task so contributors know that meetings are not on the table.
What tools would be useful for goodfirstissues?
There are a myriad of tools out there that y/our community may be using remember that:
you want goodfirstissues to be visible to new contributors — think here how open / visible is your current task management tool? do you hide your tasks behind a login wall then how do you want people to see and pick up the tasks?
you want goodfirstissues to be up to date and accurate with a direct link to the person who will review the work
Start with an assessment of current tools in use, do they meet these requirements?
The open approach
The added benefit of using GitHub and GitLab is that contributors search the site using #goodfirstissue & #helpwanted to find worthwhile projects to get involved in and these are not just for coding tasks, any contribution to open source projects is welcome and encouraged. You can test this out by using additional tags for example translation, design etc.
Good First Issues
Good First Issues empowers first-time contributors of open-source software. This website is primarily targeted at…
During October masses of contributors participate in hacktoberfest. Imagine what that could do for your project.
Open source is changing the world - one contribution at a time.
Why would contributors turn up to help?
Open source contributions are contributions into the commons, it is a chance for people to practice and grow their skills to produce software and other commons assets for the use of everyone to enjoy and improve on. Open source is a movement.
The not so open option
If you do not want to have your issues in full view of the world and you do not want your project to be open source you will need to make some of it open and visible in order for contributor to see those tickets and engage with them.
You can use OpenProject, Taiga or Parabol (the problem with Parabol is that all tasks have to be assigned to someone so not ideal) if you decide to have an open invite for contributors— after signup to your workspace whichever that may be — slack, Mattermost etc.
Of all the communities I have been involved in it is the closed and non transparent ones that struggle the most to keep engagement levels going. This is compounded with low reward schemes. In addition closed environments are hard to sell without open communication and enough transparency to keep new contributors interested an engaged.
Ask some hard questions here:
Why would anyone want to contribute their energy and time in this space? What tangible and intangible benefits are there? How obvious is it to an external party what the benefits are? What are you offering that they cannot do themselves or find elsewhere? Why should existing contributors incorporate mentorship into their participation?
Without answers to these questions it will be hard for y/our organisation to find the motivation to actually do this work.
If you are offering monetary compensation then that’s a big motivator but if you want people to stick around after that task is done you will need to do better than a one-off payment.
If you want people to create their own monetary reward opportunities / freelance then how they can do that should be crystal clear at outset. Link those goodfirstissues within a roadmap of what could come next.