Harihareswara has run or helped run several distributed sprints/hack days/hack weeks. Here are some tips that help. The approach is less "top-down schedule" and more "here's how to adapt to and support the emergent ways people will act".

Helping less-skilled programmers improve their code, dealing with the poor-quality pull requests themselves, and redirecting their energies to improve your project in other ways: tips and examples.

New contributors to open source project should learn how to learn from and contribute to our shared "lab notebooks", troubleshoot with the scientific method, and develop hypotheses.

Tips and resources for creator-maintainers, moving from general management to tech management to open source management.

How to get the best results from hackathons, sprint weeks, and all-hands meetings.

Follow these tips to get new contributors, and turn them into new maintainers.

Whether you're an Outreachy/Google Summer of Code intern or a mentor to an intern, these suggestions help you get the most career benefit out of the experience.

Check for these barriers that often slow down new users and contributors during outreach efforts.

Harihareswara lists some sources of money to fund free culture and open source software projects.

Consider these factors to predict whether it's possible for you to improve an open source/free culture community.

Tips for learning FLOSS applications, using Drupal as an example.

How to attract corporate sponsors: Inventory your potential donors and fundable tasks or chores, prepare your requests and update your website and documentation to ensure your open source project looks credible, make the request, and follow up on responses.

Developers' events: goals, people, activities, things you'll need, and logistics to prepare.

Retain your existing contributors by better understanding what they want and need. Recruit new contributors by easing their path to contribution and making it easy for them to find you and feel welcome.

When should you spend or save? What's on your project's roadmap, and how could you spend to support it?

Understanding your audiences and what you need to tell them, how frequently, and why.

Guidance on open source maintainer burnout and career planning, including a self-guided exercise.

A guide to handling conflict, addressing difficult issues, and recruiting and promoting maintainers in open source projects, including a self-guided exercise.

Why and how you can start, choosing projects to try, and making a first contribution by testing and commenting on bugs.

Experts have a hard time getting in the right frame of mind to write an introduction or overview. Use an audience: give a novice a tour, and use the recording as a first draft.

Questions like "how many contributors does this open source project have?" or "how much contribution is this project getting?" are not as simple as they may seem.

The reasons some open source projects are procedurally but not substantively open, and how to mitigate the problems that friction causes -- including three tips from InnerSource.

Reduce how frequently new contributors vanish by articulating your vision, setting their expectations in documentation and replies, providing quick first-level reviews, and improving workflow.

Noticing that you're burning out; work approaches that can help; succession, sustainability, and new folks; maintainer as parent; deprecating components, and closing a project; further resources.

Supporting users can frustrate maintainers. What are its causes, and how could we build the "infrastructure of equanimity" in open source? Some answers, and ideas for potential cross-project tools & practices.

Your approach will differ based on what kind of project you're joining; consider these categorization systems, and example documents from established organizations.

How do Dreamwidth, Zulip, MediaWiki, FogBugz, and Debian make it easier for less experienced users to submit bug reports?

How easy is the developer setup process for your project? Here's a sample audit report.

Read lessons learned when Harihareswara implemented the Friendly Space Policy for Wikimedia Foundation technical events.

Read lessons learned when Harihareswara successfully mentored an Outreachy intern (who later continued to contribute to the project).

This open source team successfully trained all its developers to also review each other's code.

Data from GitHub is not a reasonable proxy for data about open source as a whole. Here are examples from supply chain security, funding, and research and infrastructure support, plus resources to reach further.

Many Google Summer of Code and Outreachy applicants are not fluent English writers. Tutoring helps them write better internship applications, blog posts, bug reports, code comments, pull requests, and mailing list posts.

How 15 hours of writing, coaching, and nudging helped a maintainer publish a delayed release.

The Strengths, Weaknesses, Opportunities, and Threats framework helps the Autoconf project assess itself and prioritize future work.

Harihareswara presented this poster, summarizing lessons learned at the Recurse Center, at PyCon 2014.

Why the new PyPI took so long to arrive, and what's new. In LWN.

Harihareswara traces the FOSS internship program's growth over its (then) nine-year history.

When we compare community anti-harassment policies to licenses like the GPL, we learn unexpected lessons about our attitudes towards governance. (A FOSDEM talk, originally at Crooked Timber.)

Even if you've been using Python for years, you may not know about alternative command-line interpreters like bpython, some helpful debugging options, and how to use the codecs module.

Shallow cloning, blaming, nicer diffs, and more features help you use Git more efficiently.

Harihareswara describes using a screenscraper to grab text and adding a client-side search engine to three years' worth of newspaper columns.

Whisper is an open source speech recognition tool; read about use cases, logistics, accuracy, and an approach reasoning about ethically using it and other artificial intelligence/machine learning tools like it.

Reply to a mailing list post that isn't in your inbox, while ensuring future readers and longtime subscribers will see your update in context.

More than a decade after its last major rewrite, Mailman improved usability, system administration, and more. In LWN.

Who's funding open source projects, a quick case study, key steps in figuring out a good project idea, budgeting, hiring, and submitting, and how a new workgroup can help you get going.

For PyGotham 2017, Harihareswara and Jason Owen co-wrote and co-starred in a play about code review, company culture, and collaboration styles.

At PyCon 2016, Harihareswara demonstrated some useful (and useless) underappreciated features of HTTP.

Harihareswara delivered this keynote address to the Open Source Bridge conference in 2012, discussing lessons she learned from her parents that helped and hindered her as an open source leader.

This keynote address to Wiki Conference USA 2014 (transcript, audio, and video available) discussed features of good learning environments.

A newbie-friendly walkthrough of how developers fix bugs, including searching for the right file, making the git commit, getting it reviewed and merged, and closing an issue in a ticketing system.

Read and watch more presentations on and interviews about technical and management topics (grants, Python, MediaWiki, outreach events, project management, etc.)

Good interaction design helps us execute on our values; here's the why, the how, and the next steps. Adapted from a keynote address.