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

81–90 of 491 posts

Re: Dear GitHub

#81

Post by detaro »

mynewtb wrote: post #57
ben174 wrote: post #24

Earlier quoted context omitted.

By their very nature, git repos are one of the easiest things to migrate. Simply point at a new remote and push, and that's really it. It means that, unlike many other services, I could see GitHub being completely abandoned almost over night. If something better came along.

You would lose the issues.

True, but thanks to the API and their relatively simple structure it's reasonably easy to at least copy their contents as well. Linking them correctly to user accounts on a new platform is probably the biggest issue.

Re: Dear GitHub

#82

Post by msbarnett »

earlz wrote: post #67
mplewis wrote: post #13

Bitbucket kills GitHub issues with these two features: - Multiple assignees for an issue - An "Approve" button so that maintainers can stamp a PR with the seal of approval

I just wish that bitbucket's UI was half as smooth as Github. Sure, it's not terrible, but it has a lot of rough edges.

I'm completely comfortable calling BitBucket's UI/UX terrible.

Re: Dear GitHub

#83

Post by dang »

minimaxir wrote: post #52
dang wrote: post #36

Earlier quoted context omitted.

Since they're both near the top we might as well treat the later post (which is the other one) as the duplicate.

The post with ~110 points was killed in favor of the ~50 point post at the time. In that case using time as the tie breaker might not be the best since people will have to upvote again.

In general you're right, but this story was guaranteed not to lack for upvotes. Indeed it went to #1 as soon as we buried the other one as a dupe.

I realize it's not a big deal, and it's actually a great sign about the HN community that almost no one cares much about karma. But we do want to try harder to give the original submitter credit, because then the incentive is aligned with what's best for the community: finding good stories that haven't been posted yet.

Re: Dear GitHub

#84

Post by slavik81 »

aesthetics1 wrote: post #2

Each and every suggestion is a sane and much needed improvement.

I completely agree with some of these suggestions, but it doesn't need all of them. If you really need a heavily-customizable issue tracking system, you can do anything you want in Bugzilla or Jira.

Every checkbox, dropdown and mandatory field they add makes GitHub Issues less attractive to those who don't need it. Simplicity is a feature, and it's one that you sacrifice as you make your software more flexible.

Re: Dear GitHub

#85

Post by detaro »

jondubois wrote: post #54

I like GitHub issues as they are. I wouldn't like to force people to adhere to a particular format when reporting problems. I find it strange that some project maintainers get annoyed when people use the issues section to post questions. What's wrong with that? A question can reveal design failures about your software... Maybe if your software was better designed, people wouldn't be asking the question to begin with.…

Why should maintainers not get annoyed if people ignore the proper support channels (which often have a great community of users to help) and further burden the developers instead?

Re: Dear GitHub

#86

Post by Mickydtron »

ketralnis wrote: post #58
monkmartinez wrote: post #42

I do not operate a popular OSS project, but I have experienced the +1 spam and it sucks. The suggestions, in my opinion seem rational. Interesting side note: With the exception of Selenium, most of signees are maintainers of JS/HTML OSS projects. I wonder if we could objectively compare JS to projects in terms of the problems mentioned in the document. For example, there is a strong correlation between +1'ers and JS…

I think it's just monkey see->monkey do. As soon as one person said +1, everyone that saw it thought that that's just how you voted for stuff. It's the same reason you see comments on HN or reddit that just say "This." or that if you leave your shoes by the door, everyone else will do the same. I doubt these people keep doing it if you ask them not to.

I agree that that's probably how it started, but it seems that once the cultural expectation has been set, it's hard for a single project maintainer to set a different custom just for their own project. People are going to use the conventions and communication methods that they learn elsewhere, even if you say not to in the contributing guidelines document. You might be able to get individuals to stop doing it in your project by asking them directly, but then each person has done it at least once, and you've had to ask each person to change their normal habits. Besides, as they note in the letter, there is a valid and valuable purpose to these communications, it would just be better if they were in a different place than clogging up the comment thread.

Re: Dear GitHub

#87

Post by tholford »

rhinoceraptor wrote: post #22
anarchy8 wrote: post #6

I feel like there is a great opportunity right now for anyone to make a Github replacement. Sounds like a lot of these features are sorely needed at the moment. Why has Github been complacent?

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?

Re: Dear GitHub

#88

Post by dragonsh »

Look at kallithea SCM at http://kallithea-scm.org/, we have used it and in most cases it works well. Also it supports both git and mercurial. 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.

Re: Dear GitHub

#89

Post by mjevans »

neilgrey wrote: post #34

Yup, I love GH, use it every day, but issue management is the pits. It'd be really nice if I could custom sort the queue of issues so that I know what's next up in my queue of things to do; right now I've got 5 tags called NextUp:1 -> NextUp:5 on each repo; this takes way more manual updating than a simple drag/drop widget. Like they mentioned, having a voting system would be super useful for knowing what matters --…

I agree with voting.

I also think that voting systems should only have /positive/ inputs. (I agree with the content of a given statement/post). Negatives belong as a concretely expressed /contrasting opinion/ which can, it's self, be 'agreed with' (voted for).

Re: Dear GitHub

#90

Post by joncalhoun »

jondubois wrote: post #54

I like GitHub issues as they are. I wouldn't like to force people to adhere to a particular format when reporting problems. I find it strange that some project maintainers get annoyed when people use the issues section to post questions. What's wrong with that? A question can reveal design failures about your software... Maybe if your software was better designed, people wouldn't be asking the question to begin with.…

Have you ever tried to maintain a popular OS project on Github? Github issues feel great until you start using them at scale, and then they start to fall apart without some structure. This is especially pronounced in open source where many issues come from people who aren't familiar with what information you need in an issue to quickly resolve it.

I don't think the authors are requesting that this be made mandatory for all repos, but instead they just want the option to set up rules for repos they maintain. As someone giving up their free time to offer software for the rest of us, it seems only fair to let them set the rules about what they need before they can resolve an issue.

The biggest issue I see OSS maintainers running into is that they likely aren't the voice that Github listens to most anymore. If they can get some companies that pay for Github Enterprise to sign their letter as well that would likely help prioritize these features.

Post reply on HN