I think 2024.pgconf.dev was a great event. I am really grateful to the organizing team for all the work that they did to put this event together, and I think they did a great job. I feel that it was really productive for me and for the PostgreSQL development community as a whole. Like most things in life, it was not perfect. But it was really good, and I'm looking forward to going back next year. It was also a blast to see Professor Margo Seltzer again; I worked for her as a research assistant many years ago. She gave a wonderful keynote.
Normally, when I go to PostgreSQL conferences, I spend most of my time thinking about and discussing technical topics. However, despite the fact that this was a conference primarily for PostgreSQL developers and about PostgreSQL development, I found that I spent more time at this event thinking about the PostgreSQL community than I did on technical topics.
The Developer and Leadership Meeting (minutes) featured presentations about some of the committees that both do work and exercise authority, and we discussed the fact that most of those committees are self-selecting: the current members choose the new ones. In some ways, this model makes a lot of sense: the current members are the people who best understand the work that needs to be done, and are therefore in a better position than anyone else to evaluate candidates. On the other hand, this can also lead to a lack of diversity: people choose people they know, perhaps even people with whom they are friends, and other people don't get the same opportunities. It can lead to a lack of diversity of opinions, too: existing members choose new members who won't rock the apple cart. That can be good or bad, depending on the situation.
This topic came up again at the unconference, where Stacey Haysler and Joe Conway led a session discussing how to increase community participation. A key point in this discussion was that groups within the PostgreSQL community that need more help should put out open calls for volunteers, and the web site should enumerate all the groups that exist and make it clear whether and how people can volunteer for each one. This also applies to other types of events, like conferences. Very often, these events seem to just spring up out of nowhere and all I have to do is submit a talk while somebody else deals with all the unglamorous work of drumming up sponsors and figuring out lanyards and making sure that every room has a projector, but in fact, the "nowhere" out of which they spring is often a group of under-appreciated people working very, very hard. Yet, without open calls for volunteers, that situation is unlikely to improve significantly: if people (me included) don't say what things they want help with, then other people (again including me) can't entirely be blamed for not helping.
We had a few sessions that were specifically intended to help people who are in the process of learning to navigate the PostgreSQL development community. One was the Advanced Patch Feedback Session, where current committers tried to give advice to some non-committers who are highly involved in the development process. Another was the Patch Review Workshop, which was about learning to review other people's patches. Both writing your own patches well and reviewing other people's patches well are parts of a healthy developer community, but we're not quite hitting the mark at present. Processes and expectations aren't documented well enough, or sometimes at all, and it's not always clear to people what they can do that will be useful, or what they can do that will be successful, and some of that is that we just haven't explained it well enough. If we want to have a stronger development community, we need to do better.
Another issue when we try to work together to improve PostgreSQL together is tone. It's unfortunately rather common for people to receive emails from the mailing list that they don't like very much, perhaps because of the content, but maybe even more because of the tone. While planning out Making PostgreSQL Hacking More Inclusive, Melanie, Amit, Sawada-san and I spent a bunch of time discussing tone: for instance, what is the right way to tell someone politely that you think their idea is simply not viable? We could not agree. Everyone thought that there were good ways and bad ways to phase that message, but everyone had slightly different ideas about what they were. So nobody's going to ever be able to do this perfectly, because perfection is the eye of the beholder, and even among a group of 4 committers we all beheld the situation a little bit differently; at the same time, we all agree that doing better is imperative.
A final aspect of the community that got a good bit of discussion was diversity. Of course, that was a part of what came up in the "Making PostgreSQL Hacking More Inclusive" panel, but it also came up at the development and leadership meeting, and Margo also mentioned it in her keynote. There are, unfortunately, no easy answers here, or at least I don't see them: we can't realistically choose people for leadership positions unless we can first get them involved in ways that make them reasonable candidates for those roles, and the lack of diversity in leadership positions discourages people from getting involved unless they happen to fit the profile. Yet, if we compare the situation now to the situation five or ten years ago, I think people are far more aware that we have an issue in this area, which is something; and I think the number of women attending PostgreSQL conferences, while still low, has significantly increased, which is good as far as it goes. Let's see what we can do to improve things further.
While we're at it, I'd really like to see more people from India and Japan in senior positions within the project. We have very large developer communities from both countries, but there is no one from either of those countries on the core team, and they're also underrepresented in other senior positions. At the risk of picking specific examples to illustrate a general point, there is no one from either country on the infrastructure team or the code of conduct committee. We do have a few committers from those countries, which is very good, and I was pleased to see Amit Kapila on the 2024.pgconf.dev organizing commitee, but, overall, I think we are still not where we should be. Part of getting people involved is making them feel like they are not alone, and part of it is also making them feel like progression is possible. Let's try harder to do that.
I know that this long list of problems might seem a bit depressing to the reader, but I came off of the conference with a lot of positive energy. We will never solve all of the problems in this area, just like we'll never fix every bug in PostgreSQL nor add every feature that PostgreSQL really ought to have. But I feel like we're doing a much better job acknowledging what the problems are, and trying to be thoughtful about them, and even beginning to solve some of them. And that's nice to see. And, on a personal level, I have some ideas about things that I want to try to do differently, too.
No comments:
Post a Comment