This post is related to the earlier OpenStack Developer Satisfaction post, which may be of interest.

As part of the Forum at the recent OpenStack Summit in Sydney, there was a session on "Making OpenStack more palatable to part-time contributors". The session had an etherpad and there are some useful additional notes on Colleen Murphy's blog. Update: and she did a great related (sort of the flip side of the coin here) presentation at summit: Communication through Code How to get work done upstream

In the 2019 Vision Statement for the Technical Committee, one of the achievements is "more sympathy to the needs of part time contributors". To reach that, being attractive and inclusive to part-time contributors is important. Thus the session.

While no concrete plan was made during the session, some of the issues were enumerated and some differences in understanding were illuminated. That's a good first step to getting anywhere.

Casual Contributors

A primary difference in understanding was over the concept of "part-time". The etherpad lists some scenarios, running the gamut from what have been called "drive-by" contributors to contributors who used to be full-time but are now, for whatever reason, only able to contribute a small amount.

While it is important that individuals who fall into that latter category are included (it is likely their contributions are exceptionally valuable) in the community, due to their experience with and awareness of the processes and social mores, "palatability" doesn't strike me as a specific concern (except with regard to the larger satisfaction aspect). This suggests a different term than "part-time" might be in order.

"Casual contributor" might work, borrowing some of the connotations from the "casual gamer" term. These are people who need and want to contribute but it is not their sole or obsessive focus. With that phrasing, barriers to participation become relatively larger when compared with the perceptions of someone who is making a long-term or full-time commitment.

It also, hopefully, limits the extent to which old timer survivors who overcame those barriers through hard graft are able to say "do what I did, it worked for me".

Taking pride in the pain, suffering, and hard graft you endured to join a club that is supposed to be open to everyone is not a great look.

— See Dent (@anticdent) November 7, 2017

Casual contribution ought to mean just that: casual: relaxed and unconcerned; not regular or permanent. It should also mean some chance of success; that is that any code contributions actually get reviewed, and if good, get merged.

This is not something we (where "we" is the OpenStack community) have always been particularly good at. Here's a reasonable looking patch to Nova that's been under review for more than two years.

Additional barriers to participation include:

• Lots of project knowledge is tribal, and even when not, requires piecing together many disparate pieces. Ramping up to understanding is challenging.

• Visibility has historically been a key factor in getting attention, especially in the more established projects. If you want to make changes, you need to be around, alot, and you often need to attend in person events (e.g., the Forum and the PTG).

While both of these situations may have some aspect of "that's just the way it is" that doesn't mean we should give up on trying to improve the situation.

Things to Try

There were several proposed solutions (some highlights below), but no concrete plan for next steps. OpenStack's culture and governance doesn't allow for decrees and ultimatums, only awareness. The thing to be aware of here is that things have changed: casual contribution is not only becoming the norm, it is a sign of health and maturity in the project. We want broader contribution. If you have an opportunity to do or influence any of the following, do!

• Write weekly updates from projects or subteams to a relevant mailing list to make it clear what's in progress and what matters. This is happening more and more often and people seem to dig it, but it is only useful for people who make a habit of reading the mailing list; many people do not. It may make sense to syndicate them in some fashion.

• Develop a culture of picking up and improving on proposed changes from contributors who are not able to attend to their patches on a frequent basis. Doing so would require getting past code ownership, which we should do anyway.

• Produce simplified architectural diagrams; something to look at that explains the big picture of how things work together, within the individual projects. In some cases these already exist, but their discoverability could be improved.

• Shrink or decompose projects. Smaller pieces with clear boundaries and limited goals are easier to ingest. They have a smaller surface area that a casual contributor may usefully traverse.