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

421–430 of 491 posts

Re: Dear GitHub

#421

Post by zAy0LfpBZLC8mAC »

What I don't get ... why do people building free software even consider forcing their users and in particular their contributors to use proprietary development tools such as github? (Or, for that matter, exclude people from contributing to their projects who only use free software.)

Next, we'll see public complaints to Microsoft because MS Word doesn't properly support the way they want to maintain their project's documentation?

I mean, sure, feel free to complain all you like, but how is this not exactly what was to be expected from the beginning, and why do you expect them to care in the future, given that you just seem to have realized that they didn't care in the past, for obvious reasons, and given that their incentives haven't changed, and there is no reason for them to change in the future?

Re: Dear GitHub

#422

Post by alfonsodev »

sqs wrote: post #280

At Sourcegraph, we're trying to help solve these problems for developers everywhere ( https://sourcegraph.com ), both in open source and inside companies. GitHub’s commercial success and contributions to the world of development are impressive (and I'm speaking as a GitHub user for 8 years), but they can’t build everything developers need on their own. We’re really pumped about improving dev team collaboration in the…

I think reactions as implemented in Facebook, Slack or Sourcegraph is a really neat UX solution for the +1 spam problem.

Re: Dear GitHub

#423

Post by nyan4 »

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…

Bugs Everywhere was one of the leading distributed bug trackers. They don't seem to be gaining any traction unfortunately.

http://www.bugseverywhere.org/

Re: Dear GitHub

#424

Post by alfonsodev »

athenot wrote: post #48

I have mixed feelings about these requests. Yes it would be nice to have these extra features in GitHub. Its issue handling has always been a bit light on the workflow side—but IMHO has made up for it with a pleasant way to organize conversation around issues. The simple and smooth UX is part of what makes GitHub so great. For the opposite side of the spectrum, there's the Bitbucket+Jira combo. It is customizable to…

I have mixed feelings about custom fields, I'd like Github UI to become as burden as Jira, but in the other hand 'reactions' as Slack or Facebook are implementing would make much easier to follow a discussion without so much scroll down.

Re: Dear GitHub

#425

Post by jessaustin »

vmarsy wrote: post #180

A lot of these points are fair and interesting, but I fail to grab some of the points, especially that one: Ability to block users from an organization. What does blocking users mean? Blocking from commenting/making PR/cloning? Why blocking a whole organization from an open source project? What would prevent such users to use a personal account instead to do what they organization counterpart is blocked from anyways?

A more plausible interpretation would be that a particular GitHub organization might wish to block the inputs of a particular user across all its projects. That is, the phrase "from an organization" is adverbial and clarifies "block" rather than "users".

Re: Dear GitHub

#426

Post by talmand »

pron wrote: post #324
pekk wrote: post #287

Earlier quoted context omitted.

Even if you don't have anything against Github relating to the Horvath incident, there are other things like Github shutting down people's projects because they wrote a doc containing the word "retard." In other words, now they are in the business of regulating the content of open source projects (beyond obvious precautions like not hosting stolen credit card databases, child porn, etc.) They seem to think they're to…

> now they are in the business of regulating the content of open source projects That is a very good thing. At this point in time we're beyond speculation. We have some good evidence about the direction online communities take with and without content moderation, and the serious players (most recently Reddit) have come to realize that top-down moderation is absolutely necessary. Fringe, unmoderated activity has a pla…

And who exactly gets to decide what is "fringe"?

Re: Dear GitHub

#427

Post by zzzeek »

mintplant wrote: post #291
monkmartinez wrote: post #191

Earlier quoted context omitted.

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

yes, fossil, you need to get me past this:

http://fossil-scm.org/index.html/dir?ci=acbee54e8ba8a3bd&nam...

I'm talking about a portable issue tracker format that ideally uses something like git as its transport (but note: this does not mean that the issue database would travel along with the application's source code! That might be nice as an option but not by design). command-line and web-based front ends can then refer to it. Fossil, OTOH, looks like a huge monolithic web application / version control system / issue tracker / kitchen sink written in very hard-coded C.

Looking through some docs, Fossil is anti-git and it claims its own DVCS is a great improvement over git: http://fossil-scm.org/index.html/doc/trunk/www/quotes.wiki. Because Fossil has every possible feature packed all into one monolithic executable, rather than relying upon existing systems like diff, patch, etc. this means Fossil is "the opposite of bloat": http://fossil-scm.org/index.html/doc/trunk/www/qandc.wiki (in fact that is the opposite of the opposite of bloat....)

Re: Dear GitHub

#428

Post by fweespeech »

cookiecaper wrote: post #334
jeddawson wrote: post #317

Earlier quoted context omitted.

Ditto. Maybe 98%. I think that's a big part of the disconnect I'm seeing here in the comments. Those of us that live in private repos are likely pretty happy with how things currently work especially since we're the ones paying to use the service. If it wasn't working well for our teams, we'd find somewhere else to spend our money. That being said, we're certainly the minority when it comes to users on the platform.

>That being said, we're certainly the minority when it comes to users on the platform. But you're the huge majority of people who give GitHub money. It makes sense not to prioritize the pain points of open-source projects when you lose money by hosting them.

We don't pay GitHub precisely because they lack features we can implement in GitLab.

Much of that is due to the OP's requested features that are currently missing. But tbh, it is too late to get us to switch.

> 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.

For instance, is something we basically implemented in our local version of GitLab but aren't sharing because our implementation pulls this from internal docs other people can't use. Our CSRs put issues into GitLab but they tend to forget steps while on the phone with a user.

We wouldn't have bothered if we had something like this when I was evaluating GitLab vs. GitHub.

Re: Dear GitHub

#429

Post by felhr »

jitpack wrote: post #391
felhr wrote: 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…

Hi. your junior colleague might be interested in the security answer here https://jitpack.io/docs/FAQ/ . It's an important matter so will be happy to answer any more questions via email/gitter. You can also run JitPack on-premises and have full control over build artifacts.

Fortunately not my junior colleague! just a junior dev using my lib in his company's project. Thank you for the FAQ. I will forward it to him

Re: Dear GitHub

#430

Post by Karunamon »

Most of this stuff seems pretty common sense and reasonable. I really only have a couple of objections:

* Issue templating.

It's one thing to prefill the entry box, it's quite another to add fields that everyone must fill out. I quite like that filling out something on Github is totally the opposite of filling out something on Jira.

* Issues and pull requests are often created without any adherence to the CONTRIBUTING.md contribution guidelines

This is a people problem that has plagued open source from day one. You cannot engineer your way around it in a manner that doesn't annoy your contributors.

There was a blurb in here about getting rid of the big green "new pull request" button, but that was when this link went to a google doc. Good - if someone doesn't want to take PR's, then they have almost no reason to be on Github in the first place. Put another way, it's the mark of someone that wants a repo as a signpost of sorts without actually interacting with its community.

Post reply on HN