Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
BigRedDot
Mar 6, 2008

ExcessBLarg! posted:

Disabling issues is elitism under the misguided assumption that users won't just figure out how to open bullshit pull requests too.

It's also counter productive as, today, maintainers can ignore issues which users will sort between themselves and concentrate on pull requests which have a much better signal-to-noise ratio. If you close issues, the SNR on pull requests will get much worse. The eventual conclusion is secret private repos shared among a cabal, basically returning to the 90s open-source contribution models.

Also, honestly, the smug elitism is blatantly transparent. Have any of them written real code or is it all JavaScript? Looks like just JavaScript.

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.

Adbot
ADBOT LOVES YOU

Hughlander
May 11, 2005

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.

Subjunctive
Sep 12, 2006

✨sparkle and shine✨

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.

Plorkyeran
Mar 22, 2007

To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

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.

Dessert Rose
May 17, 2004

awoken in control of a lucid deep dream...

quote:

If you think about it most of the time the changes we make break code. We just make it so it doesn't.
:2bong:

Hughlander
May 11, 2005

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.

ExcessBLarg!
Sep 1, 2001

BigRedDot posted:

There's only one of me, after all, and I don't scale.
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.

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

SupSuper
Apr 8, 2009

At the Heart of the city is an Alien horror, so vile and so powerful that not even death can claim it.

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.

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.
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.

In the end if you don't wanna deal with users, you might wanna reconsider making your project open at all.

Thermopyle
Jul 1, 2003

...the stupid are cocksure while the intelligent are full of doubt. —Bertrand Russell

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.

In the end if you don't wanna deal with users, you might wanna reconsider making your project open at all.

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.

Hughlander
May 11, 2005

GitHub webhook to close all issues when they open with "Could not reproduce." Fixes many things.

Suspicious Dish
Sep 24, 2011

2020 is the year of linux on the desktop, bro
Fun Shoe

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

ExcessBLarg!
Sep 1, 2001

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.
Personally I evaluate commit quality, and sometimes checkout closed issues and PRs to see how issues that have been handled, how they were handled. Open issues alone doesn't really mean a whole lot, and usually you can glance down the stack of older open issues and see there's a lot of noise. Maybe that's not how other people perceive things.

SupSuper posted:

In the end if you don't wanna deal with users, you might wanna reconsider making your project open at all.
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.

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

The MUMPSorceress
Jan 6, 2012


^SHTPSTS

Gary’s Answer
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.

Hughlander
May 11, 2005

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.

TooMuchAbstraction
Oct 14, 2012

I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.
Fun Shoe

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.

The MUMPSorceress
Jan 6, 2012


^SHTPSTS

Gary’s Answer

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.

Hammerite
Mar 9, 2007

And you don't remember what I said here, either, but it was pompous and stupid.
Jade Ear Joe

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.

Ika
Dec 30, 2004
Pure insanity

Hammerite posted:

Surely you want separate bugs addressed by separate changesets though.

They could be checked in separately and reviewed as a unit.

SupSuper
Apr 8, 2009

At the Heart of the city is an Alien horror, so vile and so powerful that not even death can claim it.

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.
If you want people using your code no questions asked, maybe put it in Stack Overflow instead. :v:

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.
See what public opinion turns up on Google, it's pretty hard to assess a project from its Github.

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.

ErIog
Jul 11, 2001

:nsacloud:

SupSuper posted:

If you want people using your code no questions asked, maybe put it in Stack Overflow instead. :v:

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.

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.

Steve French
Sep 8, 2003

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?

Hughlander
May 11, 2005

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. )

The MUMPSorceress
Jan 6, 2012


^SHTPSTS

Gary’s Answer

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.

Steve French
Sep 8, 2003

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.

if our build process wasn't stupid? sure, we should just be fixing that stuff right away.

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.

JawnV6
Jul 4, 2004

So hot ...
Yeah! Down with process! No reviews no masters!

TooMuchAbstraction
Oct 14, 2012

I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.
Fun Shoe

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!

HoboMan
Nov 4, 2010

code:
function Cancel_Clicked() {
            var oWindow = GetRadWindow();
            if (oWindow)
                if (oWindow.close)
                    oWindow.close();
                else
                    oWindow.Close();
        }
I don't know dick about javascript or any web poo poo, but what the hell is this?

TooMuchAbstraction
Oct 14, 2012

I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.
Fun Shoe

HoboMan posted:

code:
function Cancel_Clicked() {
            var oWindow = GetRadWindow();
            if (oWindow)
                if (oWindow.close)
                    oWindow.close();
                else
                    oWindow.Close();
        }
I don't know dick about javascript or any web poo poo, but what the hell is this?

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."

necrotic
Aug 2, 2005
I owe my brother big time for this!

HoboMan posted:

code:
function Cancel_Clicked() {
            var oWindow = GetRadWindow();
            if (oWindow)
                if (oWindow.close)
                    oWindow.close();
                else
                    oWindow.Close();
        }
I don't know dick about javascript or any web poo poo, but what the hell is this?

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.

The MUMPSorceress
Jan 6, 2012


^SHTPSTS

Gary’s Answer

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.

piratepilates
Mar 28, 2004

So I will learn to live with it. Because I can live with it. I can live with it.



HoboMan posted:

code:
function Cancel_Clicked() {
            var oWindow = GetRadWindow();
            if (oWindow)
                if (oWindow.close)
                    oWindow.close();
                else
                    oWindow.Close();
        }
I don't know dick about javascript or any web poo poo, but what the hell is this?

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

HoboMan
Nov 4, 2010

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)

Vanadium
Jan 8, 2005

Please add some braces to that JS code, thank you.

gonadic io
Feb 16, 2011

>>=

HoboMan posted:

a switch statement with only one case

Incidentally this is really common in low-level Haskell.

piratepilates
Mar 28, 2004

So I will learn to live with it. Because I can live with it. I can live with it.



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.

HoboMan
Nov 4, 2010

^ [x] All of the above

MisterZimbu
Mar 13, 2006
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

The MUMPSorceress
Jan 6, 2012


^SHTPSTS

Gary’s Answer

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.

HoboMan
Nov 4, 2010

I believe I am slogging though a nightmare of code that was auto-generated 10 years ago

Adbot
ADBOT LOVES YOU

VikingofRock
Aug 24, 2008




gonadic io posted:

Incidentally this is really common in low-level Haskell.

Interesting. When is this useful?

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply