|
Meh, I report valid and well-received-and-eventually-resolved issues all the time for things that I have no idea how to fix nor do I have the time to figure out how to write test cases for your special snowflake project, so on the one hand I say I hate that idea. On the other hand issues are often quite bogus and a chore to handle so I can understand the sentiment.
|
#
?
Mar 17, 2016 20:46
|
|
|
|
| # ? May 17, 2024 15:53 |
|
|
Thermopyle posted:Meh, I report valid and well-received-and-eventually-resolved issues all the time for things that I have no idea how to fix nor do I have the time to figure out how to write test cases for your special snowflake project, so on the one hand I say I hate that idea. Yeah I understand why they're doing it, but j can't help but see it just turning people off of the project by doing a hard and fast "no code? Don't care". I think it'd be better even if they just replied to every issue with "could you provide some code related to this issue?" instead so people go ahead and make an issue and are then partially invested in it instead of turning them away from the start.
|
|
#
?
Mar 17, 2016 20:54
|
|
|
It doesn't help that github issues suck as a tool.
|
|
#
?
Mar 17, 2016 20:58
|
|
|
Subjunctive posted:It doesn't help that github issues suck as a tool. *cue a hundred thumbs up and +1 emojis " "Please stop posting only +1 to this issue. " *cue a hundred more thumbs up and +1 emojis" I think they actually brought in a +1 button to alleviate this but I'm 100% confident that people are just posting a reply with a thumbs up in it anyway.
|
|
#
?
Mar 17, 2016 21:01
|
|
|
There's no great way to "move on" from a project except to remove it from under your account, breaking the URL of everyone who cloned it at one point. So there's definitely a pressure to never move on that GitHub gives you from its account-based architecture being kinda garbo.
|
|
#
?
Mar 17, 2016 21:12
|
|
|
If you create a new org and move the repo to it the old url under your account will redirect to the new one. Github's handling of moving repos is actually really good other than that they do a bad job of communicating that it's even an option.
|
|
#
?
Mar 17, 2016 22:26
|
|
|
Plorkyeran posted:If you create a new org and move the repo to it the old url under your account will redirect to the new one. Github's handling of moving repos is actually really good other than that they do a bad job of communicating that it's even an option. I, for example, had no idea that you could do this 
|
|
#
?
Mar 17, 2016 22:31
|
|
|
piratepilates posted:Because you can do it better, duh! It's even easier than that; all Kafka does is take some data and spit out the same stuff out at the other end! Just replace it with some shell scripting and a couple of unix pipes. It's an afternoon job, maybe a day top if you count the time to migrate production systems.
|
|
#
?
Mar 17, 2016 23:16
|
|
|
piratepilates posted:Came across this discussion on Twitter about removing issues from github and forcing everything to be a PR instead: https://gist.github.com/ryanflorence/8a62abea562ca2896dee Another approach might be to require everybody to pass a short IQ test before being allowed to download your software.
|
|
#
?
Mar 17, 2016 23:51
|
|
|
Plorkyeran posted:If you create a new org and move the repo to it the old url under your account will redirect to the new one. Github's handling of moving repos is actually really good other than that they do a bad job of communicating that it's even an option. Oh, huh! That's actually pretty good, then.
|
|
#
?
Mar 17, 2016 23:56
|
|
|
Suspicious Dish posted:Oh, huh! That's actually pretty good, then. Plain ownership transfer works too. https://github.com/kazu-yamamoto/ghc-mod redirects to https://github.com/DanielG/ghc-mod
|
|
#
?
Mar 18, 2016 00:16
|
|
|
piratepilates posted:Came across this discussion on Twitter about removing issues from github and forcing everything to be a PR instead: https://gist.github.com/ryanflorence/8a62abea562ca2896dee Also found a twitter conversation about it: https://twitter.com/kentcdodds/status/710521313161453568 I quite like this @RReverser fellow just coming in and being like "this is a stupid idea why are you considering this"
|
|
#
?
Mar 18, 2016 02:37
|
|
|
piratepilates posted:
doesn't that automatically get turned into a +1 button press
|
|
#
?
Mar 18, 2016 03:25
|
|
|
You could also just ignore issues and pull requests entirely. That would be even less work. Heck, why not close the source?
|
|
#
?
Mar 18, 2016 10:15
|
|
|
Surely an issue/feature request/bug and a pull request are two different kinds of thing. An issue is the record that "something's not right or somebody wants it changed". A pull request represents an attempt at fixing that thing. An issue might prompt several changes, that might work together or might be different people's solutions to the same problem; that's a one-to-many relationship. If you have two pull requests seeking to address the same issue, what mechanism do you have for expressing the fact that the two pull requests are related? That post on GitHub complains that project contributors don't like dealing with issues that turn out to be bullshit. But pull requests can be bullshit too.
|
|
#
?
Mar 18, 2016 12:19
|
|
|
Hammerite posted:Surely an issue/feature request/bug and a pull request are two different kinds of thing. An issue is the record that "something's not right or somebody wants it changed". A pull request represents an attempt at fixing that thing. An issue might prompt several changes, that might work together or might be different people's solutions to the same problem; that's a one-to-many relationship. If you have two pull requests seeking to address the same issue, what mechanism do you have for expressing the fact that the two pull requests are related? An issue also helps if you would like to get additional feedback whether something is broken or not working as intended for multiple people, since others can chime in (much like something like Bugzilla). I also like them as "wishlists" for features etc., but then I'm not the one mainting them, so maybe that person would prefer pull requests after all.
|
|
#
?
Mar 18, 2016 15:06
|
|
|
Hammerite posted:That post on GitHub complains that project contributors don't like dealing with issues that turn out to be bullshit. But pull requests can be bullshit too. Especially when you disable issues so people start opening PRs merging random branches just to report an issue.
|
|
#
?
Mar 18, 2016 15:16
|
|
|
Hammerite posted:That post on GitHub complains that project contributors don't like dealing with issues that turn out to be bullshit. But pull requests can be bullshit too. And they're harder to turn down without looking like a jerk, too, since someone went to the effort to code a "fix" -- even if they're an incompetent programmer or their fix is undesirable for other reasons.
|
|
#
?
Mar 18, 2016 15:17
|
|
|
Hammerite posted:That post on GitHub complains that project contributors don't like dealing with issues that turn out to be bullshit. But pull requests can be bullshit too.
|
|
#
?
Mar 18, 2016 15:18
|
|
|
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.
|
|
#
?
Mar 18, 2016 15:33
|
|
|
If a project is just too much of a burden on the maintainer's sanity or their family, why can't they just pass the repo to someone else? 
Space Kablooey fucked around with this message at 15:49 on Mar 18, 2016 |
|
#
?
Mar 18, 2016 15:35
|
|
|
ExcessBLarg! posted:
|
|
#
?
Mar 18, 2016 15:37
|
|
|
ExcessBLarg! posted:Also, honestly, the smug elitism is blatantly transparent. Have any of them written real code or is it all JavaScript? Looks like just JavaScript. So you're decrying elitism with further elitism? idgi.
|
|
#
?
Mar 18, 2016 15:42
|
|
|
Easy solution. First project that does submit a pr: Added file issues/1 Copy paste from github issue
|
|
#
?
Mar 18, 2016 15:43
|
|
|
I only accept issues or pull requests via carrier pigeon. This keeps the signal-to-noise ratio high and also blocks all of those poors and other lesser beings that do not have their own aviary. 
|
|
#
?
Mar 18, 2016 15:48
|
|
|
This is hilarious: https://github.com/dotnet/roslyn/issues/9772 Guy makes a language proposal that would constitute a breaking change with minimal benefit, doesn't understand what "breaking change" means, and stubbornly defends his proposal. It's great.
|
|
#
?
Mar 18, 2016 15:50
|
|
|
Basically that post on GitHub is a reaction to the apparently unforeseeable issue that if you make software with no barriers to who can use it, then guess what, everybody will use it. Everybody will run into problems with it, everybody will hit bugs or want features to support their use cases. The easier to use the software is, the more useful it is, the more people will come back with issues. But there's a distinction between a user and a contributor. 99% of people using any particular piece of software don't give a monkey's how it works, they just want it to work. They don't care how the code is arranged, what coding styles or test frameworks are in place, what programming language it was even written in, or about the grand architecture of the internals. Nor should they! The whole point of modular, reusable software is to encapsulate those concerns so we don't need to care about internals to get stuff done. The whole point is to hide that complexity from users. This way tools and libraries can be composed without worry, whereas responsibility for those internals can be contained to a dedicated team who have chosen to care. Insert the car analogy here.
|
|
#
?
Mar 18, 2016 15:53
|
|
|
Hughlander posted:Easy solution. First project that does submit a pr: Joey Hess, the author of git-annex and propellor, has a doc/bugs folder in all of his projects. Each bug gets its own documentation file, updated with new information as needed, until they're marked "fixed," sometimes in the same commit which actually fixes them. I found the system a bit compelling: at the very least, accepting bug reports via pull request would emphasize that they are contributions, even without code. E: oh, none of his projects are on github though, I think he rolled his own project-site-thing Doc Hawkins fucked around with this message at 15:57 on Mar 18, 2016 |
|
#
?
Mar 18, 2016 15:55
|
|
|
Ithaqua posted:This is hilarious: https://github.com/dotnet/roslyn/issues/9772 Jesus Christ. I'm starting to think there should be a universal word filter for "beautiful code" the same way that chrome extension worked for "the cloud". It's on the same level of "I prefer composition over inheritance" where the meaning has been diluted to the point where it never adds anything.
|
|
#
?
Mar 18, 2016 16:01
|
|
|
Doc Hawkins posted:Joey Hess, the author of git-annex and propellor, has a doc/bugs folder in all of his projects. Each bug gets its own documentation file, updated with new information as needed, until they're marked "fixed," sometimes in the same commit which actually fixes them. I found the system a bit compelling: at the very least, accepting bug reports via pull request would emphasize that they are contributions, even without code. I do fundamentally like the idea of bug tracking being intimately tied to the source repo, and I really wish there were good tools for it. Fossil does it well, but it IMO isn't a very good at the whole source code management side of things.
|
|
#
?
Mar 18, 2016 16:18
|
|
|
qntm posted:But there's a distinction between a user and a contributor. 99% of people using any particular piece of software don't give a monkey's how it works, they just want it to work. They don't care how the code is arranged, what coding styles or test frameworks are in place, what programming language it was even written in, or about the grand architecture of the internals. Nor should they! A particularly bad kind of bug reports coming from other 1% is those that think they know how it works, and therefore will have detailed instructions on how to "fix" the bug included.... Though that often leans more into comedic than irritating. But really, the only public bug trackers that don't have at least some trainwrecks of bug reports are those of wildly unpopular software.
|
|
#
?
Mar 18, 2016 17:17
|
|
|
OddObserver posted:A particularly bad kind of bug reports coming from other 1% is those that think they know how it works, and therefore will have detailed instructions on how to "fix" the bug included.... Though that often leans more into comedic than irritating. These are called "smug reports".
|
|
#
?
Mar 18, 2016 17:20
|
|
|
Ithaqua posted:This is hilarious: https://github.com/dotnet/roslyn/issues/9772 
|
|
#
?
Mar 18, 2016 18:47
|
|
|
Plorkyeran posted:I do fundamentally like the idea of bug tracking being intimately tied to the source repo, and I really wish there were good tools for it. Fossil does it well, but it IMO isn't a very good at the whole source code management side of things. I love fossil. It only occasionally destroys all history of my projects including the working copy.
|
|
#
?
Mar 18, 2016 20:05
|
|
|
Ithaqua posted:This is hilarious: https://github.com/dotnet/roslyn/issues/9772 This is so much like the last roslyn ticket that hit this thread. "Here's my pet feature. I don't care about this 'breaking' nonsense, let's all just be positive folks!!"
|
|
#
?
Mar 18, 2016 22:05
|
|
|
quote:I just don't see the point of the argument. Would you say not having to add a semicolon at the end of every statement in C# 7 is a breaking change? Can it be done? I think is achievable. I already proposed that too. It will be great if we can have that, right? What a strange worldview this person must have, to see people patiently explaining why their idea is a bad idea and isn't going to be adopted and think "these people are going out of their way to confound and frustrate me" They are literally saying in there that the critical evaluation of ideas is pointless. That it's no-one's place to make judgements as to the merits of a suggestion
|
|
#
?
Mar 18, 2016 22:29
|
|
|
Those are the most dangerous coworkers, by the way.
|
|
#
?
Mar 18, 2016 22:41
|
|
|
Hammerite posted:What a strange worldview this person must have, to see people patiently explaining why their idea is a bad idea and isn't going to be adopted and think "these people are going out of their way to confound and frustrate me" All of that over having to use an '@' symbol in front of a string, as if that is destroying the 'beauty' of the code.
|
|
#
?
Mar 18, 2016 22:49
|
|
|
Hammerite posted:What a strange worldview this person must have, to see people patiently explaining why their idea is a bad idea and isn't going to be adopted and think "these people are going out of their way to confound and frustrate me" My theory is that nobody's ever told this person "no" before, so they literally don't understand what they're hearing. Used to being babied and spoilt. An outright refusal just doesn't even register, a push back must just mean you aren't paying enough attention. You don't understand. I'm asking you to do something. Think about this and try again.
|
|
#
?
Mar 18, 2016 23:07
|
|
|
|
| # ? May 17, 2024 15:53 |
|
|
piratepilates posted:All of that over having to use an '@' symbol in front of a string, as if that is destroying the 'beauty' of the code. What's that quote about how the majority of any discussion of language features focuses on syntax instead of semantics?
|
|
#
?
Mar 18, 2016 23:30
|
|