We need a GitHub issue bot that responds to comments about project abandonment/death with this article.
@linux_mclinuxface i saw quite a lot of these unhelpful comments for the jq project that was inactive for some time. me and a couple of randos kept on helping with issues and even did feature and bugfix prs. we were close to forking but then the original author showed up and gave us admin rights. we coordinated, fix broken ci/cd, merged lots of prs and did a new release. now the project is very active again
@linux_mclinuxface The other thing is that sometimes a simple project can just be ... Done.
I have at least one repo off the top of my head (constraint solver for picking resistors for a voltage divider given min/max allowed values, division ratio, and a list of component values available in inventory) that meets my needs and I haven't changed in quite some time.
It's not abandoned, i use it on a regular basis. I just don't need to change it because it does what it needs to!
@azonenberg oh yes. This is a thing. I saw it on some thin libraries I worked on: they did what they needed to do, the API was stable. No need for an update.
@azonenberg @linux_mclinuxface that reminds me that I should adapt my LM317 calculator page into a separate calculator page just for resistive dividers...
@gsuberland @linux_mclinuxface Mine is specifically focused on constraint based.
So for example "how do i get as close as possible to 12.34x division ratio given only the values i have on the shelf, total string resistance no more than 1M, and lower resistor at least 10K"
@azonenberg @linux_mclinuxface that's exactly what I was thinking. my LM317 calculator looks for the best resistance values to produce a given output voltage, and has similar constraints in terms of min/max and discrete resistance values that can be used (right now that's just E* value sets, but could trivially be adapted to take custom lists). it would be pretty easy for me to turn it into a generic divider calculator that tells you the best options for given constraints.
@linux_mclinuxface This is great. Although it did make me think that I want to add some sort of setting maintenance expectations section to the top of my readmes in future. Sometimes I'd want to know whether a project is still maintained mostly because I want to respect the author and not open a public fork, potentially creating confusion, willy-nilly.
@wjohnston also, think about your issue template as a place to set expectations.
@linux_mclinuxface Ooo… I like that a lot.
@wjohnston if you want to be passive aggressive you could have a GitHub Action that updates the issue template with something like “Yes, I know there are 456 issues open, we’re working on them. Average time to close is 4 months, 2 days. If want the time will go down please read our contributing.md”