Roadmap 2023 - Community Input

[ceb8]

At the anual Astropy Coordination Meeting we will be updating the Astropy Roadmap, both to recognize what progress has been made and to add/revise goals as needed. In aide of this task wer are soliciting community input.

This issue will be open for commenting untill the start of the Astropy Coordination meeting on May 2.
The current Astropy Roadmap can be viewed here.

Please comment on this issue with the following information:

• Are you suggesting an addition or alteration or removal.
  • If addition: what?
  • If alteration: change in status only, or material change?
  • If removal: due to completion or another reason?
• Justification for suggestion

This community input will be used to draft the next iteration of the Roadmap, after which there will be another opportunity for community comment before official adoption.

[pllim]

xref #255

[pllim]

Improve support for using Astropy tools in high-performance machine learning and data analysis frameworks, such as on GPU systems

I don't think GPU is happening (too hardware specific) and haven't heard a lot of requests. Maybe replace with cloud computing?

[pllim]

The rest of the roadmap still seems relevant and sadly I don't think there has been much progress except for "compression handling" in FITS that is probably part of:

• Phase 3 Funding: Improving Compressed Image performance and Dask integration in io.fits. #275

[Cadair]

As well as better compression support in FITS, we have also started making progress on:

Improve and/or maintain interoperability with performant I/O file formats and libraries such as HDF5 and Dask.

At least as far as FITS goes: astropy/astropy#14452

[eteq]

Since it came up in #255 (comment) , worth at least thinking about whether we should add "try to expand involvement from people beyond US, Canada, and Europe". One could argue that falls in the existing community points, but still.

[kelle]

I'd like to work on the one bullet in Governance, Mgmt, and Personnel:

Develop a process for recruiting, selecting, and managing personnel to complete Project priorities that require external personnel.

In particular, I'd like to discuss the possibility of getting something more concrete on here about how we "managing" funded projects, not just ones that require external personnel.

[kelle]

Another thing to consider adding to the Roadmap: A revision/update to our Code of Conduct.

[hamogu]

I suggest to delete: "Implement robust performance benchmark reporting for pull requests."

I wonder if that's useful enough to justify the significant effort that would go into it (we had asv before, so we know that there is a significant workload just to keep such a system working, even after it's been implemented). Fundamentally, I think astropy might be so big, that a system that comprehensively benchmarks every part of the software is so much work (to set up, to maintain, and to run), it's not worth it. In the past, we have been pretty good to discuss performance on PRs where it's significant (and then you can benchmark just a few cases by hand that are most relevant to that particular PR) or to increase performance in sub-subsequent PRs if code was found to be too slow. We also already know some bottlenecks without need for further benchmarking; and we know that some speeds regressions are unavoidable (e.g. I remember we once had a function that run fast due to a bug [but I can't find the PR now as an example] - and there was no way to maintain that speed while also calculating correct results).

Would I like all parts of astropy to be faster? Sure. Would a "robust performance benchmark reporting" help? Probably. Do I think that "Implement robust performance benchmark reporting for pull requests" is worth the effort? No. Thus, I suggest to remove it from the roadmap.

Instead, we could try to reach out more regularly to users (and that includes all of us reading this!) to report where performance is an issue. For example, I personally use astropy mostly in interactive analysis scripts and few steps are done more than once. I spend way more time looking things up in the docs than running any code; so for me effort on more examples in the docs would yield much better time savings than speeding up astropy code.

[ceb8]

As the Coordination Meeting starts today, this issues has reached the end of it's time and I am closing it.