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

291–300 of 491 posts

Re: Dear GitHub

#291

Post by mintplant »

monkmartinez wrote: post #191
hk__2 wrote: post #165

Earlier quoted context omitted.

> 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: In…

You've described Fossil.

http://fossil-scm.org/index.html/doc/trunk/www/index.wiki

Re: Dear GitHub

#292

Post by ams6110 »

jasode wrote: post #177
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…

> adds cognitive overhead to the process Yes! The maintainers deliberately want to add cognitive overhead so the quality bar for creating issues is higher. By having simple zero-friction forms, you haven't removed cognitive overhead. You've simply shifted the cognitive load into the followup messages asking for clarification of "reproduction steps", "version tested". The issues' threads therefore begin with "meta" ty…

So use a real issue tracker. Most of the big ones integrate with github. Why should they reinvent this wheel?

Re: Dear GitHub

#293

Post by clinta »

simoncion wrote: post #283
clinta wrote: post #266

Earlier quoted context omitted.

One concern would be around tools that fetch from github automatically. go get for example would need some sort of structured metadata if it wanted to surface an error to a user that a library is deprecated.

> One concern would be around tools that fetch from github automatically. Sure. But... like... git doesn't know anything about deprecated repos. AFAIK, that's not a feature of git's repo fetch machinery. Anything Github would do to address this would have to modify the contents of the repo, right? > ...go get for example would need some sort of structured metadata [to do reasonable repo deprecation warnings] I mean,…

Go get does not start with a git clone. If you go get example.org/pkg/foo go fetches https://example.org/pkg/foo?go-get=1. So coordination between go and github could implement something for deprecated repositories without changing anything in git.

More details here: https://golang.org/cmd/go/#hdr-Remote_import_paths

Re: Dear GitHub

#294

Post by ars »

ywecur wrote: post #278
ars wrote: post #241

Earlier quoted context omitted.

He might think he's testing conformance, but he actually just tested curiosity.

Wouldn't they at least ask after a while if that was the case?

What makes you think they didn't? I saw lots of people look up, check the people around them and keep going.

Re: Dear GitHub

#295

Post by simoncion »

clinta wrote: post #293
simoncion wrote: post #283

Earlier quoted context omitted.

> One concern would be around tools that fetch from github automatically. Sure. But... like... git doesn't know anything about deprecated repos. AFAIK, that's not a feature of git's repo fetch machinery. Anything Github would do to address this would have to modify the contents of the repo, right? > ...go get for example would need some sort of structured metadata [to do reasonable repo deprecation warnings] I mean,…

Go get does not start with a git clone. If you go get example.org/pkg/foo go fetches https://example.org/pkg/foo?go-get=1 . So coordination between go and github could implement something for deprecated repositories without changing anything in git. More details here: https://golang.org/cmd/go/#hdr-Remote_import_paths

> Go get does not start with a git clone.

Fair enough. (I don't use go, so I'm unaware of pretty much all of its internals.) [0]

> ...coordination between go and github could implement something for deprecated repositories without changing anything in git.

A couple of things:

* This only fixes things for Golang. It doesn't fix it for the couple-thousand other tools that pull things from Github.

* I never suggested changing things in git. That would be freaking nuts. :) EDIT: Or did you mean "without changing anything in the git repo"? If you meant that, then I strike this bullet point and apologise for the noise. :)

* Frankly, having a well-known file in your Git repo that contains meaningful tags seems far more compatible than changing git, or altering the $BUILD_TOOLGitHub integration... for one thing, the convention could be trivially adopted by non-git users. :)

[0] Thanks for the documentation link, BTW! :D

Re: Dear GitHub

#296

Post by brooklyndavs »

lamontcg wrote: post #162
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…

This is very true. While clunky to use most support sites for enterprise software includes these types of fields as mandatory to complete a support ticket.

As someone who has opened issues myself on projects in gitHub its easy to be unaware or even forget all the information a maintainer would need to reproduce the issue. As someone who uses an open source stack every day anything to make the whole issue flow better for maintainers and users I'm for 110%

Re: Dear GitHub

#297

Post by mintplant »

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 may take cognitive overhead away from the submitter but it shoves it onto the maintainet at the same time. Instead of 100 people having to deal with 1u of cognitive overhead each, you have 1 person having to deal with 100u or more to extract information from the submitters.

Re: Dear GitHub

#298

Post by billconan »

One annoying issue I found with github is that it doesn't provide a discussion board. a lot of times, I have a question to ask, it doesn't mean I found a bug or anything needs progress tracking, but I have to go through the "github issues".

Re: Dear GitHub

#299

Post by ggreer »

shurcooL wrote: post #282
ggreer wrote: post #171

Earlier quoted context omitted.

Maybe "complain" is too strong, but he created a GitHub issue –notifying several hundred people– without running ag --version. Heck, he didn't even look at the output of his command. It was immediately obvious to me, from the limited information he provided, that it was a bash alias.

Do you really want people to be afraid to report an issue in case it's something silly/not an actual problem? Would that be better? I guess it depends on the project and its contribution guidelines.

> Do you really want people to be afraid to report an issue in case it's something silly/not an actual problem? Would that be better?

I seriously doubt the pendulum will swing too far in the opposite direction. Right now, the majority of created issues are close to useless. If those people took five minutes of their own time to troubleshoot, it would save others hours.

Re: Dear GitHub

#300

Post by dragonsh »

scrollaway wrote: post #207
dragonsh wrote: post #126

Earlier quoted context omitted.

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…

> instead of helping projects This isn't how it works. You don't help projects by pretending the football-stadium-sized issues with them don't exist and using them despite their flaws. Trac is an awful, awful piece of software. It's awful to set up, to use, to maintain, to gather feedback from, it's awful for just about everything. If in some very weird parallel universe it gathered even 1% of the following that Gith…

Look at diagoproject.com's ticket triage. They moved repository to github.com but cannot move issues there. It's built on trac and works. I am sure github.com will take ages to do such thing. Indeed even Python needs to rely on roundup for issues tracking. Now the developers will be more miserable since issues won't directly link to commits or changes which is loss of integrity.

Also from a ethical point of view it's wrong to trust for profit commercial closed source for community driven open source work. I am sure history will repeat and github.com will become future sourceforge.net.

Post reply on HN