With this post, I’m accepting a nomination for the Coco election.
I’ve been part of astropy almost since the very beginning: I supported Tom Aldcroft in writing “asciitable” which eventually became astropy.io.ascii and I’m still a maintainer for this sub-package. I’ve also mentored for GSOC several times, was part of the team that coordinated the second astropy paper, and I’m currently on the Astropy finance committee and one of the affiliated package editors. Over the years, I’ve contributed to a number of other parts of the Astropy ecosystem (e.g. other code astropy modules, tutorials, some of the coordinated packages).
I see two large challenges for Astropy in the next few years:
-
Complexity of the core package. Over the years, getting started has become a lot more complicated as standards for pep8, pytest, sphinx are climbing and more and more tools are needed to really get everything to a state that is considered “acceptable for review” (tox, pylint, flake8,…). I believe that’s a bottleneck because it makes me uncomfortable to review things in the core package - and I’ve been with astropy for ~10 years-, so it’s a large responsibility for current contributors to become maintainers. At the same time, it’s difficult to get new contributors because of this hurdle. Please sometimes say that maintainers are the bottleneck, but historically, most of our current maintainers started as contributors for he core package, so I’m afraid that this can make the problem worse long-term. At the same time, there is a good reason for this complexity - its helps us writing high-quality code and keeps the burden on current maintainers and the infrastructure team manageable. I don’t think there is golden bullet, but careful consideration of weighing docs, mentorship, community works and other areas.
-
The growths of the Astropy ecosystem makes people specialize more. Some write tutorials, other only work on the core package. In the early days of astropy everyone did everything, so everybody knew everything. Now, as the project grows, that’s no longer the case. Keeping a large community of volunteers working in separate parts together is a challenge. Again, there is no golden bullet, but a need for careful moderation to balance different needs (e.g. users may want LTS versions run forever, but that’s difficult for the release team; tutorials work best if all packages develop in sync, but coordinated and affiliated package develop and release on different schedules).
Based on my experience in several areas of astropy and previous experience in leadership for a charity with a large and very inhomogenoues group of volunteers, I believe that I can contribute to the development of Astropy as a Coco member at this stage. However, I do have a day job and a family - if I’m elected into the Coco, I plan to (slowly) pass on other roles in the Astropy project that I currently fill (finance committee, affiliated package editor) to others.