Live data from Hacker News

Dear GitHub

github.com

371–380 of 491 posts

Re: Dear GitHub

#371
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…

This. I'm a big fan of Github, but it bothers me that this single service is the centerpiece of most OSS projects. We see it every time Github goes down and virtually nobody can be productive anymore. I hope to see a version control system on top of IPFS some day.

Ironically, git itself is decentralized. More effort should go into decentralized software architectures, especially in the current security climate where having a central point of failure is like having a virtual bull's eye for bad guys. There's no reason you couldn't have a decentralized issue tracker for example.

Re: Dear GitHub

#372
post #281
post #276

Earlier quoted context omitted.

gitlab.com is dog slow and my code is too important to risk self hosting.

Deploy on Heroku

Installing it on Heroku is not an option because their containers do not allow the disk access GitLab needs to store and manage the git repo's. source: https://www.quora.com/How-much-of-a-threat-is-GitLab-to-GitH...

Re: Dear GitHub

#373

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.

It's much better for Jono to quickly reply and ack the issue, rather than radio silence while we want for them to completly solve the issue.

Re: Dear GitHub

#374
post #370

I just created and maintain a little Android library (a very rewarding experience by the way) so most of the complaints about Github doesnt really apply to me because the size and reach of my project (I understand the point perfectly though). But I read some complaints about the users and the issues they tend to open and I fully agree. They are a minority but I can't only imagine what people with bigger projects have…

It's the nature of any issue tracker to gather low-quality feedback. The people using the product who are happy with it or who can solve their own problems mostly aren't the ones booking issues, unless there are genuine bugs. Paradoxically, a high quality project will have fewer genuine issues to report, and therefore be sensitive to a lower average quality of feedback.

Re: Dear GitHub

#375
post #331
post #43

Earlier quoted context omitted.

GitHub's success is based on its community. Simple fairness says the community should be respected and listened to, simple business says if the community doesn't get something back, it will get pissed and go somewhere else.

Again... No thought of how all this gets paid for?

By GitHub obviously. Improving their platform to maintain their momentum as a community hub is pretty much a no-brainer as far as I'm concerned.

Re: Dear GitHub

#376

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…

@Sir_Substance - thank you for the kind mention. I agree with you but don't forget that any Empire will fall sooner or later. People work with enthusiasm at a new project, after a while this new excitement is replaced by greed because the financial thing becomes the most important aspect. At this stage I would say that GitHub is Google, SourceForge is Yahoo and FossHub aims to become DuckDuckGo. We need to improve so instead of throwing us at garbage we would appreciate a constructive criticism. Thank you!

Re: Dear GitHub

#377

I'd settle for just a fix to the (minor) data-loss bug that I reported nearly a year ago, and which still crops up once a month or so. That, and something for code review. Pull Requests are terrible for code review, and it wouldn't take that much to make them so much better.

I got frustrated waiting for improved PR code review, so I built https://reviewable.io . It's best suited for private repos (since there's a learning curve that make throw off potential open source contributors) but it addresses a lot of the issues with PRs. Take a look!

I've actually looked at Reviewable multiple times for use within our team, but never decided to use it. From my usage of the demo, it feels complicated. There are a lot of controls on the screen, and I struggle to tell what exactly I'm looking at at any given time.

I also tried the demo, and was shocked to see that Reviewable had edited our PR descriptions to include a big "Review on Reviewable" badge. We currently make heavy use of PR descriptions in quite specific formats, and it felt like Reviewable was forcing itself upon us.

To be clear, I'm really glad someone is looking at this problem, and Reviewable looks like a step in the right direction. I'm just quite opinionated on code review and developer tools, and I feel like it could be much better.

Re: Dear GitHub

#378
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…

I wrote a little bit about this two years ago: https://sny.no/2014/04/dbts

There’s not necessarily an antagonism between distributed and centralised in this case. You can still have a centralised frontend such as Github Issues, backed by a versioned and distributed backend using i.e. git.

Re: Dear GitHub

#380

While I applaud the initiative, it's also a pretty strong indictment of the JavaScript / node.js community that there is not even a single non-male OSS maintainer on this list of important JS projects. What is being done in the JS community by those who lead it to make progress on this and who is leading that charge? If the answer is "Nobody", why is that true?

Tell us, why does the gender matter in this debate? Sounds rather sexist to me.
Post reply on HN