Any issue was immediately closed and only closed issues would be reopened if enough people gave said closed issue enough thumbs up (and "enough" wasn't even defined). And of course, this process wasn't explained anywhere except in replies to closed issues.
The obvious problem with this was that no issues were ever acted upon ever because no one ever looked at closed issues, because why would they?
I had created a proposal for a new function to be added that was and still is sorely missing. After it was closed and a long discussion ensued between many devs, I gave up and a year later I simply replied that I retract the proposal due to the ridiculous policy of actively being hostile to users. The maintainer deleted the whole issue and along with it all proof of their hostility and hypocrisy.
It was then that I decided I would boycott lodash and simply use better libraries in my projects now like Ramda, which is actually OSS. Looks like lodash is now no longer maintained and has hundreds of tickets open after the hostile maintainer (and it's not hard to guess who from looking at the commit counts) appears to have stopped maintaining it.
Funny how that works, closing tickets constantly ensures no one will want to help, and then the maintainers feel overwhelmed because they are doing it alone.
Basically closing issues is an awful practice that helps no one, as you say.
"Simple JS can't have unexpected security/performance pitfalls".
Hah.
https://www.cvedetails.com/vulnerability-list.php?vendor_id=...
I know this isn't directly related, however one of the vulnerabilities is prototype pollution [0], a deceptively simple technique that I think so many apps are vulnerable to. It goes like the following:
- Get an application to serialize or take `__proto__`, `constructor` or `prototype` as an input so it's a key on a JS Object
- Serialize its value to something nasty, like `'{"auth": {"name": "user", "password": "pwd"}, "message": { "text": "", "__proto__": {"canDelete": true}}}'` [1]
This high jacks the prototype of the object and adding those specified properties. If you do things like deep merging of objects on data, you are susceptible to this without the proper guards in hydration / rehydration. The mitigation is simple: don't allow objects to have `constructor`, `prototype`, or `__proto__`. You can delete them by customizing JSON.parse (by passing a reviver [2]) or using something like `mergeWith` to skip these keys
A similar vulnerability exists with `constructor` and `prototype` as well [3]
[0]: https://portswigger.net/daily-swig/prototype-pollution-the-d...
[1]: https://github.com/Kirill89/prototype-pollution-explained
[2]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[3]: https://shieldfy.io/security-wiki/prototype-pollution/introd...
A prototype can only be modified by code that is actually being run. If you can get someone else's application to run code under your control, you've already won.
It requires some knowledge of the inner workings of the system (in the above, you'd have to know that the auth provider checks for a cached `isAdmin` prop on some object before executing the authentication routine to generate it). But if your system is designed to only be secure if no-one knows the inner workings, you're probably owned anyways.
https://archive.is/l4svG (jwz link, so archive.is)
Lodash as an npm module is out of control, file-size wise, and I'm not sure I'm really getting anything for it, other than once a year having to make sure we don't have ten copies of it that can't be deduped (Currently it's occupying 29MB of disk space on my production machines)
As I remember it, Lodash biggest difference was its modular approach also, not all about performance. Lodash also addressed some inconsistencies in Underscore.js.
For many others, the OP's use is common and correct—in a lot of areas.
"They ripped me off" is very prevalent in English speaking countries too, outside of tech.
Having the (almost) same API surface as another MIT library is hardly a "ripoff" but a re-implementation.
Edit: since new evidence has come forward (https://news.ycombinator.com/item?id=27275379) I think we can all agree that Lodash is a fork of Underscore.js, nothing more and nothing else.
https://github.com/lodash/lodash/commits/0.1.0?after=e0971cd...
If they were giving "no credit at all", they would be in violation of the MIT license.
Ok, does that make forks who don't mention where they forked from rips? Huge leap in logic.
> Why should I need to dig into the Git history to find out the creative origin of Lodash?
Well, if you're interested in the origin you either look for information available in threads like this, where other people dig or you dig yourself. Not sure what the problem is. Someone published a library under MIT, another person forked that library and created a new one, also under MIT, and somehow the fork is now a rip? Give me a break
> Based on Underscore.js, copyright Jeremy Ashkenas, DocumentCloud and Investigative Reporters & Editors <http://underscorejs.org/>
They've given precisely as much attribution as is required.
I have no qualms with forks or reimplementations (ie. Android - Java.) I actively support the paradigm.
But in this case, it's pretty shitty to try to erase all evidence of said inspiration. Most forks and reimplementations don't do that. They pay homage to their origin with at least a shout out.
After some digging, it seems like the Lodash website stopped mentioning Underscore.js around 2015 sometime, but even before that, it never had "evidence of said inspiration" as claimed by you.
Here are the versions I looked at:
- https://web.archive.org/web/20120826202523/http://lodash.com...
- https://web.archive.org/web/20130502014523/http://lodash.com...
- https://web.archive.org/web/20140517192947/http://lodash.com...
- https://web.archive.org/web/20150513014815/https://lodash.co...
- https://web.archive.org/web/20160803063412/https://lodash.co...
- https://web.archive.org/web/20170830163720/https://lodash.co...
- https://web.archive.org/web/20180703043557/https://lodash.co...
- https://web.archive.org/web/20190803030353/https://lodash.co...
- https://web.archive.org/web/20200615092636/http://lodash.com...
- https://web.archive.org/web/20210314233141/https://lodash.co...
> A drop-in replacement\* for Underscore.js
You are right though, my memory failed me. No mention of forking.. Shameless!
Inside Macintosh > Macintosh Human Interface Guidelines > Part 2 - The Interface Elements > Chapter 4 - Menus > Tear-Off Menus and Palettes
http://mirror.informatimago.com/next/developer.apple.com/doc...
http://mirror.informatimago.com/next/developer.apple.com/doc...
>A tear-off menu allows users to move a menu around the screen like a window. Tear-off menus save desktop space because the user can place them on top of a document or move them to a convenient position. If you implement a tear-off menu rather than a fixed palette in a window, you allow the user to have a larger workspace in document windows. Users can also choose to leave the menu in the menu bar, or tear it off and close it when necessary. Tear-off menus give the user more flexibility than fixed palettes do.
The library is free and worked on by maintainers in a spare time from main duties (not talking here about lodash specifically).
Maintainers don't own you any support nor obliged to work the way you may think they should.
I would say that it's great that we have many tools and should give more respect to maintainers which basically save you a ton of resources and maximum they ask for is to follow the established processes.
I've lost count of the number of tickets that have been raised that has no information, or is not reproducible, or something else. When I then ask for more information, or something else, they never reply. I've no incentive to keep such tickets open.
So I set up stale bot and auto-close the tickets. Individuals can come and re-open if it happens to them, or more information is added.
Now I do agree, if it is a genuine issue, then it shouldn't be closed until it is sorted out it. So you can set up stale bot to ignore labelled or something. So that's how I've set up all of my repos. For me this has taken off a huge burden.
I don't agree with locking threads after they've closed though. There is very little reason to do so.
This way maintainers need to at least explicitly set the label before the issue is closed automatically, and not the other way around.
[0]: https://github.com/vitejs/vite/blob/b6d12f71c1dbd5562f25bc2c...
It's like when I was clearing out my inbox of spam - about 10% of the garbage was legitimate spam, the rest was self-inflicted spam - ads for places I frequent, and mailing lists that I kept thinking I would read 'some day'.
What I needed was a way to group all of the suspicious messages so that I could machine gun my way through them spending less than a couple of seconds each. First hour got a lot of dead messages quickly, slowing down over time and totaling about 4k messages by hour four (most of that spent in front of a TV, which let me finish but also made it take longer - if you ignore the divide by zero error).
What you need is a way to tag suspicious issues so that you can go through and veto the 20 that are legit, and delete the rest. But that may require some feature requests to GitHub, and a different bot.
I have a different view of those in most cases - particularly on large, or publicly accessible, boards. That comment may not contribute anything useful for the people previously involved, but it may very well be useful for everyone else - such as any person that finds the thread through a search engine.
> Like when a user tells others in a 7 years old, obsolete thread they're wrong because shiny new solution XYZ exists.
That's a specific case about one-upping someone much later, but a more generalized case - posting modern solution under unresolved problem thread - is very valuable for people who find the thread looking for a solution. Conversely, blanket ban on "necroposting" discourages accumulation of knowledge on tough problems.
See also: https://xkcd.com/979/
I think this suggests two things:
1. There is an opportunity for better tooling. I'm thinking something like those annoying infinite scroll news/blog sites, where you reach the end of the article and it dynamically sticks another one on the page below (& updates the url). Imagine that but with any bug that's been marked as a duplicate (which the bug reporter should be able to do). Now you get the best of both worlds -- a way to view the new post with or without context.
2. Necro-ing would be less problematic if bug tracking were less centralized. More long, support-type bugs between distributors and users, where is preferable to log a new issue than necro an old one; more short summaries of confirmed bugs submitted by maintainers to the upstream repo. GitLab's separation of issues and epics is a good idea here, although their implementation is awkward at best.
That's a good point I haven't considered. Yeah, the consequence of mistakenly starting a new topic under an unrelated old thread is that the new discussion is now miscategorized and harder to find.
> It can still link to the old issue in order to keep the chain intact.
Yes, that would be great. If one could pull off an UI that nudged people to correctly link back to older threads, so that such links were typical, I think it would mostly solve the necropost problem - the etiquette could be changed to "don't necropost; if starting a new thread on a topic that was discussed in the past, ensure your post links back to those old discussions".
(I think I saw a few boards automatically generating a box with "related topics", but IIRC, their method of finding related topics yielded lots of false positives. If improved, this could work too, though I would still prefer explicit links that don't change over time.)
> I'm thinking something like those annoying infinite scroll news/blog sites, where you reach the end of the article and it dynamically sticks another one on the page below (& updates the url).
I personally don't want that. I hate this UI pattern. In particular:
- As implemented on social media platforms, it makes it nearly impossible to find your way back to something you saw a minute ago but scrolled past.
- As implemented on news sites, auto-appended articles are usually not relevant to the one you just finished.
- The URL substitution is particularly annoying - usually, the time I care about the URL is when I read/skim the article to the end, and then decide to share or bookmark it. At that point, the URL will already be changed to point to a different article, and it's easy to miss. And the way these feeds are implemented, if you follow the link to a follow-up article and scroll up, you won't get back the article you actually wanted.
The reason the term exists is because it's a blanket rule based on the age of the reply, not based on the intent or context.
The generally recommended alternative is to make a new thread and simply link to the old one so you don't confuse people.
I never understood it either. I mean, as a religion.
What is even sillier, is that as far as web forums are concerned, you have 50% of them which will go mad if you "necropost", and the other 50% which will go mad if you open a new thread when there is already an existing thread on the same topic (even buried), because these have the exact opposite written or unwritten rule. The latter ones love their 800 pages long topics; the former ones forbid you to follow up with a discussion even when it is the exact same topic, if the discussion stopped for a while.
I've seen something a bit like that: moderators who would come down hard on people who ask a question, both in an old thread or a new one (because the first time they were told not to create new threads or not to necropost so they tried again, following the advice, in the opposite manner), by telling them "why can't you search the fucking forum 2 minutes before digging an old thread / creating a new thread, stupid; this has been answered multiple times: here, here and here; topic locked", and of course none of the links he gives does answer the specific problem the posters had and clearly specified, because the mod didn't spend the said 2 minutes reading the posters' questions and just stupidly copied the first search results in the rush he had to punish the intruders. So, when you hit the same problems as the posters, you are out of luck, because their questions were not answered before, and they will never be.
The result is ~10 relevant hits when you Google an error message with not a single useful solution.
But secondly, even your own counterexample I don't think checks out. If I'm browsing your forum & interested in perspectives on working at Lyft v Uber, I absolutely want to read a recent update and contrast that with what people thought 3 yrs ago v now.
Tbh, the "I got my sound card working" post seems least appropriate of them all (but still ok to do imo, necroposts are good)
Old and current experiences are definitely both valuable. Just start a new thread. It's too easy for other members to miss the dates when it comes back to the top. Then they're reading and responding to old posts from absent people like they're here and now.
A random person online invests an afternoon to read through a years old issue thread and decides to comment, expecting the maintainer to reply. Meanwhile, maintainer has dozens of such issues, and dozens of frustrated users bringing up each of them every week. Asking the submitter to respect a previously made maintainer’s decision, file a new issue and invest their own time to concisely summarize the status quo seems only fair.
In other words, diverting discussion to a new thread is a chance to compress old context into a short summary, like you would squash a Git history—except in this case the old closed issue thread is fully linkable and isn’t going anywhere.
[0] That said, it depends on maintainer’s personality. I can see how some could feel losing control and demoralised by ever-evolving difficult-to-track discussions on previously closed issues.
What you describe is about the community respecting foss maintainers; closing tickets is not going to solve this problem.
Whether an issue should be closed or should be allowed to be re-opened by the public is not even up to debate as far as I’m concerned, this is up to maintainer’s policy.
When you can only tackle so many things there is 0 point in having a bug tracker that will only inflate and with little in the way of automatic triage determining the priority it is a borderline impossible task to wade through them.
Allowing duplicates is fine, the important stuff comes up again whilst the unimportant bits die off.
A public bug tracker isn't just for you. It, arguably, isn't even primarily for you. It's for all your users who experience a problem and want to confirm if someone else also had it, and if there's a known solution.
(It's something that particularly annoys me as a developer. I can fix problems on my own just fine, thank you. But I want to know if my problem is something tied to my configuration, or a known issue of some software that's failing for me - so that I don't waste time looking for the cause in the wrong place. I want the project's issue tracker to help me answer that question quickly - and auto-hiding/archiving/closing stale issues makes this job much harder.)
There is a lot of work still to be done on bug-tracking. The eternal attempt to keep users away from bugtrackers has meant that, when they inevitably became public because of FOSS growth, their interfaces did not really work for users.
I think it's high time we accepted bug trackers are also forums. There should be a way to mark certain comments as "effective workaround", and surface them at first glance. There should be ways for developers to mark certain comments as "useful info" so that the rest can be filtered. There should be ways to have lengthy discussions attached to the bug but not forced on the developer. There should be incentives to actually solve "historical" bugs first. In short, there should be different ways to look at a bug depending on one's role, without losing anything, without alienating anyone, and accepting the complexity of user-developer relations.
But there is very little money in it, I guess.
With that in mind, I believe that properly supporting all the various use cases an issue tracker serves without turning it into another JIRA is a hard UI design task.
But at the same time, practices like closing or locking stale bug reports can be seen as UI workarounds. Some people feel their boards are cluttered, so they reach for the only tools available - the close button, the lock button, an autoclosing/autolocking bot. It solves the UI issue for them, at the expense of other groups of board users.
This is to say: it's ultimately an UI deficiency on the part of a common issue trackers. Developers should be able to restructure their board as they see fit, but it shouldn't impact other users' ability to utilize the data stored on it. It would be great if major software forges solved this on their end.
Perhaps we need a concept of a "stale" issue/thread that's distinct from a "closed" one. A stale issue would be one that's not actively being looked at, but is nevertheless not resolved. The way it would differ from a regular open issue is:
- It doesn't sort itself up when somebody posts a comment on it.
- Posting on it doesn't notify people who didn't explicitly subscribe to it - all activity on stale issue is grouped under a single, inconspicuous indicator, that can be easily ignored.
- Stale issues are always sorted to the bottom or kept on a separate tab, and are trivial to filter in or out during searches. But the tab marker itself stays visible, so that people can find out there are such issues in the first place.
- Stale issue can be explicitly promoted to active at the discretion of the developers (or perhaps by community vote).
Hopefully this would reduce the need to aggressively close - and especially to lock - older issues.
I love the idea of bugtracker-as-forum (you're right that they already are and we're just in denial about it and don't design them to do that well) but it's the kind of thing that doesn't seem productizable (how many companies would want that, for instance? I doubt many) and non-commercial non-trivial open source isn't such a lively field, lately.
[0] https://www.sqlite.org/src/reportlist [1] https://www.sqlite.org/src/wiki?name=Bug+Reports [2] https://www.sqlite.org/forum/forum
Is there a reaction emoji that signals "effective workaround"?
Come to think of it, we need a "duct tape" emoji. I'm surprised it isn't in Unicode already.
Also, not everyone is using the most recent release.
No, it's a method of automatically discarding valuable information.
To put a different spin on what TeMPOraL said: a bug is roughly defined as a deviation from expected program behaviour. It is not defined as a deviation from expected behaviour which we intend to fix soon. There is value in keeping track of all the bugs in a codebase, even the ones you don't intend to fix soon.
That is to say, a bug tracker is for tracking bugs. It is not a to-do list. (edit Although I wouldn't want items on my to-do list to expire without my knowledge, either.)
If you want to mark a reported bug as Not a bug or Won't fix, that should be done manually. If a bug was fixed in passing as a result of some other work, the bug should be manually marked as fixed. It doesn't make sense to have a timeout act as a stand-in for a triage decision, in a way that fails to distinguish between these two outcomes.
So.. a filter.
I didn't claim it is a perfect filter. I did claim it is _a_ filter and one may subjectively decide it is a better choice than trying to track an ocean of issues which, if you're someone the size of Mozilla, will be a vast majority of "It crashed" useless issues anyway.
_If_ something is that important, it will come up again and closed issues can be referenced. Again, no claim that this is perfect from me.
This is "DELETE .... FROM TABLE WHERE ...."
You lose a lot of context from other reporters, and some discussion that could happen between reporters. All of this allows diagnosing an issue, and sometimes solving it without input from the team ("ah, this 3 years old bug? I solved it, turns out I had faulty memory, check yours").
I dislike closing them, especially as github only has two states: open and closed, and doesn't distinguish with invalid, wontfix, fixed, stale, needinfo, etc.
At least they are still searchable and interactable with when closed, but who thought it was a god idea to lock them? All the original subscribers won't be notified of new discussion on the topic.
If you're not working on a bug, then, by definition, it's not taking up your time.
Some people are just obsessive about not wanting to look like they have open bugs on their project. But closing tickets and fixing bugs are not the same thing.
Triaging an endless list is very costly.
I do agree with the idea that if you expect your project to be public (and not just something you did that you'll share if somebody wants) it is a cost you are expected to take. But it's wrong to pretend it's free.
If maintainers feel like they need to close tickets only to keep order, than that's a problem with the tooling: tickets should only be closed if they're malformed, solved, or (arguably) wontfix.
Oh, yes. Yes it is!
I think you were downvoted because the first part of your answer is wrong, but this one hits right on the mark.
You can't measure how many bugs you have, but you can measure how many bug reports you have. ;D
Imagine if the Linux kernel or even Chromium had stale bots closing reported vulnerabilities everywhere. It's like they are burying bugs waiting to be exploited by drive-by security researchers.
Some long standing problems get progressively easier to fix when the blockers around a bigger problem gets conquered slowly due to requirements.
I've worked on legacy codebases with thousands of unresolved issues old enough to drink. Those issues were probably triaged and reproduced by the people who hired the people who hired me and had been lovingly transferred during multiple bug tracker migrations, but they never achieved high enough priority to warrant development attention. And certainly no one on the current team had any interest (or time) to dig up and attempt to reproduce issues that no human has touched in a decade. Just reading through all the old issues would require a larger team than the product revenue could sustain, let alone reproducing and resolving them.
Having said that, there was no harm in keeping old issues "open" because everyone on the team used metadata to filter old issues out of their views so they were effectively "closed" in that no one ever saw them unless they deliberately went looking and they stopped being included in summary reports. No idea whether people would consider that better or worse than explicitly marking them as "Closed".
EDIT: Additionally, I've never worked anywhere where the capacity/willingness to fix bugs exceeded the incoming rate. So net bug count minus fixes would always grow forever unless you regularly purged unfixed bugs. This seems almost universally true in software.
Yeah, well, if it weren't so full of decades-old still-unsolved bugs, then maybe the product would have more users and therefore more revenue?
But I will say that my experience in enterprise software has been similar. The relationship between software quality and company success is more a bell curve than a linear one: if you neglect quality you'll certainly lose customers, but above a certain point if you spend too much of your budget fixing every bug you'll eventually lose to competitors with mediocre quality but lower prices and/or more capabilities.
It's all about finding the right balance.
For projects that have some sort of product manager who is personally in charge of managing and perhaps de-duplicating the tickets, I'd leave the choice up to them. Some like having only one ticket that captures all discussion about an issue. Some don't care, and aren't so worried about losing track of comments from several years ago. That feels to me like a work style issue, and I don't need to tell them how to do their job.
Or, for projects that are working with an issue tracking system that makes it really difficult to juggle large numbers of open tickets, I also see it as potentially valuable. It's a trade-off. Yes, you get a little extra chaos from broken discussion around perennial issues. But, if you simply cannot effectively manage and prioritize more than, say, a hundred open tickets, then that might be the lesser of two evils.
An issue where the reporter is unreachable and developers do not have local reproduction should absolutely be closed as it serves no function other than generating noise in the issue tracker.
Open issues is a liability to overview and planning, and having bad open issues is therefore directly harmful to maintainers, reporters and users.
Closing a bad but ultimately real issue will just make way for a possibly good report to take it's place (i.e. a new reporter rather an old unresponsive one) so it only provides benefit.
When I try to debug a problem and I see it has already been reported and closed due to inactivity (that is :not fixed. Not tagged won't fix) I give up, I won't fight the machine.
The process of closing it means pushes that work back on the users obviously this requires the coders to keep an eye on the bugs and assess their importance
Having 8000 bugs cross 10 years with ancient versions helps no one
FWIW In this case it’s a feature request
This sentence missing lot grammar.
So much so that I really can't even see which direction of the argument it's arguing for or against.
There are other types of trackers where automatic closure can be justified, but a bug tracker is not one of them.
I’ve said it before and will keep on saying it: GitHub’s stale bot should be removed with prejudice.