Cycle 4 Funding: On-going code quality improvements (Vaher)

[eerovaher]

I am submitting a draft of my Cycle 4 funding request. The funding would allow me to continue my work on improving astropy code quality. This includes finding and removing obsolete code from astropy, but also refactoring code that has been marked as likely to be overly complex by some of the Ruff code quality rules.

[kelle]

Just want to confirm, this is for you as an independent contractor, correct?

[eerovaher]

Yes, I would be an independent contractor.

[eteq]

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

[pllim]

I appreciate removing dead code, increasing test coverage, and technical reviews. But I don't know how I feel about ruff as I think some core maintainers are getting burned out by the constant style changes without functional changes (#349 (comment)).

[eerovaher]

My priority would be to work on coordinates, so what really matters is if @mhvk is willing to keep reviewing pull requests like the ones I've been making.

[mhvk]

Yes, happy to keep reviewing the good simplifications/dead code removal/etc.! Especially since it is usually so well organized, thanks!

[bsipocz]

Like Pey Lian, I'm +1 for the dead code parts of this proposal, but -1 on adding more ruff rules and code refactorings as it was a really painful experience with big PRs.

But overall +100 to have a contract to @eerovaher for his ongoing maintainer efforts

[eerovaher]

I made a remark about refactoring code to enforce Ruff code quality rules, but I did not specify what does that actually mean and this seems to have caused some confusion. The rules I had in mind are rules like C901 (complex-structure), PLR0911 (too-many-return-statements), PLR0912 (too-many-branches) or PLR0915 (too-many-statements). Addressing such rules means a substantial manual refactoring of a small number of functions at a time (one or maybe a couple per pull request), not automatically making small changes to a large number of functions throughout astropy. I've opened a number of such pull request already and @mhvk has been reviewing them, so when he says that they have been good simplifications and he is happy to review them then he knows what he is talking about.

I do not intend to open pull requests that would apply automatic updates to a large number of functions, with the exception that if a monthly pre-commit update causes Ruff to make many changes to astropy then I might manually intervene, like I've done the last two times.

[AnaGabela]

Hi Eero,

I'm writing on behalf of Astropy's Finance Committee regarding the outcome of your recent Funding Request.

We are sorry to report that your proposal could not be funded during this funding Cycle. We will be closing the FR as a result.

While the community vote was the primary driver of this, it is important to note that this likely does not reflect anything about you as a member of the Astropy Community. Rather, it reflects the specific balance of projects proposed this cycle, the available funds, and the priorities of this cycle’s funding sources relative to others.

We encourage you to read feedback in the thread above or other feedback you might have received via other means, and consider an FR for the next cycle with whatever modifications you think would help. You are also welcome to reach out to the Finance Committee for feedback if you would like.

Ana- on behalf of the Astropy Finance Committee