I am so conflicted on this! On the one hand, I fucking love it. Who hasn't experienced a backlog grooming session where you know it's impossible to reach the end of the backlog and you just sort of go along with the process of scraping from the top. There's definitely something miserable about that feeling.
On the other hand, it's not like the issues are gone, they're just tagged differently, and if everything is just tags and organization then why not go with the flow rather than exerting control in an attempt to achieve this pseudo-perfect empty issue list. There's gotta be benefit in keeping those notes around and visible, right? Sort of feels like deciding to throw something out of your house while deep in a cleaning spree even though your subconscious is (reasonably) nagging at you to hold onto it because you might need it in the future.
On the whole I think I'm for it, though, if anything just for the cathartic release and presumed re-invigoration towards new issues.
For a bit more context, the creator is doing a full rewrite.
I think it would probably have been cleaner to release the rewrite first, then close all the old issues as deprecated. You could isolate the rewrite branch issues with a version tag. Closing then while the new version isn't done may lead to contributers opening new issues on the old version without realizing that it is no longer supported.
But he's not just ignoring the issues and leaving problems in the code base, the entire project is getting a refresh.
I like it, it's the "put everything in a giant mailbag, label it, and dump it in a storage locker" approach. If the issues are still relevant, they can be resurfaced.
As a user, I find such a “cleanup” problematic if it means closing the issue. If the issue still exists in the product, it should remain open, for documentation, and so that users running into it can easily find it and add to it. I find it more honest if a project acknowledges that the issue exists by leaving it open.
As a developer, I’d rather use a filter to hide older non-critical issues, if I’m bothered about seeing the amount of issues.
Closed doesn't mean resolved, it means closed. Closing issues just shifts them to another tab, doesn't remove them entirely. What you propose, a filter to hide these, is exactly what has been done just through the official open/closed filters.
Closed doesn't have to mean resolved and the tickets would still be available either way. Closed is IMO ideal for these tickets as ultimately it means that they aren't being looked at.
I'm also conflicted. On one hand I reach for it every time I'm back in JavaScript land. On the other I think that slightly less than half of this library should be in the standard library for Christ's sake.
> This is, I think, the most common way for my bug reports to open source software projects to ever become closed. I report bugs; they go unread for a year, sometimes two; and then (surprise!) that module is rewritten from scratch—and the new maintainer can’t be bothered to check whether his new version has actually solved any of the known problems that existed in the previous version.
Wouldn’t it be more reasonable for projects with few maintainers, or even run solo, to have the individuals who reported a bug to each spend 10-15 minutes to validate if the issue still exists instead of the sole maintainer having to spend days if not weeks to do the validation?
Especially considering that the reporter is likely better attuned to observing the bug if it’s a bit more fickle or complex than the maintainer who may or may not be able to reproduce it on their end to begin with?
This might shift a bit when there’s a bigger team involved or when it’s a companion project to a commercial service.
What I tend to see with many (F)OSS projects is that very few are willing to roll up their sleeves while simultaneously spending significant amount of time to make it known how essential the project is to them, making demands and giving copious suggestions.
The vast majority just create new issues to make their wishlist known and/or supply a very vague bug report.
A subset of them might bother to submit a decent bug report and that’s about the extent their willingness to contribute goes.
Personally I don’t have the character to maintain a project simply due to not having the will to handle most of the comments I often see in a diplomatic manner.
That said, I do always try to track down the cause of an issue and submit a PR to fix the issue I’m reporting in an effort to do my part.
And a variation on that: the issue was reported against one major release, but a new major release (just incremental changes, not rewrite) is coming out, so close all issues against the old release, because the problem might no longer exist.
Make a PR with some tests that should pass, but are instead marked skipped. That way when the rebuild comes around, there's an easy path for the rebuild to see how it's doing, see if things are at all improved.
If you care about it, you should put a test on it.
He’s specifically talking about projects that just reimplement all the bugs from scratch in a new, incompatible code base. Such teams certainly don’t port passing unit tests, let alone skipped ones!
I’m probably not enough of an expert on their code to write that unit test. And I don’t have much faith in a team who blindly closes bugs to unskip tests and upgrade them to the new API.
This is bullshit. I've submitted hundreds of bugs to open source projects. This situation happens but it is extremely rare. Much less common than the bug being fixed, ignored, or closed by bloody stalebot.
John-David Dalton, the lodash author, wrote [this last year][1]:
> For the lodash rewrite I’m declaring tech debt bankruptcy. Starting from scratch with TypeScript and Rollup. No FP wrappers. That fad is over. RIP your co-workers if you introduced that headache into your codebase. Definitely not team or human friendly.
Don’t know if he’s sticking to this 100% but seems pretty close.
> That fad is over. RIP your co-workers if you introduced that headache into your codebase. Definitely not team or human friendly.
Is he not the original author?
This is phrased like someone else added the complexity he's decrying. If he's the one that introduced it then instead of talking about it as an introspective or something that they learned from, he's talking about it like he develops projects according to fads and that's it's time to move on to the next one now that this one has ended.
lodash/fp is an optional distribution of lodash that did what the core library did, but did so in a more flexible, powerful, composeable way that makes it easier to construct powerful functions. it was separate from the core, but based heavily on it. https://github.com/lodash/lodash/wiki/FP-Guide
at the time, nothing was settled. we were in a pioneering mode of building; we didn't know what people would find useful or what the future would hold. there were a lot of different ideas floating around, and lodash was trying to stay the same while also offer a port to this barely-subtly-different paradigm, to see what value might be found there. saying that "introduced" it feels like a crude reduction to me; he allowed people the option they asked for.
i personally think fp - in particular - "pointsfree" fp - has huge down sides to being understandable. but fp in general also is a much more succinct and capable way of expressing things, and multiple times a week i run into situations where auto-currying or reverse args would make the code i write much cleaner & not damage code comprehension.
rather than call fp a fad, & insult the author for ever letting it in, i think there's room to say that it's sad that js had to stay on the lowest common denominator. the future was unable to be changed, the old ways stuck. we lost some really good opportunity & capabilities. that said, i still think the pointsfree style is hugely damaging & responsible for greatly reducing the chances we had to improve. instead, we're not "moving on", we're going back to square 1, to the only thing we've ever known or done. that makes me a little sad, to have the pioneers pack up & move back into the city.
what really scares me is the attitude that every failed pioneering expedition is a "fad" and that we shouldn't ever try things. lodash-fp was a harmless small token offering to possibility, and should be respected, whatever your view on fp.
One of the big issues with the fp javascript trend was that coding patterns which work well in languages like closure or Haskell had a kind of "let's shoehorn this into js". There was a tonne of blogspot on "how to write functional javascript" that followed this pattern of currying all the time in a language where it just doesn't result in particularly readable code. I'm glad it's falling out of fashion.
IME there was a fad (that thankfully never picked up) where people were talking about making giant unreable piles of curry functions and calling it finally, some good functional js.
They looked like write-only code to me and at high-risk of assaulting the GC (aka slower than lodash).
Nothing really but besides it not working with typings too well it’s just quite uncommon. I love it personally but strictly use it on personal projects, this is really not something one should introduce to a project that multiple people are working on.
Looking at the first few PRs in the list, you can see things like:
- Adding a word in a comment.
- Adding config files to self-promote dev services.
- Switching from using var to let.
- Changing well-established behaviours of core functions.
- Removing semicolons.
- ...
I'm sure most of those were opened with good intentions of improving the library, but at some point for the maintainer they just become spam (or worse, a growing burden that makes you feel guiltier and guiltier for not giving it attention).
Celebrities hire bodyguards and fly first class (or private) to avoid the constant stream of attention and keep sane. I wonder what measures could be taken by celebrity OSS projects.
Personally as an open source maintainer I like the typo/wording fixes/automated refactor PRs the most. There's almost no effort needed from my side to review them, so I almost always merge those very quickly. It's the PRs that implement huge are the ones that you take the most time reviewing/discussing, and thus those are the ones I put off looking closely at.
The submitter creating multiple var -> let PRs (one PR per file...), was also doing this, including the one file per PR, in other projects, and would've broken some of their legacy IE(!) users.
They can keep padding their resume if it means little fixes actually happen. Even typos and little translations, they affect the general reputability of the software. Sounds like a fair trade, especially as most hiring companies can just look at PRs and see what was actually changed very easily.
I was starting to get excited about migrating my packages to Bun, but hesitating because I was afraid of compatibility or whether Bun is really here to stay or not - I have been slightly burnt by "Modern Yarn"; but honestly, seeing lodash make the leap makes me want to consider it more seriously now.
I’m a yarn burn victim as well, and it has made me a lot more apprehensive about fundamental decisions like these. They seem so promising and your research seems to check all/most of the boxes… Then you get Yarn 2/3
I resist telling open source developers how to run their projects, because I am one myself, and get annoyed when other people do that to me.
But oof, if I were a user who spent some non-trivial time filing an issue & helping troubleshoot, or working on a fix or new feature and submitting a pull request, I'd be feeling pretty discouraged right now.
In my opinion, if a bug report is crap, it is perfectly acceptable to politely say so with a canned response and then close the issue a week later if better information is not forthcoming. Declaring 'issue bankruptcy' shows that you do not care about your users time and tells me that I should not trust your project.
Issue bankruptcy is real. Speaking from personal experience, at some point maintaining OSS is incompatible with living in the real world. The work is free and often thankless (but not always). The problems are complex and compete with real world responsibilities, like work, family, rest. People get pissy and regularly want to argue with you or read the docs for them. It also carries enormous responsibility if your OSS is popular.
I am anticipating a huge collapse in the OSS ecosystem as the people who drive them say "fuck it" and walk away for more important things.
That I can understand. These days I'm almost starting to think of nontrivial personal projects as more an addiction or self harm than real projects.
The OSS ecosystem is insanely inefficient though. There's lodash, underscore, and plenty of others. They don't all need to exist. There's also lots of libraries that only do one thing, which are mostly a subset of something like this.
Most of this stuff will be used with minifiers and tree shaking, and unused features will be removed, we don't need lightweight libraries when the heavy ones are easily optimized and mostly made of separate parts, so the dev effort mostly scales linearly.
I think OSS has plenty of manpower, even if everyone decided to only spend a quarter of the time they currently spend, if it weren't for the fact programmers like elegance and simplicity more than anything, and constantly want to rewrite to make things just a little bit better.
Readit News
On the other hand, it's not like the issues are gone, they're just tagged differently, and if everything is just tags and organization then why not go with the flow rather than exerting control in an attempt to achieve this pseudo-perfect empty issue list. There's gotta be benefit in keeping those notes around and visible, right? Sort of feels like deciding to throw something out of your house while deep in a cleaning spree even though your subconscious is (reasonably) nagging at you to hold onto it because you might need it in the future.
On the whole I think I'm for it, though, if anything just for the cathartic release and presumed re-invigoration towards new issues.
I think it would probably have been cleaner to release the rewrite first, then close all the old issues as deprecated. You could isolate the rewrite branch issues with a version tag. Closing then while the new version isn't done may lead to contributers opening new issues on the old version without realizing that it is no longer supported.
But he's not just ignoring the issues and leaving problems in the code base, the entire project is getting a refresh.
https://twitter.com/jdalton/status/1571863497969119238
Here is an idea: write the damn thing under a new name and abandon /offer a path to migrate.
Can someone comment on this from the linked tweet? I haven’t been a js dev in a long time. Is functional style dead?
As a developer, I’d rather use a filter to hide older non-critical issues, if I’m bothered about seeing the amount of issues.
> This is, I think, the most common way for my bug reports to open source software projects to ever become closed. I report bugs; they go unread for a year, sometimes two; and then (surprise!) that module is rewritten from scratch—and the new maintainer can’t be bothered to check whether his new version has actually solved any of the known problems that existed in the previous version.
Especially considering that the reporter is likely better attuned to observing the bug if it’s a bit more fickle or complex than the maintainer who may or may not be able to reproduce it on their end to begin with?
This might shift a bit when there’s a bigger team involved or when it’s a companion project to a commercial service.
What I tend to see with many (F)OSS projects is that very few are willing to roll up their sleeves while simultaneously spending significant amount of time to make it known how essential the project is to them, making demands and giving copious suggestions.
The vast majority just create new issues to make their wishlist known and/or supply a very vague bug report.
A subset of them might bother to submit a decent bug report and that’s about the extent their willingness to contribute goes.
Personally I don’t have the character to maintain a project simply due to not having the will to handle most of the comments I often see in a diplomatic manner.
That said, I do always try to track down the cause of an issue and submit a PR to fix the issue I’m reporting in an effort to do my part.
> report issue
> issue is automatically closed 6 months later due to lack of activity
...with absolutely no change to or comment on the issue.
If you care about it, you should put a test on it.
He’s specifically talking about projects that just reimplement all the bugs from scratch in a new, incompatible code base. Such teams certainly don’t port passing unit tests, let alone skipped ones!
For the full article, search for: jwz cadt
> For the lodash rewrite I’m declaring tech debt bankruptcy. Starting from scratch with TypeScript and Rollup. No FP wrappers. That fad is over. RIP your co-workers if you introduced that headache into your codebase. Definitely not team or human friendly.
Don’t know if he’s sticking to this 100% but seems pretty close.
[1]: https://twitter.com/jdalton/status/1571863497969119238
Is he not the original author?
This is phrased like someone else added the complexity he's decrying. If he's the one that introduced it then instead of talking about it as an introspective or something that they learned from, he's talking about it like he develops projects according to fads and that's it's time to move on to the next one now that this one has ended.
at the time, nothing was settled. we were in a pioneering mode of building; we didn't know what people would find useful or what the future would hold. there were a lot of different ideas floating around, and lodash was trying to stay the same while also offer a port to this barely-subtly-different paradigm, to see what value might be found there. saying that "introduced" it feels like a crude reduction to me; he allowed people the option they asked for.
i personally think fp - in particular - "pointsfree" fp - has huge down sides to being understandable. but fp in general also is a much more succinct and capable way of expressing things, and multiple times a week i run into situations where auto-currying or reverse args would make the code i write much cleaner & not damage code comprehension.
rather than call fp a fad, & insult the author for ever letting it in, i think there's room to say that it's sad that js had to stay on the lowest common denominator. the future was unable to be changed, the old ways stuck. we lost some really good opportunity & capabilities. that said, i still think the pointsfree style is hugely damaging & responsible for greatly reducing the chances we had to improve. instead, we're not "moving on", we're going back to square 1, to the only thing we've ever known or done. that makes me a little sad, to have the pioneers pack up & move back into the city.
what really scares me is the attitude that every failed pioneering expedition is a "fad" and that we shouldn't ever try things. lodash-fp was a harmless small token offering to possibility, and should be respected, whatever your view on fp.
https://twitter.com/jdalton/status/1571870137690591236
They looked like write-only code to me and at high-risk of assaulting the GC (aka slower than lodash).
Looking at the first few PRs in the list, you can see things like:
- Adding a word in a comment.
- Adding config files to self-promote dev services.
- Switching from using var to let.
- Changing well-established behaviours of core functions.
- Removing semicolons.
- ...
I'm sure most of those were opened with good intentions of improving the library, but at some point for the maintainer they just become spam (or worse, a growing burden that makes you feel guiltier and guiltier for not giving it attention).
Celebrities hire bodyguards and fly first class (or private) to avoid the constant stream of attention and keep sane. I wonder what measures could be taken by celebrity OSS projects.
https://github.com/MithrilJS/mithril.js/pull/2880#pullreques...
That's a particularly obnoxious bot. Didnt even follow their workflow...
I suppose it depends on scale, and the team size.
And Github issues are 80% support forums, 20% bugs, 5% of the bugs come with reproduction test cases, if you're lucky.
One particular GH user submitted multiple PRs doing only that. Across multiple JS projects...
...feels like GH profile padding.
I was starting to get excited about migrating my packages to Bun, but hesitating because I was afraid of compatibility or whether Bun is really here to stay or not - I have been slightly burnt by "Modern Yarn"; but honestly, seeing lodash make the leap makes me want to consider it more seriously now.
But oof, if I were a user who spent some non-trivial time filing an issue & helping troubleshoot, or working on a fix or new feature and submitting a pull request, I'd be feeling pretty discouraged right now.
No one wants to loose those so it is sad for both sides.
Same for 325 PRs: https://github.com/lodash/lodash/pulls?q=is%3Apr+is%3Aclosed...
I am anticipating a huge collapse in the OSS ecosystem as the people who drive them say "fuck it" and walk away for more important things.
The OSS ecosystem is insanely inefficient though. There's lodash, underscore, and plenty of others. They don't all need to exist. There's also lots of libraries that only do one thing, which are mostly a subset of something like this.
Most of this stuff will be used with minifiers and tree shaking, and unused features will be removed, we don't need lightweight libraries when the heavy ones are easily optimized and mostly made of separate parts, so the dev effort mostly scales linearly.
I think OSS has plenty of manpower, even if everyone decided to only spend a quarter of the time they currently spend, if it weren't for the fact programmers like elegance and simplicity more than anything, and constantly want to rewrite to make things just a little bit better.