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

231–240 of 491 posts

Re: Dear GitHub

#231

Post by jessaustin »

scrollaway wrote: post #227
jessaustin wrote: post #220

Earlier quoted context omitted.

Yes it is fairly bizarre that Github don't dogfood the issues function. I'm sure they have an internal system that they prefer, but even that internal system could have a public interface. Also, if the internal system is superior then its superior features could be added to the public system so that we could all benefit.

Where are you getting that they don't dogfood the issue tracker? It's a private tracker (private repository) but from what I've seen in the Github blog, they do... it wouldn't make much sense if they didn't.

If they're using it, they're doing so in completely different fashion than everyone else. That is, it's not public for viewing, submitting, commenting, etc. Indeed TFA indicates exactly the sorts of pain points that would be missed by those using the tool in such a radically different way than everyone else. If someone at GH had to wade through all the damn +1's then something would have been done about them years ago.

Re: Dear GitHub

#232

Post by deckar01 »

jhchen wrote: post #152
jonobacon wrote: post #116

Hi Adam, Addy, Andreas, Ariya, Forbes, James, Henry, John-David, Juriy , Ken, Nicholas, Pascal, Sam, Sindre, My name is Jono and I started as Director of Community back in November at GitHub. Obviously I am pretty new at GitHub, but I thought I would weigh in. Firstly, thanks for your feedback. I think it is essential that GitHub always has a good sense of not just what works well for our users, but also where the pa…

Promises about the future about Github’s roadmap is understandably difficult to make, besides by a very small number of people at the top. I don’t think this is the expectation. But visibility into past failure to address these concerns and the current status is long overdue. I assume when these maintainers reached out in private channels, they were equally detailed, and have waited years. At present, I’m not sure ho…

GitHub has settings for individual repos. People can opt to turn the issue tracker off completely.

Why not have the option to enable issue voting? It could be as easy as stars for issues.

Custom issue instructions would be trivial to tuck away in the settings page or associate with a specially named markdown file. They turn a wiki on by default, but you can't instruct users about the info you expect in their issue on the page where they create the issue. Documentation is very effective when it is inline with the system it is describing.

Custom issue fields with validation is a little more complex. Punt.

Re: Dear GitHub

#233

Post by zanny »

Killswitch wrote: post #221
dragonsh wrote: post #210

Earlier quoted context omitted.

@jono Will you be able to answer, if github has any plans in the roadmap to open source the code in 1-2 years and develop in open instead of closed rooms. Given many open source project adopting it for their code repository its important question to be answered. Otherwise sourceforge.net story will repeat again, this time with github. Many projects adapted it when it was closed source and then when they open source i…

Problem with them open sourcing their platform is that the platform base is used in enterprise and how the bulk of their revenue is made... Who wants to buy milk when the cow is being given away?

They are getting hosting deals for many of these companies themselves. Why spin up your own github clone when you can just use github?

And gitlab is now 99% feature-compatible with github. If you aren't using the developer ecosystem of github.com, you are not missing much using the free software option already.

Re: Dear GitHub

#235

Post by zanny »

Osiris wrote: post #173

The author mentions that if GitHub was open source, they would implement these features themselves. Gitlab[1] is an open source repository manager that supports local installs as well as public hosting at gitlab.com. If author appreciates open source, perhaps they should put their efforts into improving an existing open source option rather than relying on a proprietary solution. [1] https://gitlab.com/gitlab-org/git…

This. When you are tired of github, start using gitlab, and realize your mistake going forward and stop making it, over[1], and over[2], and over[3].

[1] http://sourceforge.net/

[2] https://code.google.com/

[3] https://bitbucket.org/

Re: Dear GitHub

#236

Post by foota »

grey-area wrote: post #187
krschultz wrote: post #130

Earlier quoted context omitted.

An open question is how the community should provide feedback. Trello provides a decent example of how to do it well [1], but GitHub feels like a black box. I've been on GitHub since 2008 and I have been paying every month for years, but other than emailing support I have no idea how to vote for a feature request. My personal pet peeve is not being able to mark a public repo as 'deprecated'. There are a lot of other…

An open question is how the community should provide feedback. Perhaps if Github used their own issues system to gather feedback on Github itself, they'd more rapidly improve it. I'm sure they'd feel a lot of these pain points in a far sharper, more visceral way if they were subjected to them daily.

But then they'd be spammed with useless +1 comments

Re: Dear GitHub

#237

Post by zanny »

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…

Problem is for that system you need per-user authentication mechanisms to verify the interacting party in a bug report. If you can't do that, people can impersonate project members and you're going to have a bad time. Centralized issue tracking is not winning because of implementation details, its winning because you need some central authority to verify people are real and who they say they are.

You would have to sign off every message in a git log tree with a personally authenticated gpg key that can be found in a public keyserver everyone trusts.

Re: Dear GitHub

#238

Post by noir_lord »

jonobacon wrote: post #146
electic wrote: post #135

Earlier quoted context omitted.

As a software engineer, I am reminded of when I go to Home Depot and ask someone for help and they say, "Oh, I do not know. I am new here...". I think it is best to come prepared with the right answers. As you can see from the doc, there are a lot of maintainers who have signed this. Perhaps: - Note the feedback. - Bring in the right folks to consult with on your end. - Write a public response with concrete informati…

My main goal in responding was to acknowledge the issues. This is just the start of the process, and by no means the end. The next step, as you mention, is to bring the right people in. This is why I want to ensure this is raised with our teams inside GitHub to explore ways to rectify some of these concerns.

You did the right thing, fast feedback of "We are looking at it" is often better than later feedback of we did "X".

Linode could take a leaf out your book in terms of dealing with people not entirely happy (if I'm been kind) with the way they deal with stuff.

Re: Dear GitHub

#239

Post by zanny »

tholford wrote: post #87
rhinoceraptor wrote: post #22

Earlier quoted context omitted.

The same reason YouTube is so popular. Neither GitHub or YouTube are big because of their technology, it's their community that keeps people there. It's a huge tax on attention and contributions if a project decides not to use GitHub. There are many GitHub replacements but none of them have the community of GitHub.

Playing devil's advocate - in their respective heydays, SourceForge and Google Code both seeemed unassailable. They had large, active communities that hosted the most popular OSS projects. Could the same thing happen to GitHub?

But it requires feature expansion on the scale of github, and a perpetual decline and ignorance of the community on the parts of the current host for years for that kind of transition to happen naturally.

That, and github has centralized development to a degree that sourceforge or gcode in 2008 could only dream of. It not only obsoleted other hosting solutions but also brought millions of developers into these kinds of development ecosystems whom used to just use forums or their own personal websites to host their projects.

Post reply on HN