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

191–200 of 491 posts

Re: Dear GitHub

#191

Post by monkmartinez »

hk__2 wrote: post #165
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.

I am not Michael Bayer (but I hope to be more like him someday)... that said, what I think he means or could mean is that issues would be distributed along with the repo. Maybe something like a git log for issues that are attached to and/or part of the repo itself.

Thinking about it, something like this would be sweet. I would immediately have a snap shot of things that might go boom when I run said software. eta: Instead, I have to go dig through github itself, which is slow compared to greping through a git log.

Re: Dear GitHub

#193

Post by timv »

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…

But the big thing that GitHub doesn't use GitHub for is interacting with the masses.

- GitHub doesn't use GitHub issues to take feature requests or bug reports.

- GitHub doesn't use Pull Requests to allow users to submit bug fixes

When all your issues and pull-request are being raised by a defined set of people who are (or ought to be) committed to the same collective goal (because they're employees of the same company) you can develop a culture and norms around how those things work.

If "Some Guy" at GitHub raises issues where the only description is "This feature doesn't work on Mac" or raises PRs where the only description is "this fixes a bug I found" the cultural pressure would teach him/her that's not how things are done, and if the lesson wasn't learned, then they wouldn't last at GitHub.

When the people you're interacting with are infrequent contributors, it's a different scenario. They need guidance. They need to be pushed to go down the helpful path on their first attempt, because there are too many new contributors and they often don't stick around for long enough to change behaviours by osmosis and cultural pressure.

Re: Dear GitHub

#194

Post by teen »

I actually disagree with some of these suggestions, I find the simplicity of Github issues is what makes it so great. I think this should be solved with 3rd party tools, such as waffle.io

Re: Dear GitHub

#195

Post by teen »

I actually disagree with some of these suggestions, I find the simplicity of Github issues is what makes it so great. I think this should be solved with 3rd party tools, such as waffle.io

Re: Dear GitHub

#196

Post by notabot »

My company pays me to work on a fairly old-school free software project and we run our own git service. Our workflow is email based so we won't ever consider switching to GitHub.

That said, we do sometimes consider setting up an official mirror on GitHub. Ideology aside (some team members might think we shouldn't promote a propriety solution for free software project), the main thing that puts us off is that there is no way to disable pull requests. Closing all pull requests by hand is not appealing; leaving all pull requests open is not desirable. We can probably write a bot to close pull requests, but that is just yet another administrative burden.

Not sure if GitHub will ever consider allowing users to disable pull requests though. That seems to go against GitHub's core interest.

Re: Dear GitHub

#197

Post by daurnimator »

maxaf wrote: post #78
ketralnis wrote: post #58

Earlier quoted context omitted.

I think it's just monkey see->monkey do. As soon as one person said +1, everyone that saw it thought that that's just how you voted for stuff. It's the same reason you see comments on HN or reddit that just say "This." or that if you leave your shoes by the door, everyone else will do the same. I doubt these people keep doing it if you ask them not to.

There's an old story about this man who stood quietly next to a closed door in Moscow, said nothing to no one, and did nothing else of interest. Eventually others joined him, and before long a queue has formed. No one knew what they were standing in line for. Monkey see - monkey do.

I remember one day I was walking through london with multiple hours to kill; and there was a massive line. Without anything else to do, I just stood in it. Approx 45 minutes later, I got to the front: turns out it was a sale for a clothing store. I didn't really need any clothing, but the discounts were good; so I purchased a jacket. This was 6 years ago and it's still my favourite jacket....

Re: Dear GitHub

#198

Post by beshrkayali »

beshrkayali wrote: post #181
curryst wrote: post #107

Earlier quoted context omitted.

It's a momentum thing I think. A big part of the Github platform mirrors a social media platform. When you meet a developer, you check out what they're up to on Github just like you might check on a friend's status on Facebook. Like Twitter, it's a way to get your name out there. Also, I don't want to have to maintain an account on a Gitlab (or equivalent) server for every project. Anyone who has enough interest to t…

> Also, I don't want to have to maintain an account on a Gitlab (or equivalent) server for every project. Anyone who has enough interest to troll through issues on a project or open an issue already has a Github account. It lowers the barrier to entry for your project. There are multiple ways to go around this, OpenID, Mozilla Persona, or any third-party authenticator. > The final thing is just name recognition. Peop…

I just realized that Persona is going to be discontinued. Unfortunate, but alternatives can be whipped up I guess.

https://developer.mozilla.org/en-US/Persona

> On November 30th, 2016, Mozilla will shut down the persona.org services. Persona.org and related domains will be taken offline.

Re: Dear GitHub

#199

Post by monkmartinez »

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…

I actually hesitate to really "watch" repos because the sheer volume of email generated is staggering. I take my hat off to those who run successful OSS projects. Thank you!

Re: Dear GitHub

#200

Post by mschuster91 »

dragonsh wrote: post #126
fweespeech wrote: post #108

Earlier quoted context omitted.

Yeah, I'd honestly like for a website that actually focused on "Social Coding" rather than the Enterprise Money that GitHub is focusing on. Tbh, that is what GitLab, Bitbucket does also which is why they really are only effective as replacements rather than improvements upon. I wonder if threads like this keep popping up if people will say "Fuck it" and build an OSS Github clone that focus on being the Reddit of Code…

Recently even Python language planned to move its repositories to github.com for network effect, instead of helping projects like kallithea SCM and trac by partnering with software conservancy or gnu. Python should learn a lesson when they decided to move their repository to closed source system like github. But obviously as people use Facebook, developers use github for the same reason, network effect. I hope they c…

> and trac

Because, honestly, trac just sucks. It ain't as bad as the stuff Atlassian sells but still... it tries to be a fusion of MediaWiki and Bugzilla, and eh nope.

Post reply on HN