Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dear GitHub

github.com

Post reply on HN
Print view View original

161–170 of 491 posts

Re: Dear GitHub

#161

Post by imtringued »

ggreer wrote: post #137
monkmartinez wrote: post #42

I do not operate a popular OSS project, but I have experienced the +1 spam and it sucks. The suggestions, in my opinion seem rational. Interesting side note: With the exception of Selenium, most of signees are maintainers of JS/HTML OSS projects. I wonder if we could objectively compare JS to projects in terms of the problems mentioned in the document. For example, there is a strong correlation between +1'ers and JS…

I maintain a C repo[1] and user idiocy is much lower than what I've seen in JS projects of similar popularity. Still, I agree with these criticisms of GitHub. I hate +1 spam enough to delete such comments. Sometimes I even ban those who do it. I'm frustrated by people who open idiotic issues[2][3][4][5]. I procrastinate on bad pull requests because my options are: 1. Close the PR with little or no comment. People the…

About number 5. I don't see anyone complaining about anything.

Re: Dear GitHub

#162

Post by lamontcg »

Permit wrote: post #142

This first request is the anti-thesis of GitHub's simple approach: >Issues are often filed missing crucial information like reproduction steps or version tested. We’d like issues to gain custom fields, along with a mechanism (such as a mandatory issue template, perhaps powered by a newissue.md in root as a likely-simple solution) for ensuring they are filled out in every issue. Every checkbox, text-field and dropdown…

Zero structure just leads to lots of shitty issues that have no information on what version of the software it was against, no reproduction steps, and no stacktrace or debug output. I'm tired of closing issues with "I cant reproduce at all, maybe you're on an old version? Anyway feel free to open a new bug if you ever come up with a reproduction step..."

A simple optional field to include the version number that the issue was being reported against would do wonders for my interaction with users.

And you don't need to include that on your software project, but really if our users can't be bothered to tell us what version they're running, I have many, many other issues to fix which I know are broken in master.

Which I guess is the difference. If you're a small project with few users, then the handful of bug reports you get are useful and you want a zero barrier.

I have literally thousands of bug reports, hundreds of those will be left without ever being fixed (even though they may be perfectly legitimate). I have to triage. If a user is blocked by not being able to tell me what version they are running then that pre-triage of making them not even bother to cut a ticket with bad information is useful because then they don't waste any of my time...

Re: Dear GitHub

#163

Post by sondr3 »

imtringued wrote: post #161
ggreer wrote: post #137

Earlier quoted context omitted.

I maintain a C repo[1] and user idiocy is much lower than what I've seen in JS projects of similar popularity. Still, I agree with these criticisms of GitHub. I hate +1 spam enough to delete such comments. Sometimes I even ban those who do it. I'm frustrated by people who open idiotic issues[2][3][4][5]. I procrastinate on bad pull requests because my options are: 1. Close the PR with little or no comment. People the…

About number 5. I don't see anyone complaining about anything.

True, but it's still user problems that aren't problems with the software itself. Far too often you get people who want help with _everything_ on a project, from installing the right language, their editor and so on when it's not something that really concerns you.

Re: Dear GitHub

#164

Post by dmethvin »

Permit wrote: post #142

This first request is the anti-thesis of GitHub's simple approach: >Issues are often filed missing crucial information like reproduction steps or version tested. We’d like issues to gain custom fields, along with a mechanism (such as a mandatory issue template, perhaps powered by a newissue.md in root as a likely-simple solution) for ensuring they are filled out in every issue. Every checkbox, text-field and dropdown…

It can be as simple as a text file that is dropped into the content-free TEXTAREA that currently greets new issue reporters. Try running a big project like jQuery, Angular, or Babel and you'll understand how important a feature like this would be.

Re: Dear GitHub

#165

Post by hk__2 »

zzzeek wrote: post #141

We need world class, modern, distributed bug tracking now. If you google around for this technology, a lot of nice ideas, many using git itself as transport, were poking around, and around 2009 they started falling silent. Why? Because GitHub started up and everyone just buzzed over to it like so many moths to a flame, having learned nothing from places like Sourceforge about what happens when 90% of the open source…

> We need world class, modern, distributed bug tracking now.

Why distributed? You need a central place to report bugs and track them to ensure they’re not duplicated everywhere.

Re: Dear GitHub

#166

Post by beshrkayali »

Sir_Substance wrote: post #123
beshrkayali wrote: post #73

I do like Github, and I understand how it makes the entire process of maintaining a code repo a lot easier, but what I'd genuinely like to know is why don't big projects just move to their own thing? I understand that there isn't a single solution that exactly matches what Github has, and that maintaining your own git server + git management/issues/etc.. app is a pain, but I see it as the only real solution. Developi…

>but what I'd genuinely like to know is why don't big projects just move to their own thing? Github is a great advertising and marketing platform for large OSS projects. Quite the opposite, large projects should be moving towards github, because it's a great stage for them to perform on. On top of that, it's rather become the defacto replacement for sourceforge (sorry FOSShub, it was a bold try), with all that implie…

The reason why I thought bigger projects would be more capable of handling this is because team size = more manpower obviously.

> Quite the opposite, large projects should be moving towards github, because it's a great stage for them to perform on. On top of that, it's rather become the defacto replacement for sourceforge.

Not exactly sure what they're supposed to perform better/easier on a shared-hosting locked-in platform. If it's the issue of getting people excited about the project to want to use it or join in and help, it'd be interesting to see if there are any numbers to back this up.

I'm not sure about sourceforge but i never thought of it as a serious thing for big project hosting before github came around.

> It incentivises people towards public grandstanding on creative and technical issues, and encourages resolving disputes by forking the repo, burning bridges and splitting the dev team rather than discussing all aspects of the problem, chewing it over and making a group decision.

Totally. This is a good point I think. I never understood the fascination with obsessive forking (edit: lol, after the letter moved to github it got 2 forks! WHY! https://github.com/dear-github/dear-github) just to apply a patch or change a line of code (there's a lot of those). It's a nice feature and all, but not really that useful imo. I'd like to see some data on forks that haven't been touched as well, amounting to garbage, outdated code basically.

> ... throwing up a kallithea repo (if they don't just use DCVS the real way) and a dokuwiki and then knuckling down to business...

The thing that bugs me the most about Github and the likes is this. It's slowly taking away the will or need to do this. Same as how the use of Slack/Gitter has somewhat eclipsed IRC in OSS world. From my experience, I learn a lot when I'm doing things I don't really want to do or I find tedious because I either discover that there's a detail that I don't understand well or it motivated me to write an automator to sort things out.

> so maybe I'm just pointlessly resisting the tide of the inevitable or something.

Wait until the fixation on cloud crap washes off and everything will be back to normal lol.

Re: Dear GitHub

#167

Post by treve »

jasode wrote: post #45

The bullet points of complaints feel like a continuation of Linus Torvald's refusal of github pull requests in May 2012.[1] Taken all together, it seems like github is on a path of alienating their most valuable members. Github was unresponsive to Linus' feature requests and it turns out that theme continues almost 3 years later. If github plans to evolve into a full-featured ALM[2] like MS Team Foundation or JIRA in…

I don't see anything wrong with going after the massive amount of smaller project with simple needs, instead of the few large projects & popular projects with very specific needs.

If github evolves to the projects you're mentioning, you'll surely alienate the many more casual users. I personally hate working with the bloated applications you mention.

Re: Dear GitHub

#168

Post by hendry »

zzzeek wrote: post #141

We need world class, modern, distributed bug tracking now. If you google around for this technology, a lot of nice ideas, many using git itself as transport, were poking around, and around 2009 they started falling silent. Why? Because GitHub started up and everyone just buzzed over to it like so many moths to a flame, having learned nothing from places like Sourceforge about what happens when 90% of the open source…

Suckless have discussed this several times and have fallen back to an email mailing list.

http://lists.suckless.org/dev/1201/index.html#msg10574

Last one proposed by someone: http://lists.suckless.org/dev/1504/26210.html

Re: Dear GitHub

#169

Post by pvorb »

pvorb wrote: post #125

The problem is that GitHub has a monopoly and is considered _the_ current standard for Open Source. But I think that once some of the major projects move to alternatives like GitLab (which has many of the features described in that letter) GitHub will have to obey its user base. Unfortunately no Open Source project with a large user base will dare to do the first step.

I went ahead and created an account on GitLab.com. So far I can tell the transition is seamless. You can import a repository from GitHub with only a few clicks. Issues will be inherited, but the single PR on the repo I tried to migrate got lost on the way.

Re: Dear GitHub

#170

Post by beshrkayali »

tyre wrote: post #94
beshrkayali wrote: post #73

I do like Github, and I understand how it makes the entire process of maintaining a code repo a lot easier, but what I'd genuinely like to know is why don't big projects just move to their own thing? I understand that there isn't a single solution that exactly matches what Github has, and that maintaining your own git server + git management/issues/etc.. app is a pain, but I see it as the only real solution. Developi…

> I understand that there isn't a single solution that exactly matches what Github has, and that maintaining your own git server + git management/issues/etc.. app is a pain You outlined exactly why people don't build their own or use another system. Github is the best there is. That doesn't mean it doesn't have problems, but if your company/project/expertise isn't focused in collaborative development and/or version c…

> Github is the best there is.

Doesn't matter really as it's still a locked platform. The argument they're making is that they're developing in the open and they'd like some sort of expedited treatment because of the size of the project or because they're doing OSS. I don't think those two can go hand in hand all the way.

Post reply on HN