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

381–390 of 491 posts

Re: Dear GitHub

#381

Post by rmc »

pekk wrote: post #287
Estragon wrote: post #277

Earlier quoted context omitted.

Maybe something more noble than a social coding site? I doubt it. Github has a reputation problem. I wouldn't put anything sensitive on there, given the attitude github leadership showed about privacy ethics in the Julie Horvath incident.

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…

It's the "etc" that allows you to remove "retard".

Re: Dear GitHub

#382

Post by aws_ls »

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

Distributed is the key word. Blockchain/Bitcoin (not withstanding the hurtful politics ongoing at present) has shown the way, and ideally most shared/social things should work in a distributed, trust-less environment in future. Including Social networks and Search Engines.

So it is quite natural, that OSS developers can pave the way for shared/distributed source control (a protocol on top of GIT. Just like HTTP is over TCP).

Just to clarify, I don't hate github. But it sort of obscures the beauty/advancement that is GIT, over previous version control softwares. Wonder what does the creator Linus think of this?

Re: Dear GitHub

#383

Post by piotrkaminski »

danpalmer wrote: post #377
piotrkaminski wrote: post #222

Earlier quoted context omitted.

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 m…

Thanks for checking out Reviewable, and sorry it didn't work out for you. It's definitely a more complex tool than plain PRs but you also get a lot more functionality in return.

If you checked it out before I added the interactive onboarding (aka butterflies) and on-demand help you might want to try (yet) again, since I've been told it makes it a lot more approachable. Otherwise, and if you have the time, I'd love to sit down with you (virtually or otherwise) to do a short user study so I can better understand the UX pain points and maybe fix them.

As for the badge, it's actually mostly there to help developers find their way to the review. In public repos, it's also the marketing payment for the otherwise free service, but in private repos I can switch it off for you (the flag doesn't have a UI yet).

I'm always looking to improve Reviewable, but in the end it's unabashedly opinionated too, and sometimes those opinions will clash -- I'm OK with that. I'd rather make a tool that some people will love than an enterprise monster that everyone will love to hate. :)

Re: Dear GitHub

#384

Post by notabot »

justincormack wrote: post #366
notabot wrote: post #196

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…

FreeBSD has worked out a means of accepting pull requests on their github mirror, guessing using the API.

I myself don't really see any motive of doing that. It is administrative burden (maintaining the service that bridge API and existing system, managing GitHub accounts / tokens). Compare that to the number / quality of pull requests received [0] [1] and I find RoI of doing that very low.

[0] https://github.com/freebsd/freebsd/pulls [1] https://github.com/torvalds/linux/pulls

Re: Dear GitHub

#385

Post by yAnonymous »

seivan wrote: post #344
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…

Not sure you'll read this but I'd love a tagging feature for starring. Sorting on code isn't good enough.

+1

Re: Dear GitHub

#387

Post by anarazel »

jondubois wrote: post #364
rco8786 wrote: post #64

Earlier quoted context omitted.

The request was to allow maintainers to define a template or have the ability to add fields. So the formats would be on a project by project basis. > Maybe if your software was better designed, people wouldn't be asking the question to begin with. This is just silly.

Not so. For my project, I noticed on several occasions that different people were asking the same questions and that prompted me to rethink the design of the project a bit and it greatly improved the community engagement as a result.

Sure, sometimes that's the case. In many other situations it's just people being almost comically lazy.

Re: Dear GitHub

#389

Post by Rovanion »

lwf wrote: post #275
scrollaway wrote: post #207

Earlier quoted context omitted.

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

Ubuntu has actively moved away from directing users to Launchpad to report a bug from a crash, and instead moved towards reporting to a crash database where they're triaged by actual developers. Debian, in a similar vein, doesn't even have a web form to report bugs. As a result, almost every bug I've gotten on a Debian package has been clueful. At the very least, I know what version of the software they're running. I…

Thank you for your time spent on Debian!

Re: Dear GitHub

#390

Post by DouweM »

Rovanion wrote: post #386
donretag wrote: post #305

Earlier quoted context omitted.

+1

If one implemented issue voting then a +1 comment could automatically be converted into a vote.

Which is almost exactly what happens on GitLab: https://twitter.com/gitlab/status/687930087057027073

Users can use those buttons to +1 or -1, and any comments that contain nothing but an emoji (like `:+1:`) are automatically converted to emoji awards, as we call them.

Post reply on HN