5  Community Recommendations

Our analysis of participant interview transcripts resulted in several community-led recommendations that we feel are valuable to consider when developing new approaches for advancing DEI in the Astropy project. Some of the recommendations echoed themes in Astropy’s recent community survey, providing strong rationale for taking action on those points. Where possible, we provide quotes to support a given theme; in some cases, though, we do not provide an attribution or quotes in order to protect the identities and privacy of the respondents.

Help Newcomers Find Support

In DEI interviews and the community survey, respondents overwhelmingly expressed a desire to improve avenues for newcomer participation in Astropy. Specifically, respondents noted that newcommers have trouble finding ways to get started working with and within Astropy communities. Ensuring a welcoming, accessible newcomer experience is vital to promoting a more diverse community and facilitating equity and inclusion, so we probed on this topic when it emerged in our interviews.

We are aware that Astropy maintains a list of “good first issues,” but interview participants were either unaware of the existence of the issue tag or believed the list was too short or specific for most newcomers to find a place to contribute.

Furthermore, fear of failure and concern over contributing detrimental code also impacts newcomers’ propensity to become contributors. Indeed, one astropy user we interviewed expressed fear of “breaking” something with new code, which has partially kept her from being a contributor:

The imposter syndrome that kind of gets you where you’re like, “Ooh, scary. What if I add this thing and it’s bad or it breaks something?” Graduate student astropy user

In considereding how to alleviate these fears, there was some optimism among interviewees that automated tooling could reduce the social or psychological burden of contributing, particularly for newcomers who might be nervous about the quality of their work:

There’s lots of new concepts happening, but in terms of the actual, like, difficulty of pushing a piece of code and then getting an automated response and then tailoring it before I think the humans really need to see it is you need a little bit of experience and mostly just gumption.Astropy maintainer

Furthermore, much of the work of Astropy historically has been the work of software development. But in recent years, efforts such as training, lesson development, documentation, code formatting, and community leadership have become new roles valued within the community. Each of these non-coding areas is an area where on-ramps and invitations to contribute can be extended in different ways. It was clear that many “users” of Astropy care deeply about the software and its continued availability and are looking for ways they can contribute to that end. Closing the loop and connecting “newcomer” enthusiasm to areas of effort would be beneficial.

An astropy maintainer we interviewed noted that reframing some of these contributions as substantive and making them more visible to potential contributors could be a bigger priority for the project:

One of the weird things I think is important is also making more avenues for contributing to the code … From qualitative experience watching new contributors, many times there are people who don’t know astrophysics, but who are interested in contributing to the code base. And so, you know, they’re maybe not bad at algorithms. Or oftentimes many of them are just interested in like stylistic and linguistic improvements, which astropy was in desperate need of, and less desperate need, but still needs. So we’ve seen a lot of people that swing in for two, three contributions, supplementing the code. So I think one thing that would be great would be figuring out how, but I think part of it is that non-substantive contribution than ones that are just like to the stylistic beauty of the code. It’s a nice itch to scratch, but I don’t think it’s fulfilling in the same way that, you know, making something, making it something that’s a contribution. I think people end up drifting onto the next thing, but it’d be nice if it stuck around. So figuring out how to do that would be great. Astropy maintainer

Finding new avenues for community members and potential community members to contribute may also benefit from a broader view of the disciplines and backgrounds that are suitable for Astropy, a topic we expand upon in the next point.

Embrace Intellectual Diversity

Newcomer challenges are exacerbated when the community member is coming from a non-astronomy, non-scientific OSS discipline. In other words, it is difficult for individuals from other disciplines to “find a place” in the community, even when they believe their unique skillset could be beneficial to the project.

We interviewed an Astropy newcomer from a country that is underrepresented in Astropy. His background is in artificial intelligence and machine learning, where he developed a skillset that he believes could be useful in many different scientific domains. Accordingly, he is continually looking for opportunities to contribute to OSS projects and often collaborates with astronomers and astrophysicists. He has, however, found it difficult to make strong ties in the Astropy community, ties that he thinks would lead to fruitful collaborations:

I do find a bit difficult in finding the relevant community because of my different background. So as I am from AI background and not much familiar with the science or astronomical aspect, I believe that collaboration could be helpful as there are different expertise involved from the collaborator as well as from me, but yeah like there’s a lack of communication that I can cite here. The reason is that there are some terms which I may find it difficult … So due to that, there’s not much interaction happening between the between me and the community, which causes some issues while collaborating. Astropy newcomer

He is seeking avenues through which he could find these potential collaborators, a sentiment we also heard in the community survey regarding specific astronomy sub-disciplines:

I would like to focus myself on collaborative opportunity itself. If we could have a common forum or something like that which is already available as on Slack, then like people can basically talk about the open problems there and people like me who are much more into the ML stuff or who are not much into Astro can accordingly comment on it … it’s just that we know that we have this data and this is the problem. So how to solve the problem is what we can do. And identification of problem is what, from the Astro perspective, will be needed. Astropy newcomer

A revised way of finding Astropy community collaborators would enable him to improve his existing strategy for making connections, which depends on reading lots of academic papers and finding places where novel approaches might help improve the method. As he explains, he currently combs through academic papers and presentations and reaches out to the authors when he has an idea:

As far as I can see, typical papers from … a good, a decent journal, all the works there are typically based on very old ML techniques. So again, that’s what I feel is causing, I mean, the lack of collaboration is basically what is causing this problem. Although there can be techniques which can improve the results, way better than what they have achieved, but they are basically unable to because of lack of awareness of these novel algorithms. Basically I go looking throughout those presentations, like particularly from the professors, and by seeing the problem in their particular work there’s a substantial opportunity to improve those results. And that’s how I had to reach them and accordingly collaborate and work with them on those topics. Astropy newcomer

To be sure, this interviewee does view himself as somewhat of an “other”: He is aware that the primary goal of Astropy is to improve astronomical research, and his tone suggested he was hesitant to upset the balance of disciplinary backgrounds in the community. He did, however, have some ideas about how to manage this problem:

So maybe like people who are interested in AI as well as Astro could be given a specific role and they could interact at that specific channel. Similarly, you can say that Astropy can maybe float a Google form or something like that, asking people about their interest and suitably make a Google group or in Slack itself, make a community or make different channels wherein people can join and discuss stuff. Astropy newcomer

In other contexts, we have seen the value of inviting participation from individuals with disciplinary backgrounds that may not seem like an ideal “fit” for the project. Technical writers can aid with documentation; data management specialists can find efficiencies in the data storage, manipulation, and processing pipelines inherent in OSS work; social scientists can provide data and insights that help improve collaboration and coordination; and users from wildly different domains can surface and explain issues that might be in typical users’ or contributors’ blindspots. Promoting intellectual diversity in the project, then, can be beneficial to many different aspects of project health, including but not limited to code quality.

Learn from Other Communities and Their Events

We asked interviewees about their perception of DEI in both the Astropy community and the other communities they participate in. These questions elicited positive and negative examples, with the positive examples from other communities being useful anecdotes for Astropy to learn from. An astropy contributor, for example, recalled an incident he was a part of at a major astronomy conference and expressed appreciation for how it was handled:

[At the conference], I actually ended up filing a violation of the harassment policy. Somebody had made a, um, transgender unfriendly joke at the reception. So I went through the process and one thing they did to make it easier is that you could call a phone number, but they also had an online form. And then, I was in my kind of state of emotional distress at that time when I decided to report something, I said, “Oh, there’s a online form. I can submit that.” But ultimately, I had a phone call with a human resources person that the [conference organizer] had hired to investigate those things. And it went very differently than what I was expecting. But the thing that really surprised me was I thought I was going to have to bring witnesses and prove that the person said it. And it wasn’t like that at all. It was kind of like, “Well, what do you think should happen to the person?” And we talked about that some. They had to view some materials, you know, some educational materials. So I guess if that were more widely known, then maybe people would feel more comfortable with reporting it because the, yeah, the HR person that [conference organizer] had hired, it was really, really pretty good.”

These small interventions–offering multiple ways to report violations and making the process transparent–offer immense utility in making people feel that they have agency in the community. Likewise, making the people who handle these issues visible to the community can also ease concerns about reporting and otherwise discussing incidents or structures that make them feel uncomfortable.

Beyond negative incidents that were handled well, interviewees also discussed encouraging experiences they’ve had in other communities. One respondent described bringing a family member–an aspiring OSS contributor from a heavily underrepresented group–along to a Python-oriented conference. Perhaps to their surprise, the welcoming environment led to a strong sense of self-confidence and a host of networking opportunities:

Yeah, so I guess like having that explicitly stated, you know, and not just saying a bland general statement about diversity and inclusion, but naming the categories specifically, [and making the physical environment more welcoming], I think that made us all feel a lot more at ease that [family member] was at a good place.

Beyond these examples, looking to other communities can help to identify problems that are common across all types of OSS projects and adapt the solutions to them. OSS leaders know this well, given that they often share frustrations and ideas in informal ways. Formalizing this problem-and-idea sharing process could enable more members of the community to engage in developing solutions to some of the more common problems OSS projects face.

Give Guidance to Core Developers and Maintainers

A recurrent theme across any type of social science inquiry into OSS projects is the demeanor of the project’s core developers, contributors, and maintainers. To be frank, these individuals can get caught in a bind: The time demands of the (often voluntary) work are not always amenable to kind, patient, and thoughtful interaction. Furthermore, these groups grow accustomed to interacting with one another in ways that prioritize efficiency and technical development over social dynamics.

While necessary at times, it is important for core project members to remember that they represent the community in ways that the average user or contributor does not. They are continuously interacting with users, contributors, and potential community members at a higher rate than others, and therefore become the “face” of the project for many newcomers.

From the perspective of interviewees, Astropy does a good job of managing the tone and content of interactions with individuals who may not yet grasp the various norms and approaches to communicating about technical topics:

I think most astropy maintainers are pretty studious to then present a, um, a friendly face, you know, even if something’s quite clearly wrong. When it’s another maintainer, you’re like, “Please fix.” If it’s a person contributor, you’re more like, “Uh, oh, thank you so much. I see that there’s an issue here. There are some ways to address it. Please let me know if you need any help.” I think the friendly face is important.

Reiterating the “friendly face” to core project members–whether through formal trainings or small interventions–helps to keep this reality front-and-center as the project grows and evolves. Beyond the friendly face, core members should also be persistent about following up with one-or-few-time contributors who they’d like to see continue to engage and contribute. As one maintainer noted, it’s often as simple as pointing these individuals to similar problems that match their skillset:

I mean, yeah, we don’t assign them to anything. If they actually had a very tight PR, so it was well-focused on one issue, then that often takes the form of right here: “Thank you so much for contributing. There are plenty of other of these types of PRs. We have a list of them on our issues page on GitHub, so please take a look.” That’s if their PR was well-crafted from the get-go. Astropy maintainer

Make Community Member Roles and Pipelines Explicit

Interviewees and survey respondents alike mentioned that the process of moving from user to contributor to core project member is not always explicit or easy to map out. When a newcomer, especially one from an underrepresented background, is considering joining a community, the lack of clarity on this potential trajectory can be a deterrent. In other words, it is easier and more comfortable to learn both technical practices and social norms when one’s future role in a commmunity is easy to imagine.

Making the various community member pipelines explicit could go a long way in diversifying both the Astropy community and the project’s leadership. Conversations among leadership and the community about these trajectories may also help to address latent problems in those pipelines. In one of our interviews, for example, we asked about the potential trajectories for community members towards leadership positions. This conversation generated an insight about the Coordinating Committee’s diversity that is certainly worth acknowledging and strategizing:

Yeah, well, the field of astronomy, I guess, itself, it still tends to be skewed pretty heavily towards North America and Europe. And yeah, that shows up in the composition of the Astropy Coordination Committee. Astropy contributor

In this case, the interviewee ascribes the lack of CoCo diversity to the lack of diversity in the discipline more broadly. The next section, consultant insights, will dive a bit deeper into how Astropy might view itself as a catalyst for change in this domain. Regardless, sparking these kinds of conversations about how newcomers, and even experienced community members, perceive their future in the project can surface actionable insights to improve the project’s pipeline from role-to-role.

Use “Buzzwords” with Care

The temperature around DEI conversations has risen in recent years: From business leaders to governments to scientists, not everyone is on board with the idea of intentionally promoting diversity, equity, and inclusion in organizations. The recent fervor around this topic has made word choices and explanations of concepts critical to productive discussion. For this reason, community members suggested that Astropy use care and caution when communicating about its DEI efforts.

This concern cuts both ways. Individuals and groups who are hesitant about DEI initiatives question the rhetoric and language used by its proponents; on the other hand, proponents also hold concerns about watering down the conversation by relying too much on buzzwords, as was the case with a graduate student astropy user we interviewed:

It’s a little frustrating because at the same time, it is a big issue I think for a lot of spaces. And a lot of communities, but also recently there’s been a lot of trends, where people just throw those words around like buzzwords and it’s frustrating because it dilutes the whole purpose of, you know, talking about the issues with equity and having the people who are in a community actually be represented by whoever’s meant to be representing them. Stuff like that. That’s kind of broadly, I think, those things are important and it’s not good to downplay.

She continued, noting that word choices can influence who ends up in a community and, in turn, what work gets done:

Because it does really influence not only the social dynamics that happen if you’re including people, versus you’re not being nice, but it also does affect not only the way things done, but what things get done. Because if you have a very narrow definition of people, you only have one narrow group, then the probability that everyone thinks the same way is much higher. If you have a really diverse group, you’re going to get a lot of different ideas. You’re going to get a much better breadth, I think, of idea generation, things to do. And I think that’s something that can be, you know, if you’re trying to contextualize within Astropy, if you want a tool that everyone truly can use and everyone goes, “Ooh, yeah, this is the one tool for, you know, Python and astronomy,” then you gotta have breadth, obviously. And I don’t think you can realistically get breadth if the people who are trying to create that all come from one background and have the same sort of things to say about it. Graduate student astropy user

Consulting with DEI experts who have a strong command on DEI-focused language and messaging can help in this regard. OrgMycology is limited in its capabilities in this domain, but is happy to offer suggestions for organizations and individuals who hold expertise on communicating about DEI.

Offer Safe, Constructive Avenues for Feedback

Feedback and collaboration are central elements of any successful OSS project, where contributors, core developers, and maintainers must work together in cohesion. The structure and tenor of these feedback loops are as important as the content: Unhealthy interactions can stymie motivation to participate, especially when participation is voluntary. Incidents have occurred within the Astropy community that speak to the need to provide more guidance and training on interacting with respect and kindness:

[A contributor in the community] is not a native English speaker, and she feels like she’s kind of been bullied or put down by… I mean, it’s easy, and it’s easy for it to be as simple as somebody saying like, “Oh, so-and-so is not such a good speaker” or something. And like minimizing their participation in a workshop or other presentation.

Two interviewees mentioned that meeting people in-person helped to feel more comfortable with the level of attention their contributions receive on platforms like GitHub:

Oh, yeah, I think in my case, it was just being able to corner people. I mean, I literally had to corner them and get them to help me. I did notice, so after the conference, I had this large pull request, which is the first time I had ever undertaken something for open source that was that big. And yeah, I remember for a few weeks afterward, it felt like nobody was talking to me on GitHub, like the pull request was sitting there. But I mean, things pulled together, like when it got close to the feature freeze deadline, then that’s kind of when people turn their attention towards getting the pull requests straightened out. And I got the attention that I needed and then it all worked. I think we can all work online. I mean, we’re all having to get used to that because of the pandemic, but before, when I worked on a European project, we always used to say, like, if we saw people once a year or so, that’s kind of enough to keep the contact with them and then you can interface remotely the rest of the time.

Considering conditions such as these is important when designing avenues for users and contributors to receive feedback. Face time, in other words, can help put potential contributors at ease and make contributions more accessible to a wider variety of individuals. While scaling this approach is difficult, even short videoconferences may provide some of the social interaction necessary to get users over the threshold to contributors and help them feel that feedback is constructive and healthy.

Implement and Enforce the Code of Conduct with Creativity

Codes of conduct are very useful for making community members feels safe and comfortable interacting within a community. Many projects, however, struggle with how to implement and enforce these codes of conduct. The primary problem, according to interviewees, is the balance between anonymized and private incident reporting and human-centered incident reporting. On one hand, anonymized reporting can make community members less fearful of retribution for reporting an incident.

On the other hand, the opacity of reporting in this way can make it difficult for a reporter to know who is handling the issue and what the outcomes may be. Furthermore, reporting forms cannot always capture important signals such as tone, emotion, and other cues that are vital to ensuring the reporter is psychologically safe. Interviewees both hypothetically and anecdotally (see point #3) discussed this balance and often valued human followup even when they might prefer using a reporting form for the initial report:

I’m not sure that making it informal would solve that issue, but I think maybe having a liaison of some sort, a human being who’s there who’s like, “Hey, you filled out the form, great. Let’s talk about it, you know, what’s something that maybe you felt uncomfortable putting in the form. And here’s some clarification on how we make sure that retribution doesn’t happen, stuff like that. And maybe have on the page where code of conduct stuff, you know, like,”If you need to report it here, or talk to somebody, get in touch with this person.” That can be the liaison who is like, “Okay, well, you know, if you feel uncomfortable reporting it in a very official capacity, let’s talk about it.” Let’s figure out a solution that works for that individual. If they’re really, really that fearful of confronting whatever’s going on. It is important to listen to people who, you know, are unfortunately having to deal with reporting people breaking a code of conduct. And I think it is important to try to make that process as comfortable as possible.

No matter the process, it is essential that someone in the project is visibly accountable for handling reports and ensuring that the process works as intended. Often this can be more than one person, such as a community manager and an ombudsman. Listing these responsible parties on websites and info pages, as well as making them visible to the community at events and workshops, can help community members know who to go to when incidents arise.

Foster Healthy Collaborations within the Community

Interviewees appreciated the collaborative environment Astropy has fostered, comparing it to the sense of competition they observe or pariticpate in with other scientific domains:

And, you know, there’s so many science spaces where for whatever reason… I know the reason and I don’t agree with it, that collaboration is not something that’s truly encouraged. It’s more competition. And I understand that, you know, there’s limited money and that causes a lot of the competition. But I think for science to truly happen, you need collaboration and you need to say, “Oh, we have this core group of people, let’s bring people in, let’s continually expand.” And I mean, obviously you’re going to hit scope issue at some point. But, it is nice that it seems like there’s genuine efforts on Astropy’s part to do that.

Across all interviewees, though, there was an expressed desire to make these collaborations more diverse and inclusive. In some cases, this was geared toward intellectual diversity (see above); in others, interviewees believed there should be more effort put into international collaborations. Among the strongest perspectives was an interviewee who had experience making collaborations more inclusive, describing how they and their advisor continually sought to act with intent and invite underrepresented groups into their research:

We’re doing an REU, research experience in undergrad, where we bring in undergraduates to our our school and we’re like, “Hey do some stuff.” And now that I get to pick them with my advisor and go, “Okay which undergrad do we want?” And so I get a say in that, and that’s really cool. One of the things that we talk about all the time is, “Hey, let’s think about it, who really needs this more?” And, and you know, “Is it weird to be picking?” No, not really, because still systemically the odds are not stacked in the favor of the people who are underrepresented. And so if we do have an opportunity to extend that hand, then we should absolutely do so.”

Seeking out programs and universities to partner with could be a practical way to foster more diverse collaborations within Astropy and in the discipline more broadly. As one participant mentioned, historically-Black colleges and universities are not well-represented in Astropy; being intentional about making those collaborations happen may be beneficial to the project’s overall diversity and health.

Beyond research collaborations, experienced members of the Astropy community noted that in-person events are vital to building connections and being comfortable moving from user to active contributor. Travel expenses and visa issues, though, prevent many potential community members from ever being in the same room as their peers:

So definitely there’s inequities and I guess people, you know, being able to have access to things like computing resources and travel. Well, travel, yeah, because really being able to be in person helps a lot and it helped so much for me to be working with the Astropy people at the Python in Astronomy Conference. But I was, at the time I was working for [notable astronomy organization] and they paid for my trip, so I didn’t have any funding issues to go to it. Astropy contributor

Finally, participants expressed enthusiasm for the idea of creating and growing mentorship programs within Astropy. Even the most skilled developers can use guidance on navigating the more experience-based norms and practices of the community and broader OSS field. Mentorships, like all of the suggestions offered by the community, should be managed with intent and care. As one interviewee noted, it is important to ensure that these programs are sufficiently diverse so as to not recreate the same DEI issues communities in this domain have faced in the past; similarly, finding ways to not overburden underrepresented groups with these acts of service is essential:

I guess as long as you’re mindful of who gets to be the mentor and who gets to be the mentee so that it’s not, again, closing the loop in a way that we don’t want to, the same type of people being in the space, that’s a good idea … So have some, you know, obviously it’s not fair to put the burden of responsibility on underprivileged groups. astropy user

Mentorship programs designed with intent, according to one interviewees, should also be co-created between the mentor, mentee, and Astropy leadership.

So maybe a way there should be some built-in thing where it’s like, there’s some framework upon which the mentorship works and then the details get figured out basically between the mentor and the mentee to kind of customize the experience. So to say, “Hey, these are the things that everyone gets.” And then for the format part of it, “What works for both of us? What’s the way that this mentorship can function that would be most advantageous?” It’s almost like if you need accommodations in a course, you kind of have an individualized process for that, right? Graduate student astropy user