Cycle 5: Array API in ccdproc and NDData and work on astrowidgets

[mwcraig]

No description provided.

[kelle]

Are the funds requested in addition to the amount remaining in your Cycle 4 project? or an updated estimate for the cost of the work during 2026?

[mwcraig]

@kelle -- this is the combination of the funds that have not been invoiced from the cycle 4 proposal (that work has largely been done but I was asked to hold off on invoicing until 2026), and the additional $4,125 proposed in this comment.

[kelle]

Just to be super clear: you only need $9,487.50 and not $ 11,287.50? The updated cost is $9,487.50?

[mwcraig]

I have tripled checked just to be sure, but the updated cost is **$9,487.50$$ as stated in this request.

[mwcraig]

One note about the relationship of this proposal to #483. While I have some changes to do in astropy.nddata to get ccdproc as close as possible to implementing the Python Array API making it fully compatible will be far easier if Quantity supports the Array API. I would not go so far as to say that the Array API-related work in this proposal cannot proceed without #483 I think it is fair to say that the work will be much easier once Quantity has been revised.

(pinging @mhvk just so he is aware of the connection)

[mhvk]

@mwcraig - thanks. Things like yours were indeed what I had in mind when I wrote that making quantity array-api compatible was likely required for other parts of astropy. I would obviously be happy to coordinate!

[AnaGabela]

Please react to this comment to vote on this proposal (👍, 👎, or no reaction for +0).

[bsipocz]

I wished this proposal was cut into half, one for the array API part, and the other for astrowidgets.

[neutrinoceros]

Me too.

[mwcraig]

@bsipocz @neutrinoceros -- It is too late for me to update the proposal, but if this was funded at the lowest end of the range then the astrowidgets work could be limited to what has already been done, and work on array API prioritizied.

[kelle]

The Cycle 5 funding request process has been hugely successful! On the downside, that means our funds are severely oversubscribed. Even after the Finance Committee and SPOC have taken into consideration community feedback/voting and alignment with the roadmap, there are still more funding requests than we can afford in 2026.

We would like to stretch the budget as far as possible, and to fund as many activities as possible, while making sure the Project remains volunteer-driven. Hence, we would like to know if this project will still meet its deliverables if your minimum budget is reduced by 25%, 50%, or 100%. Or if there’s some other minimum, feel free to specify that instead.

As a reminder, there will be more funding for 2027 and we expect the Cycle 6 call for 2027 funding requests to begin in the Fall of 2026.

Thank you for your engagement and understanding as we continue to optimize our funding and budgeting processes and the balance of volunteer vs funded work!

(@mwcraig )

[mwcraig]

I want to clarify something that I maybe have not been explicit about: most of the work at the minimum budget level for this proposal has already been done as part of this approved proposal for Cycle 4. I was asked to hold off on invoicing for that work until 2026 because of the cashflow issue the project had because of the delay in obtaining the new ROSEZS funding.

So on the one hand I guess I would meet all of the deliverables I outlined in the minimum budget scenario here even if the budget was reduced 100%, but on the other hand I'd feel a little bitter about that....