Here's a brief outline, and relevant links, for the talk I'm about to give at Linux.Conf.Au: "How To Get A Project Unstuck -- And Fixing The Skill Gaps That Got Us Here". I am not presenting any slides.

Introduction

My consultancy is Changeset Consulting.

Stories

1. Gathering info and helping decisions:

   WisCon

   Mailman (What was new in GNU Mailman 3.0, announcement of the Mailman 3.0 release)

2. Gathering funding:

   Video, transcript, and slides for my PyOhio talk on applying for grants to fund open source

   "Problems and Strategies in Financing Voluntary Free Software Projects" by Benjamin Mako Hill

   Autoconf (Case study: rejuvenating Autoconf; also see how my upcoming book is helping Autoconf's developers decide what to do next)

3. Nudging, prioritizing, and communicating:

   Pipenv (Pipenv case study)

A case study I didn't have time to discuss in this talk: Finishing the rearchitecture and deployment of PyPI.

The credibility and change sequence

This is the outline of my forthcoming book. My sampler ebook of Getting Unstuck: Advice For Open Source Projects, available for free download once you subscribe to my 1-10 times per year newsletter, includes that full outline. The basics:

1. Settling in (doing routine tasks that do not require much trust)
2. Taking charge (doing things that require trust but that the group has already agreed needs to happen)
3. Making change (modifying and adding social, digital, financial, and legal infrastructure)
4. Passing leadership over to successors and leaving

I may also refer here to "Software in Person", my article on how to make the most of synchronous developer events.

Why maintainers usually don't have these skills

Where maintainers come from, what we value and grow, and a lack of tools and practices to help learn and teach these skills.

Let's change that

Existing initiatives or resources to improve and teach these skills:

• The Kubernetes shadow program for its release team
• Mozilla's Open Leadership Training Series
• Simply Secure's support and training in user experience and research processes
• Karl Fogel's book Producing Open Source Software, the best book on how to start and run a new open source project

Ideas for further tools and practices to improve skills (this is where I mention possible improvements to GitHub's "saved replies" tool).

Conclusion

Thanks for watching and listening. I look forward to hearing your thoughts, so please contact me to let me know!

Edited Feb 5th to add: video is now up! And thanks to Nick Murphy, R. Fureigh, and Keffy R. M. Kehrli for being test audiences!