class: title-slide <div align="center" style="padding-top: 2rem;"> <p>Managing Research Software Projects</p> <h1>Newcomers</h1> <p> <img src="../files/codebender.svg" alt="logo" width="20%" /> </p> </div> --- ## The Problem of Growth - Both of Jess's projects are now attracting new contributors - But nobody ever files an issue or a pull request - And most people don't stick around - Part of the problem seems to be getting started - "By the time I was set up, I was out of time" - Most of this material taken from [<a href="../bibliography/#Sholler2019">Sholler2019</a>] --- ## What *Is* a "Community"? A community of practice [<a href="../bibliography/#Wenger1999">Wenger1999</a>]: 1. Participants work on or toward a common product or purpose 2. They are mutually engaged 3. They develop shared resources and domain knowledge --- ## Be Welcoming - Not enough to say "anyone can contribute" - Be proactive about fostering positive impression [<a href="../bibliography/#Steinmacher2015">Steinmacher2015</a>] - Welcome messages on social media - Dedicated `newcomers` channel on Slack - Tag issues as `suitable for beginners` - Designated person to contact - Have a [Code of Conduct](../governance/) - Its mere existence sends a strong signal about the kind of community you are - Have and publish an enforcement mechanism [<a href="../bibliography/#Aurora2019">Aurora2019</a>] --- class: sidebar ## Mentoring - Mentoring programs have mixed results - Work well for some people - Seem to turn others off - Provide as an option but don't force it on people --- ## Help People Evaluate Fit - Saves time on both sides - List different types of contributions and skills required - E.g., "Updating user's guide: needs RMarkdown" - Note: "basic Julia skills" doesn't help - Your idea of "basic" can be quite different from mine --- ## Make Governance Explicit - Do-ocracy concentrates power in the hands of those with: - Good connections - Lots of free time - Lots of self-confidence - We'll <a href="../governance/">come back to this…</a> --- ## Document on Demand - Out-of-date documentation leads to wasted time - More demotivating than not having docs at all - Guessing at what people will need is usually not productive - So turn every question into: - A vignette - An FAQ entry - Source code documentation - Archive things in a findable way - Mailing lists are still better than Slack for this - Search should scan all sources at the same time - See [<a href="../bibliography/#Lin2020">Lin2020</a>] for advice --- ## Develop Pathways to Participation Legitimate peripheral participation: > Newcomers become members of a community by participating in simple, > low-risk tasks that further the goals of the community. > Through these peripheral activities, > newcomers become acquainted with the community's tasks, vocabulary, and governance > so that they can ease into the project. --- ## Develop Pathways to Participation - Submit a bug report (versus fixing a bug) - Help with translation and localization - Test-drive a new tutorial - Particularly important for people who have been excluded in the past [<a href="../bibliography/#Ford2016">Ford2016</a>] --- ## Make It Easy to Get Started - Create a `CONTRIBUTING` file - And test it regularly - Its existence reassures newcomers that you care about them - Helps experienced project members too - "Wait, that's changed?" --- ## Use In-Person Interaction Carefully - Newcomers benefit from events that offer: - structured pedagogy *and* - less structured periods devoted to hacks and creative projects [<a href="../bibliography/#Huppenkothen2018">Huppenkothen2018</a>] - Best when combined with larger events to amortize travel costs --- ## Use In-Person Interaction Carefully - Remember that many people: - Are introverted - Have family responsibilities - Find travel physically challenging - Can't afford it - Can't get visas - Don't make them feel left out - Have note-takers for as many activities as possible - Have online discussions afterward --- ## Acknowledge All Contributions - Gratitude and recognition are powerful incentives - "A programmer will do something for a laptop sticker that they would not do for a hundred dollars" - (If they can afford to, that is) - Adopt and publicize guidelines about who is acknowledged where and for what - Do not ignore "invisible" contributions - Code reviews don't show up in Git logs - We're still trying to figure this out… --- ## Follow Up - Check in with people immediately after their first contribution - Congratulate them - Help them find the next thing to work on - Also check in with people who started but didn't finish - "What could we have done better?" - May also want to have an external person handle this --- class: exercise ## Fresh Eyes 1. Swap contribution guidelines with another workshop participant. What *can't* you find out in the first 5 minutes? 1. Who gets credit for what kind of work in your project? Who does other kinds of work but isn't credited? Is this written down?