Open-source excursions: The poetry of planning

Reflections on the value of a planning process that emphasizes transparency, empathy, and the people behind the products.
Part of
Issue 19 November 2021


Plans often begin as a way for engineering teams to codify their goals, but they naturally evolve into artifacts read and reviewed by others. Open-source maintainers have learned to leverage and share them to generate energy and exuberance, incorporate user perspectives into the prioritization process, and communicate with their communities.

To further understand how open-source maintainers perceive the planning process, I spoke with some of my Microsoft peers working on open-source technologies. Despite their differing experiences and projects, common themes emerged around the profound value of a planning process that centers transparency, empathy, and the people behind the products. 

Planning to build excitement

A plan can be both a catalyst for getting work done and a means of creating enthusiasm in the community as that work is carried out. As any maintainer can tell you, a little enthusiasm goes a long way, motivating users and contributors to follow upcoming releases and milestones. 

According to Kevin Pilch, who oversees teams working on .NET’s application frameworks, the excitement generated by sharing your plan can translate into more users engaging with alphas and betas during the development process. Contributors also tend to roll up their sleeves and help with roadmap issues they care about, says Merrie McGaw, who leads a cohort of engineers working on the WinForms platform. In my experience, that energy is often all a team needs to overcome inertia and take action on larger bodies of work that might otherwise feel overwhelming.

Planning to prioritize

The planning process is an exercise in prioritization—and a plan can serve as a powerful tool to engage the community in that effort. 

However, it takes a unique blend of technical and user knowledge to prioritize a high volume of user requests, says McGaw. To build this skill set among developers, the WinForms team distributes the responsibilities of triaging issues and reviewing pull requests through an on-call rotation. This ensures each person on the team has “face time” with the user community and helps developers bring a user-focused perspective to internal discussions about priorities.

The ASP.NET Core team leverages tooling to support the planning process. To prioritize issues, they use an internal bug-ranking tool that aggregates GitHub reactions, issue activity, and human-labeled identifiers of impact and severity into a ranked value. Though the rankings aren’t definitive, they help the development team discuss what’s most urgent to address. Maintainers can then present a compelling case for their plans to the community, which helps generate buy-in.

Planning to communicate

Once a team has established its priorities, a plan serves as an effective and transparent way to share them with the community. 

My colleagues use a variety of strategies to accomplish this. For example, WinForms uses a “ROADMAP” Markdown file, a common companion to quite a few open-source projects. The .NET group, meanwhile, assembles the work streams they’ve prioritized for each release into a publicly accessible website, (You’ve gotta love how far you can go with domain names when your project is called .NET.) nteract, my nights-and-weekends open-source project, uses a mix of publicly available Google Docs and GitHub repos to share certain initiatives. 

All of these methods have the same goal: to share ideas with our communities, giving them a sense of participation in the planning process and an opportunity to provide feedback.

True, the community and its maintainers won’t always agree on whether a specific issue should be addressed, and these disagreements can get contentious (as conversations on the internet are wont to do). But they’re also prime opportunities for maintainers to practice empathy—to understand a user’s point of view and gain insight into how they arrived at a particular conclusion. 

Planning incrementally

As Jamshed Damkewala, a product manager for the Visual Studio .NET team, recently reminded me, the planning process isn’t fixed. That’s why it’s crucial to communicate to our communities that it’s a learning journey for all involved. After all, planning is an incremental process, with each iteration bringing us closer to realizing our most ambitious ideas. 

This reminds me of one of my favorite pieces of poetry, “Little Things” by Julia Abigail Fletcher Carney. I’ve cited it in many a conference talk and blog post, and even in my first article for Increment’s Open Source issue:

Little drops of water,
Tiny grains of sand,
Make the mighty ocean
And the pleasant land.

Like my conversations with my colleagues, this poem highlights the importance of cumulative action and individual efforts—and why bringing our community along for the ride is vital to creating a plan that works.

About the author

Safia Abdalla is a software engineer working on open-source technologies at Microsoft and an open-source maintainer on the nteract project. When she’s not working on open source, she enjoys writing and running.


Buy the print edition

Visit the Increment Store to purchase print issues.


Continue Reading

Explore Topics

All Issues