6  Improving Participation

6.1 Change about Astropy

We asked respondents what they would change about Astropy, leaving the question open-ended so as to enable comments on technical, social, or other issues faced by community members. Newcomer issues were a major theme, with several respondents mentioning the desire to have easier entry points for using or contributing to Astropy. Other themes included respondents seeking improvements to the affiliated package and PR processes, expressing desired support for using Astropy in educational settings, and suggesting revisions to community priorities.

6.1.1 Easier Contributions

Respondents described a desire to make contributions to the community easier. In particular, both newcomers and returing community members mentioned not knowing how to make a contribution and seeking more learning opportunities.

A "one stop shop" or "single pager" for new people t learn how astropy works and how to get involved. Ideas such as the first projects tags on github should continue.

I think the bar for new contributors is still very high. I think ways to make it easier to contribute, either to the core astropy package or to affiliated packages, would be helpful. Some more explanation on new code infrastructure pieces like ruff, black, and type annotations would be helpful

I would like to be able to engage again but I do not know where.

I would like to contribute code or documentation, but I find it hard to understand what issues are open, a priority, and something I know how to contribute to.

Make it easier to contribute

6.1.2 Development of Affiliated Packages

The Astropy community seems to value affiliated packages both for their utility in practice and the experience of developing affiliated packages alongside the community’s experts. Still, respondents had several ideas for improvements in affiliated package development and standardization.

I most want to see us introduce an incubator pathway for developing new tools. This serves a dual-purpose of allowing for nimble creation of new software, as well as providing a platform for drawing-in folks from the "new astropy contributor" phase to the long-term contributor phase.

We see that hack days can kick-start really useful tools on timescales of days, and full-time positions (like those belonging to folks at STScI) can construct sustainable tools on timescales of months or more. GSoC can do something intermediate, but those positions are focused more on mentorship. Of course, there are plenty tasks to accomplish on the to-do list already. But I worry, for example, that small grants to "explore units compatibility with dask" might be *too* small. Working a few percent over a year might be less efficient than six focused months at a much higher level.

I know we don't have money to do this right now, but what if we competitively award grants to post-PhD folks to seed projects that could become affiliated packages? We could provide check-ins with liaisons from astropy who work to preserve/enforce interoperability within the ecosystem. And we'd help foster the folks at upper end of the user-to-developer pipeline.

6.1.3 Standards for Affiliated Packages

Several respondents were interested in improved and more clear documentation and standards.

Better documentation for associated / affiliated projects.

Clearer documentation (including tutorials) about how to convert an existing package to an Astropy Affiliated package (without assuming the person who wants to do this is already an Astropy developer).

More standardization and quality control

6.1.4 Support for Non-Astropy Software

Respondents reported some issues with interoperability, offering feedback and ideas around getting support for how to integrate astropy in less-compatible workflows. These community members want to use astropy in more complex environments with other software and “new paradigms” in computing.

expanded emphasis on astronomical software in general. python is a good solution for many use cases, but not always the optimal one.

I’d like to see some cross package tutorials, particularly with widely used iterative techniques such as MCMC. I know how to use these types of packages separately, but integrating them correctly is something I struggle with. Particularly with Astropy methods such as the ones in cosmology. The tutorials section is great already, it would just be helpful to include some iterating techniques and how to successfully use them with astropy methods.

More focus on evolving code to support new paradigms for high-performance computing, like JAX.

6.1.5 Code Quality and Maintenance

There were some concerns about project maintainers prioritizing quality and purity of code over more practical concerns. One respondent suggested that the project assign more people the role of “maintainer”. It is clear that community members value code quality and stability of code that comes from the community, but understand the labor demands of these successes.

I perceive the community to be snobbish about code quality / purity, while at the same time undermining itself with things like cosmetic changes to API options that breaks my code whenever I upgrade to the latest version.

More maintainers, to lighten the load (astropy core package, but probably true for other parts too)

Not too much, really. It would be nice to have more highly-qualified developers with free time to dedicate to open issues.

6.1.6 Happy with the current state or personal challenges

Several respondents were comfortable with the way the community is at the moment, while some thought there would be some ways to improve involvement and kindness.

I know it's not helpful, but I really like the community right now and I don't have any ideas at the moment about how it could be improved.

I like things the way they are.

I would like to find time to be more involved.

Replace Astronomers with kinder and more normal people.

6.1.7 More Support for Education

One respondent expressed a need for a more full curriculum shared by the Astropy community that can help teach astronomy programming with more structure.

Having more tutorials and perhaps a full curriculum available for instructors to use/adapt for classes would help greatly. Astronomy programming is still taught somewhat ad-hoc at least at my institution.

6.1.8 Support for Early Career Astronomers

Similar to the education support, there was a clear expression by some respondents of a need for more formal ways of learning about and getting credit for high-quality software development.

I hope we are teaching young astronomers very early how to build, maintain, and contribute code. It was very hard for me to learn at a later career stage.

Much of it is built by early career researchers who deserve better rewards! But that's not so much a problem in the Astropy community but rather in academia as a whole.

6.1.9 Networking and Jobs

One respondent was interested in seeing more career development opportunities or project collaboration opportunities as part of the community.

One thing I would like to suggest is showing related job or project opportunities

6.1.10 Faster Response Times

One respondent was concerned about how some GitHub Issues linger unaddressed by the community.

Better responses to issues raised (often just ignored, even if they are acknowledged issues)

6.1.11 PR Process

There was feedback about the challenges of submitting PRs and the number of comments and changes requested for PRs.

easier PRs (often excessive commenting and requested changes by dev, making the experience very onerous)

6.2 Barriers to Contribution

We asked participants specifically about barriers they had to using or contributing to the Astropy project and astropy software. These barriers included technical, community-related, and broader systemic factors, often related to how software development is (not) credited in academic communities.

Some areas to explore changes in Astropy’s approaches to encourging and managing contribution include: evaluating how first contributions take place, identifying when, how, and why potential contributors bow out, and what can be done to remove barriers to the first contribution made in the community.

6.2.1 Git is Intimidating

Looking at the version control software Git, some of the responses talked about how Git itself can be a barrier as it can be intimidating and require some skills that not all beginners have.

Making a pull request is intimidating, since I usually don't have code that is modular or generalizable enough to become a new feature

yes, contributing a PR to astropy requires a fairly advanced level of git and github knowledge. this has improved some over the years, but one still has to be aware of what "rebase" and "squash" mean.

see previous answer about being more welcoming of non-expert contributions to github issues and code.

6.2.2 Complexity and Technical Skill

Many responses centred around the sheer complexity of the Astropy software stack, and how that itself was a barrier to entry. Others noted that tools and procedures to make developer’s lives better are often not always better for the newcomer.

Astropy is huge. The project is very daunting to find a place to contribute.

Contributing code to Astropy takes a relatively high degree of technical skill. That makes it more accessible to people who have the free time or resources to acquire that skill.

I haven't tried very hard, but it is sometimes staggering how much complexity goes into contributing to Astropy. I gather that the main dev team is aware of this and is thoughtful about improving accessibility.

Hard to know who is responsible for what parts of the codebase and which parts are "ok" to touch vs "need to be left like that" for... reasons.

We could lower the bar for contributing code by being careful of the barriers that the Python linter "ruff" has introduced.

6.2.3 Knowing Where to Start

A few responses talked about not knowing where to start and how to bring their skills and expertise into the community. It is clear these respondents would like to find ways to contribute, but might need some support in order to be able to do so.

Knowing where to start contributing!

Lately (last <3 years), it's been difficult to keep up with deprecations & CI updates. I'm constantly being asked to learn new software practices that are not relevant for the software tools themselves. This is fine, I just need help keeping up.

I’m a rubbish coder!

6.2.4 Value of the Work to One’s Career

A few responses focused on how their own jobs or careers did not value contribution to open source. This is a common problem in many academic open source domains, and is worth discussing as a community to better understand how the reward structures in Astronomy may not be aligned with work that needs to be done as a broader OSS community.

It's not counted as valuable work.

My biggest barrier has been the expectation that the longevity of my career as an astronomer would be at risk if I contributed to astropy as frequently as I wanted. Few things in life are zero-sum, but there's no flexibility on the finite 24 hours in a day. I was cautious about spending time on work in the astropy ecosystem that wouldn't produce a first author paper.

6.2.5 Community

Community members seemed to be looking for more interactive ways to get-to-know others in the community. Some felt like discussions they had been privy to moved to some other platform they weren’t aware of at a certain point in time. Others mentioned that being optically focused, they felt a excluded as a radio astronomer.

As mentioned before the main barrier that I found was to find the community discussion in places where I participate. I tend to avoid privative platforms and I could see how participation in, for example, the email list faded with time. At some point I did not know if people moved somewhere else or something else was happening.

Sometimes its hard to line up terminology from the radio astronomy community with astropy terminology. It feels very focused on optical astronomy.

I am not been able to get involved with the astropy project due to lack of interaction with the community. If there's any way to interact with the community, I believe I and many more people will be able to contribute

6.2.6 Documentation

Documentation was observed to be not very accessible to one respondent. Some work to gather user feedback from documentation users might help to develop some guidelines and work sprints on improving documentation in ways that it can become more useful to newcomers.

Minimal (and somewhat outdated) documentation for creating an Astropy affiliated package; the assumption seemed to be that people doing this would already be very familiar with the Astropy package architecture and procedures, and so no explanation of what anything in the (default) package was for seemed to exist. Consequently, I gave up my attempt to create an affiliated package.

6.2.7 No problems

A few responses have said that their first contributions went very well, and their interactions with maintainers was “lovely”.

No, my first contribution was last year and I've done a few more since that. Loved all the interactions with the maintainers, they're lovely.

No, to the contrary: the friendly response to my first issues/PRs is a major reason I got hooked.