Working on Open Source Community Software Is My Job

And How to Hopefully Create Win/Win/Win Scenarios

I am fortunate to have an opportunity to work on DEV’s software. My work is in the open, contributes to the open source Forem code base, and further supports a gathering place for communities.

I’m interested in trying something; but first some background.

A few weeks ago an early career developer reached out to me with some questions. I hopped on a video chat with them. And we kept chatting.

Some time passed, and they asked me about working on a particular GitHub issue on Forem.

Sounded great; it is an issue that is not in the critical path of work. Instead it’s an important code path that could benefit from some attention.

Our plan is to spend some time pairing on the project. And it hit me…might there be something more for community contributions?

Let’s zip back to the critical path; the sequence of tasks that define the fastest possible path to get from the beginning and end of a project. Any delay of those tasks will delay the project delivery.

As part of stewarding DEV, Forem’s product team looks at how we can add, sustain, and even remove features to best support the user experience. They set the priority.

As an engineer, I work from that priority list. And because I’m an employee it makes sense to assign me (or other Forem employees) to the critical path. After all, we can bring our full work week to resolve tasks on that path.

My hope is that community contributions do not fall onto the critical path for a project. Community contributions are volunteer efforts, so I want to honor that gift. I also want to avoid moments of “Umm, checking in on this, it’s blocking a next step…”

So I’d rather that the community contributions nurture and sustain what we have and/or add features that are outside of the current critical path. And I want to see how, as a Forem employee, I can help the community help me help the community.

The Experiment

Next week, I’m going to pair with a community member. My goal is multi-fold:

1. Extend my time to provide mentoring and skill development.
2. Learn new things from a “newer to coding than me” person.
3. Review and further breakdown the task they selected.
4. Delegate a problem resolution.

I haven’t looked nor estimated the effort of this work.

I will consider the experiment a success relative to me if I can hand-off this work and help the developer resolve the issue without me being present at each coding moment.

Thinking of what success might look like relative to the other person, my hope is that the learning, mentoring, pairing, acknowledgment of contribution will be of at least equal or greater value than the time they spend on resolving the task.

Further, I need to begin to consider how I and others might build from this experiment. What might office hours look like? What would be my weekly “community pairing budget?” I am unclear at this point, except to say, I’m looking through an optimistic lens.

Conclusion

As I reflect on this experiment, I see so many potential wins.

I know that whenever I’ve mentored folks, I’ve improved my personal skills.

I also know that being mentored or coached is a chance to up my skills; so I’m hoping that is the situation for the community member.

These mentoring moments help grow and enrich our personal networks. I landed my job at Forem because a former mentee of mine encouraged me to apply (waves at @aritdeveloper).

Also refactoring improvements ease the burden of orienting to the code; they also provide an opportunity to develop and understanding of the code-base.

All of this aligns with the value proposition of a company stewarding an open source project. Namely to help facilitate contributions from community members that align with the vision of the project.

All of this is forem -powering community.