Becoming an ASF Committer

Leave a comment

I’ve been mentoring some folks at work who want to become committers in various ASF communities, and wrote the following as part of trying to document that advice.

Note that I’ll likely update this article periodically to reflect edits on my internal version of this doc. Your feedback would be very helpful in that process, as I try to help my colleagues be better upstream citizens.

Disclaimer

Nothing in this post should be construed as a guarantee. You can do everything listed here, for years, and still not become a committer. This is because the decision is made by individuals on the project PMC, who do things for their own reasons.

On the contrary, this document discusses how things should work, and sometimes do work, in some Apache Software Foundation (ASF) projects, but might not on the one you’re interested in.

Beneath each of these recommendations is the assumption that you are acting in good faith, for the benefit of the project. Simply attempting to check these boxes to game the system will reflect badly on you, and probably on your employer, too.

Becoming a Committer

It’s important to remember that becoming a committer is not a reward, or a recognition, so much as that it is the project expressing self-interest. That is, people are added as a committer to a project because it benefits the project, not because it’s some kind of pat on the back for the individual in question. As such, every behavior suggested here is about advancing the interests of the project. It is critical that you think, first and foremost, about being a project owner, and working towards the benefit of the project and its users.

These, therefore, are the behaviors that you should exhibit if you want to become a committer, and then a PMC member, on an ASF project. (These are not unique to ASF projects, of course, but process will differ greatly from one project to another, and are largely similar among ASF projects.)

Read the mailing list

ASF projects communicate on the mailing list. If you want to be involved in the community, you must set aside time every week (preferably every day) to keep current on the community discussion.

When first participating in an ASF project, you can (and should) look back several months (or as far as you have time for) to see what has been discussed recently. You can do this at http://lists.apache.org/

A growing number of projects also have a presence on Slack, Discord, or somewhere else. Find where that is, and become a regular. A shrinking number of projects have a presence on Libera IRC – mostly the much older projects. This is where you’ll connect with the older members of the projects and learn more of the ancient project lore.

Contribute code (and other things)

If you want to become a committer, you should make significant contributions to the project. The most obvious thing to contribute to a software project is code. Code contributions should be diverse in terms of size and significance. That is, you should work on small issues and large. You should collaborate with others on features and fixes, and you should propose significant changes yourself. You should dig up old tickets, and work towards resolving them.

In particular, you should work on code that is of benefit to all users, rather than focusing solely on features that benefit only yourself, or your employer. As a project owner, you should care about the entire health and sustainability of the project.

Code contributions are not the only type of contribution that counts towards becoming a committer, it’s just the most common. Design, documentation, marketing, event management, and many other ways of contributing to the success of a project are also often considered in making someone a committer. While the term “committer” implies committing code, it can also be interpreted as someone who is committed to the project.

End user support

Answering end user questions has many benefits. It’s the best way to establish expertise in aspects of the software that effect actual users, and, thus, the best way to stay in touch with user concerns. It’s also the way to establish and maintain visibility in the project community, because your name is always visible on the mailing list.

Caution: Do not just jump in and answer every question with visibility as a primary goal. Ensure that your answers are actually useful, and contribute something to the conversation. Simply posting to every conversation, particularly when someone else has already offered a good answer, can be perceived as attempting to game the metrics.

Documentation

Improving the documentation is one of the most effective things that one can do to improve the user experience. If you notice many people asking similar questions, this is usually an indication that the documentation is weak on that point. Fix it. When the question is asked again, point to the improved documentation, and ask for feedback as to how it could be further improved.

Take criticism of the documentation as a challenge, rather than a personal criticism.

Review PRs and tickets

Dig into unmerged PRs and outstanding tickets. Figure out how to navigate the process to get an old ticket resolved, or a PR merged.

This is an investment in the project in two ways.

The obvious improvement is getting an issue fixed or a PR merges, thus enhancing the project. The less obvious way is that ancient tickets, and unmerged PRs, communicate that the project is not actively maintained, and that user issues are being ignored. This undermines project trust. Thus, addressing these things builds community trust, and increases your personal value to the project.

Be visible

Participate meaningfully in discussions on the developer mailing list. Drive discussions through to action. Advocate for changes that help yourself and your employer, but also for those that improve the project as a whole.

Get to know the important characters on the project, and what their priorities are. Help them achieve those priorities in whatever way you can. Figure out who you can best collaborate with to advance your own personal interests in the project, but also the overall health of the project and community.

Start conversations around topics you’re passionate about, and volunteer to be the one to address them.

Do not, however, just talk to be seen. Nobody is fooled by that.

Vote on releases (non-binding)

Vote on release candidates and releases (non-binding).

Note that a vote should always mean that you’ve actually tested, so testing releases is implied here, too. Indicate what platform(s) you’ve tested on, and what was the nature of the tests that you performed. Testing releases on a variety of platforms and configurations is a very valuable piece of information for projects with limited testing infrastructure.

While these votes don’t “count” towards making a release official, it’s both hugely beneficial for the project, and increases your visibility.

Give talks

Propose talks to conferences about the project, and about how your employer’s customers are using it.

Proposing “Introduction to Apache Woobly” talks has many benefits. It is a great way to get the word out about the project. It’s good for establishing yourself as an expert in the field. It educates users (and potential customers) about operating the software. And it will help you identify what’s actually important about the software, how people use it, and what kinds of questions real users are asking about the software.

ApacheCon is the obvious place to give these talks, but also look for conferences about the general technology space around the project you’re contributing to. Ask us on #open-source (Slack) for suggestions, if you’re not sure where to submit these talks.

Once you’re a committer …

If and when you achieve your goal of becoming a committer, don’t consider your journey done.

Becoming a PMC member is a continuation of the same path. Continue to do all of the above things, focusing more on the health of the project as a whole, rather than just your personal interests, or those of your employer or manager.

Also, take an active interest in other contributors – both those on your team, and those with other employers. Mentor them in following the same path that you followed. Encourage them. Celebrate them, and mention them to other contributors. This is an investment in the future of the project, so that, some day, when you move on to something else, the project will live on.

Interest across multiple projects, and at the Foundation-wide level, is the start of the path to becoming a Foundation Member, if that is something that interests you.

Summary

Finally, a reminder – there’s no way to guarantee promotion to committer or the PMC. However, if you make your goal the improvement of the project, rather than just about personal promotion, and approach these recommendations as a path to project ownership, in good faith, these are your best path towards that goal.

Resources

Find your project’s committer and PMC membership lists at https://projects.apache.org/

Read mailing list archives at https://lists.apache.org/

Find your contribution count to date on Github, for example: https://github.com/apache/hadoop/graphs/contributors (You can drag a date range to narrow it down to recent contributions.)

View past board reports from your project at https://www.apache.org/foundation/board/calendar.html This is a good way to judge the rate at which a given project adds committers and PMC members. It’s also a way to compare how long other individuals took to attain committer status.

Reading: The Sword of Shannara

2 Comments

I’ve started reading The Sword of Shannara. Re-reading, I should say, and it might even be the third time. It holds up, and is as gripping now as when I first read a beat-up copy from the school library at Florida High School in 1982.

The Sword of Shannara - Wikipedia

40 years later, Terry Brooks is still telling stories, but these are the ones – the original trilogy – that I keep coming back to. There are passages that I remember from the first time, and others that are new again.

I’m looking forward to this new old adventure.

Reading

I finished The Girl on the Porch by Richard Chizmar. I picked it up in the first place because Stephen King wrote the book Gwendy’s Button Box with this author so I expected good things. It was okay but not terribly interesting.

I’m looking forward to reading The Navigator’s Children (Tad Williams) later this year but it doesn’t come out until November.

I think I might take a shot at reading the Shannara series again since it’s been 30+ years and so much has been added since then.

Create > Consume

This year, as every year, I resolve to create more than I consume.

(edit) WARNING: this was a shower thought and seemed very profound at the time. In editing afterwards, perhaps not so much. Your mileage may vary.

Of course this can be translated in a number of different ways, and I mean them all. But while I hope to create more in quantity than I consume, I realize that’s not always practical.

Consider, for example, if you consume a cheeseburger. In theory, that consumed the time and resources of at least five different businesses. There’s the bread, the beef, the cheese, packaging, and the company that sold it to you.

But in reality, you probably only consumed a few seconds of each of their time, if that. Likewise, if I try to create things that are a benefit to more than just myself, I can have a similar distributed influence.

So what I tend to mean, by my resolution, is that I intend to spend more time creating than consuming, and thereby do my part contributing to the whole.

This is a really hard thing to do in practice, because life is tedious, stressful, and exhausting. And at the end of the day, I really only want to sit and drink in the pablum of television.

So, anyway, here’s to New Year’s resolutions, and meaning them honestly.

Knife 5 – Cthulu

Knife 5 is another Damascus blade with a Canary wood handle and a Cthulu mosaic pin in the lanyard hole.

Initially I was making a purple heart handle but it broke while I was clamping/epoxying. Oops. So I started over.

Scheduling for later because it’s a Christmas present.

Kenya day 7, Olepolos

1 Comment

(More Kenya notes)

On the morning of Saturday, November 19, 2022, the Droidcon speakers were to meet at the Shell station on Waiyaki Way, which was just a short walk from my hotel. We were told we were going to leave promptly at 10:00, which was met with some laughter.

So at 9:30, I was dutifully waiting, all alone, at the Shell station.

By 10, there were a handful of people there, and other started arriving. By 11, there were enough people there to start talking about how transportation was going to work, and a little after 11, we started walking over to where we were going to meet our matatus for the trip. Which happened to be back over in front of the Jacaranda hotel.

We loaded into the matatu, where there was very, very loud music playing, and music videos on numerous TVs.

After another 20 minutes or so, another matatu arrived, and we redistributed between the two, and finally, just before noon, we pulled out, music thumping, towards the mystery outing.

We went through Langata, and Rongai, and out into Maasai land, and around 2:30, arrived at Olepolos Country Club, in Kiserian, for nyama choma.

I’m really glad I went. It was certainly not something that I would have chosen on my own, with the super-loud music and the hours of driving. But the time with new friends, and an amazing view once we got there, and good conversations there, were just a wonderful experience.

While there, Frank and I walked around, and he showed me the Maasai boma that was there on the property. (I did not take any pictures of that, since the people living there were not eager to be photographed.

I was fascinated to learn that, even now in 2022, the Maasai people live as they always have. Frank told me some about their traditions, and how they live. One man will have many wives, each of whom has their own hut for themselves and their kids. Each evening, the man will decide which wife he wants to stay with, and will plant his spear at the door of her hut. All the other residents of that hut will have to find other lodgings for the evening.

When he wants another wife, he is not obliged to inform her. Rather, he negotiates a bride price with her father, and the other wives fetch her, and help her build her new hut in the boma.

I also learned that daughters do not look at their father, as it is disrespectful. They would certainly not look him in the face, but must avert their eyes when he is near.

After dinner, the matatus had already left, and so I was put in a rather small car with 7 people, and we drove back to Nairobi, arriving quite late.

Another really delightful, and very long, day.

Kenya Day 6, Droidcon day 3

1 Comment

(More Kenya notes)

The final day of Droidcon was also excellent. Lots more great presentations, and great conversations.

At one point in the day, a crew from KBC came to interview various of the speakers, and we were featured on the news that evening, including a brief clip of my interview.

In the closing, we were told that there would be a speaker outing the next day, to an undisclosed location, and that we should be ready to leave promptly at 10 am from the meeting point. One speaker asked if this was 10 am Africa time, and everyone laughed.

More in this in the next post.

Engineers vs Designers – Kennedy Kahiri

1 Comment

(More Kenya notes)

I attended a talk on Friday by Kennedy Kahiri about the relationship – often adversarial – between software developers and designers. Developers, he said, are interested in building the right thing, while designers tend to be focused on building the thing right. These different priorities can lead to conflict. He outlined seven things you can focus on to avoid these conflicts:

  1. Be collaborators, not competitors
  2. Process should be inclusive, not siloed
  3. Work by compromise, not ultimatums
  4. Build for the customer, not for your own ego
  5. Be flexible. Adapt to realities. Don’t be stubborn/rigid about decisions
  6. Before designing or coding, understand WHY you are doing this, and what problem you are solving
  7. Build something that solves a problem, and has a positive impact on business

As an Amazonian, of course, it all comes back to #4 – the focus on the customer first in all decisions leads to the best solutions.

Overall, a really great talk.

The Margin Is Too Narrow