You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
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.
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.
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.
Activity
pllim commentedon Mar 6, 2023
xref #255
pllim commentedon Mar 10, 2023
I don't think GPU is happening (too hardware specific) and haven't heard a lot of requests. Maybe replace with cloud computing?
pllim commentedon Mar 10, 2023
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:
io.fits. #275Cadair commentedon Mar 10, 2023
As well as better compression support in FITS, we have also started making progress on:
At least as far as FITS goes: astropy/astropy#14452
eteq commentedon Apr 3, 2023
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 commentedon Apr 3, 2023
I'd like to work on the one bullet in Governance, Mgmt, and 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 commentedon Apr 3, 2023
Another thing to consider adding to the Roadmap: A revision/update to our Code of Conduct.
hamogu commentedon Apr 26, 2023
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 commentedon May 2, 2023
As the Coordination Meeting starts today, this issues has reached the end of it's time and I am closing it.