|
ExcessBLarg! posted:Disabling issues is elitism under the misguided assumption that users won't just figure out how to open bullshit pull requests too. Look, I don't think disabling issues is a good idea, but I understand. Which is to say, I think you are way off-base with your "smug" assumption. As the tech lead for a somewhat popular (~4000 GH stars) OSS project, I can aver that being at the business end of thousands of peoples' complaints, wishes, help requests... is really loving stressful sometimes. There's only one of me, after all, and I don't scale.
|
# ? Mar 18, 2016 23:42 |
|
|
# ? Jun 5, 2024 16:38 |
|
BigRedDot posted:Look, I don't think disabling issues is a good idea, but I understand. Which is to say, I think you are way off-base with your "smug" assumption. As the tech lead for a somewhat popular (~4000 GH stars) OSS project, I can aver that being at the business end of thousands of peoples' complaints, wishes, help requests... is really loving stressful sometimes. There's only one of me, after all, and I don't scale. I'm also reminded about the whole thing with microsoft's infamous 12000 bug database. It's not that windows had 12000 bugs. It's that, "I don't like the hue of the default blue in the splash screen." counted as a bug.
|
# ? Mar 18, 2016 23:55 |
|
Hughlander posted:I'm also reminded about the whole thing with microsoft's infamous 12000 bug database. It's not that windows had 12000 bugs. It's that, "I don't like the hue of the default blue in the splash screen." counted as a bug. You have to be off by at least one zero. There are probably 12000 open bugs against *Firefox*, let alone a whole OS.
|
# ? Mar 19, 2016 00:19 |
|
Subjunctive posted:You have to be off by at least one zero. There are probably 12000 open bugs against *Firefox*, let alone a whole OS. Firefox has 7776 "unconfirmed" bugs, but that's just Firefox itself and not things like Gecko or Spidermonkey.
|
# ? Mar 19, 2016 00:42 |
|
quote:If you think about it most of the time the changes we make break code. We just make it so it doesn't.
|
# ? Mar 19, 2016 03:43 |
|
Subjunctive posted:You have to be off by at least one zero. There are probably 12000 open bugs against *Firefox*, let alone a whole OS. I'll track it down. It was a big news article in the distant past.
|
# ? Mar 19, 2016 04:16 |
|
BigRedDot posted:There's only one of me, after all, and I don't scale. It's not elitist to not want to be responsible for responding to issues. It's very time consuming and often there's not much benefit to anyone. Users would figure things out either way, and you're stuck spending your time janitoring the issue tracker then, well, whatever you prefer to spend your free time doing. The elitism is the thinking that they can cut off communication with (or between) their users by disabling an easy-to-use issue tracker, and requiring people to figure out how to post a pull request; believing that most unhelpful users won't figure out how or won't bother. I'm of the opinion that communication channels are a good thing, you just don't have to personally moderate them. ExcessBLarg! fucked around with this message at 19:09 on Mar 19, 2016 |
# ? Mar 19, 2016 19:04 |
|
ExcessBLarg! posted:So treat your issue list like a honeypot and ignore them. You have no obligation to respond to every issue, or even any issue. If the project is sufficiently popular, users will use the issue list to take care of themselves. If you don't like the idea of a bunch of open issues that will never be closed, then turning off issues might be fine if you replace it with a reasonable alternative like a discussion group. In the end if you don't wanna deal with users, you might wanna reconsider making your project open at all.
|
# ? Mar 20, 2016 16:51 |
|
SupSuper posted:Leaving your project with a big old list of open issues easily breeds the idea that your project is buggy/inactive/unresponsive/not-worth-their-time which can be poisonous to open-source. Likewise, just letting your users "handle themselves" without any developer input or moderation will likely lead to a lot of misinformation making your job worse. Yeah, the number of open issues and the age of the open issues is definitely something I heavily consider when I'm thinking about using a library. I mean, I realize that different styles of project management will have a bearing on this, but it's still something I consider.
|
# ? Mar 20, 2016 18:18 |
|
GitHub webhook to close all issues when they open with "Could not reproduce." Fixes many things.
|
# ? Mar 20, 2016 20:11 |
|
Hughlander posted:I'll track it down. It was a big news article in the distant past. From 2000: Windows 2000 has 63,000 bugs
|
# ? Mar 20, 2016 20:35 |
|
SupSuper posted:Leaving your project with a big old list of open issues easily breeds the idea that your project is buggy/inactive/unresponsive/not-worth-their-time which can be poisonous to open-source. SupSuper posted:In the end if you don't wanna deal with users, you might wanna reconsider making your project open at all. Edit: So, how would you evaluate a project hosted on GitHub which had disabled its issues tab? I doubt the reasonable conclusion is that the project must have no problems. ExcessBLarg! fucked around with this message at 21:26 on Mar 20, 2016 |
# ? Mar 20, 2016 21:19 |
|
in our bug tracking system even something like "there's a typo on this retired screen that is totally inaccessible in the current release" counts as a bug. only like .5% of open "bugs" are things that i would consider to be truly critical to fix for the quality of the product. the rest is the bug tracker version of a bit of string around your finger so you dont forget to tweak thing x or y.
|
# ? Mar 21, 2016 00:11 |
|
LeftistMuslimObama posted:in our bug tracking system even something like "there's a typo on this retired screen that is totally inaccessible in the current release" counts as a bug. only like .5% of open "bugs" are things that i would consider to be truly critical to fix for the quality of the product. the rest is the bug tracker version of a bit of string around your finger so you dont forget to tweak thing x or y. Where I am there is a policy that a bug is triaged within 30 days and a plan for when/how to deal with it is set or it's closed. Honestly not sure how I feel about that yet.
|
# ? Mar 21, 2016 00:22 |
|
LeftistMuslimObama posted:in our bug tracking system even something like "there's a typo on this retired screen that is totally inaccessible in the current release" counts as a bug. only like .5% of open "bugs" are things that i would consider to be truly critical to fix for the quality of the product. the rest is the bug tracker version of a bit of string around your finger so you dont forget to tweak thing x or y. This is how we run things, too. I like it because it means that if you have e.g. two hours left in the week and you've finished all your big stuff, you can hit up the bug tracker for a few small things to get accomplished.
|
# ? Mar 21, 2016 00:44 |
|
TooMuchAbstraction posted:This is how we run things, too. I like it because it means that if you have e.g. two hours left in the week and you've finished all your big stuff, you can hit up the bug tracker for a few small things to get accomplished. exactly. when you attach a file to your "log" in our system (i guess a log is analogous to a feature branch), our system shows you all the other bugs written up against that file so you can fix any low hanging fruit that's out there for it at the same time. you can usually tell who's a lovely lazy rear end in a top hat when you get their code to review and they've left like 15 "there's a typo in this prompt" bugs open. those guys don't last long.
|
# ? Mar 21, 2016 03:59 |
|
LeftistMuslimObama posted:exactly. when you attach a file to your "log" in our system (i guess a log is analogous to a feature branch), our system shows you all the other bugs written up against that file so you can fix any low hanging fruit that's out there for it at the same time. you can usually tell who's a lovely lazy rear end in a top hat when you get their code to review and they've left like 15 "there's a typo in this prompt" bugs open. those guys don't last long. Surely you want separate bugs addressed by separate changesets though.
|
# ? Mar 21, 2016 10:25 |
|
Hammerite posted:Surely you want separate bugs addressed by separate changesets though. They could be checked in separately and reviewed as a unit.
|
# ? Mar 21, 2016 12:13 |
|
ExcessBLarg! posted:That's pretty silly. There's a middle ground between "not dealing with users" and spending many hours a day responding to all open issues. But even if you did categorically ignore all issue requests and outside contributions (say, due to lack of time), you might still want to make the source available to others for their own use and enhancement. Those aren't conflicting goals. Honestly I think there should be better places for just putting code out there for others to learn/use. Open-source repositories carry certain assumptions of "licenses" and "contribution models" that affect user expectations. ExcessBLarg! posted:Edit: So, how would you evaluate a project hosted on GitHub which had disabled its issues tab? I doubt the reasonable conclusion is that the project must have no problems. I'm not saying getting rid of the tracker is a good solution. If there's no tracker for me to report issues on, I'd just email them instead, which is probably not what they wanted.
|
# ? Mar 21, 2016 13:35 |
|
SupSuper posted:If you want people using your code no questions asked, maybe put it in Stack Overflow instead. Well this is fundamentally a problem with the way people use Github. It's become a tool for distribution more than a tool for open source collaborative development. How many people have installed Oh My ZSH? How many people have contributed to its development? Most other popular projects probably have similarly lop-sided ratios of users compared to contributors. When the people using the Github page are people with no interest in contributing to the source, it's not surprising that the nature of bug-reporting changes. It shifts to a more traditional user support model(with all the stress that entails), and Github still operates from the standpoint that the tools are developer-focused. So there's mismatch between what the tools are supposed to be for versus how they're actually used. It's easy to release stuff on Github without realizing that the end result of having a popular project is not much different than releasing software through traditional channels.
|
# ? Mar 21, 2016 14:26 |
|
LeftistMuslimObama posted:exactly. when you attach a file to your "log" in our system (i guess a log is analogous to a feature branch), our system shows you all the other bugs written up against that file so you can fix any low hanging fruit that's out there for it at the same time. you can usually tell who's a lovely lazy rear end in a top hat when you get their code to review and they've left like 15 "there's a typo in this prompt" bugs open. those guys don't last long. If you find a "there's a typo in this prompt" bug, and you already know what file it is in and exactly how to fix it to the point that someone else later editing the same file is a lovely lazy rear end in a top hat for not fixing it, doesn't that make you a lovely lazy rear end in a top hat for filing a bug instead of just fixing it?
|
# ? Mar 21, 2016 15:22 |
|
Steve French posted:If you find a "there's a typo in this prompt" bug, and you already know what file it is in and exactly how to fix it to the point that someone else later editing the same file is a lovely lazy rear end in a top hat for not fixing it, doesn't that make you a lovely lazy rear end in a top hat for filing a bug instead of just fixing it? Some places with change management requires all changes to have a triaged business case attached to it. (And I think those places suck but they exist. )
|
# ? Mar 21, 2016 15:33 |
|
Steve French posted:If you find a "there's a typo in this prompt" bug, and you already know what file it is in and exactly how to fix it to the point that someone else later editing the same file is a lovely lazy rear end in a top hat for not fixing it, doesn't that make you a lovely lazy rear end in a top hat for filing a bug instead of just fixing it? no, our build process is the most hilariously bad poo poo and opening a log just to fix a screen typo is still going to suck you down a 30 hour hellhole of dealing with that. it's better to sweep in those non-bug bugs into real dev where you actually need to sink the time into it anyway. if our build process wasn't stupid? sure, we should just be fixing that stuff right away.
|
# ? Mar 21, 2016 15:33 |
|
Hughlander posted:Some places with change management requires all changes to have a triaged business case attached to it. (And I think those places suck but they exist. ) LeftistMuslimObama posted:no, our build process is the most hilariously bad poo poo and opening a log just to fix a screen typo is still going to suck you down a 30 hour hellhole of dealing with that. it's better to sweep in those non-bug bugs into real dev where you actually need to sink the time into it anyway. Yep, I'm aware of such places. As long as we all agree that such rules are stupid and counterproductive, then we are all on the same page.
|
# ? Mar 21, 2016 15:36 |
|
Yeah! Down with process! No reviews no masters!
|
# ? Mar 21, 2016 18:01 |
|
JawnV6 posted:Yeah! Down with process! No reviews no masters! Man, gently caress happy mediums, am I right? You either have total anarchy or total bureaucracy, there is no middle ground!
|
# ? Mar 21, 2016 18:06 |
|
code:
|
# ? Mar 21, 2016 19:06 |
|
HoboMan posted:
Looks to me like someone changed the capitalization of the function at some point, so this is the ~backwards compatible~ code to deal with that. "Do you have a function named 'close'? Okay, then call that. Otherwise, call 'Close' instead."
|
# ? Mar 21, 2016 19:11 |
|
HoboMan posted:
Uh thats pretty whacky. Is this something shared between a browser and some other... thing? AFAIK the window object's close method has always been lower case.
|
# ? Mar 21, 2016 19:12 |
|
Steve French posted:Yep, I'm aware of such places. As long as we all agree that such rules are stupid and counterproductive, then we are all on the same page. I wouldn't call them "rules". It's more like we have an enormous legacy codebase in vb6 and a very precariou build process to keep it all chugging along 20 years later. We're replacing that stuff with modern technology as we can, but in the world of enterprise you can't just throw away your software and do a full scale rewrite in a single release. As a result, the environment you have to work in informs your decisions. You're not going to branch something that may have dependencies in 30 other files just so you can fix a typo, because now you have to make sure that your commit actually compiles when you merge it back in, which can be nontrivial depending on what work has been happening in those other dependencies. As a result, we've developed the system we have now, where when we see that you're going to be working in that file anyway we show you all the low-hanging fruit you should pick off while you're at it. Which makes you an especial garbage dick if you don't fix those things, because you know full well that nobody might touch this file for quite a while and it would be an enormous waste of resources for someone to branch it just to fix those things only. I just want to be clear that these things aren't deliberately stupid and counterproductive. Sometimes broken processes just arise from what you have to work with.
|
# ? Mar 21, 2016 19:30 |
|
HoboMan posted:
That weird capitalisation reminds me of when I was working on ASP.NET (no not that ASP.NET, the old one, the lovely one) and it would generate a ton of JavaScript that looked like that. Anyway I have no idea what a rad window is, looks like someone found a weird case where a rad window may have a close method sometimes and a Close method other times and this is how they're dealing with it. Edit: oh what do you know, it IS some weird ASP.NET thing involving whatever the hell telerik is
|
# ? Mar 21, 2016 19:58 |
|
Other highlights of this code I am now faced with include: a switch statement with only one case, data validation done entirely in javascript, and "RadWindow"[1-25] as the only listed names for different popups (the 25 is a guess since they are also listed out of numerical order and mixed in with stuff that has proper descriptive names)
|
# ? Mar 21, 2016 20:03 |
|
Please add some braces to that JS code, thank you.
|
# ? Mar 21, 2016 20:06 |
|
HoboMan posted:a switch statement with only one case Incidentally this is really common in low-level Haskell.
|
# ? Mar 21, 2016 20:10 |
|
The fun thing here is that the issue is almost certainly not JavaScript's fault but lies with either the C# framework that is autogenerating it, or the guy working with the C# framework who just threw some poo poo together to get it working. Or you just work with someone who sucks at their job.
|
# ? Mar 21, 2016 20:10 |
|
^ [x] All of the above
|
# ? Mar 21, 2016 20:23 |
|
I'd imagine it's just due to Telerik clientside RadWindow APIs being a terrible clusterfuck as evidenced by the fact that all the rest of their Javascript poo poo is a terrible clusterfuck
|
# ? Mar 21, 2016 20:33 |
|
HoboMan posted:"RadWindow"[1-25] as the only listed names for different popups (the 25 is a guess since they are also listed out of numerical order and mixed in with stuff that has proper descriptive names) this poo poo is the worst. since we work in the wonderful language of mumps here, all our data gets passed around as btrees which can have any arbitrary subscript names within them that you want, which means you need to read lots of nearly-unrelated code of varying states of age and convolutedness just to find out what data can go into a given array you're working with and what the various functions that handle it are expecting that data to be called. there's no concept of defining constants at any level in mumps so there's not really even a way to hack together some kind of intellisense to let you know what subscripts you could use with a given array. you're at the mercy of someone deciding to write a wiki about any given array's structure.
|
# ? Mar 21, 2016 20:33 |
|
I believe I am slogging though a nightmare of code that was auto-generated 10 years ago
|
# ? Mar 21, 2016 20:44 |
|
|
# ? Jun 5, 2024 16:38 |
gonadic io posted:Incidentally this is really common in low-level Haskell. Interesting. When is this useful?
|
|
# ? Mar 21, 2016 21:47 |