Live data from Hacker News

Things I would build if I worked at GitHub

kevin.is

121–130 of 145 posts

Re: Things I would build if I worked at GitHub

#121

How about making pull requests less centralized? Right now, if I file a PR, only the project admins or I can modify/rebase it. I'd like to give other (non-admin) collaborators permission to work on it too. Or, maybe it could use a forking model? Let anyone fork their own PR from mine, make those forks prominently visible in my base PR, and make it easy for me to merge their edits back in.

If you want anything less centralized, then why are you using Github, a centralized interface to and storage of a previously inherently de-centralized system, git?

Github is for people who accept centralization.

Re: Things I would build if I worked at GitHub

#122
post #104

Earlier quoted context omitted.

What appeals to you about mailing lists? If it's reporting issues, discussion solutions, and reviewing patches, there are Issues and Pull Requests. If it's for general discussions about the "future of the project" or bigger-picture topics, I'd use Discourse. It's a really nice way to organize discussions that are one step removed from code-related issues. If it's for things where you need quick or real time feedback,…

Isn't this a bit like saying: if it's for issue tracking, there's Bugzilla/trac/issuetracker/phabric, or if you need a wiki there's moinmon/mediawiki, or if you need a blog there's ghost/wordpress ? More to the point: IRC (out-of-the-box) doesn't do archiving/search. Slack isn't self-host (which isn't an issue with people using github -- but it does introduce another vendor). Using external services forces you to mai…

Well, re: authentication -- I didn't think to check slack's support for oauth etc... apparently there's 0auth.com:

https://slack.zendesk.com/hc/en-us/articles/203772216-Using-...

https://auth0.com/docs/identityproviders

Not sure about authorization and group membership, channel authorization etc -- I assume you'll need to manage slack authorization with slack, and github authorization on the github side.

But fair's fair.

[ed: And now you have three providers:

https://auth0.com/pricing ]

Re: Things I would build if I worked at GitHub

#123
I see people here posting issues of their own, but I'm amazed nobody has yet mentioned the lack of IPv6.

I've setup a few machines with IPv6-only network connections, and it makes pulling my dotfiles from github a pain since I need an IPv4-proxy/tunnel to access github.com

Re: Things I would build if I worked at GitHub

#126

I see people here posting issues of their own, but I'm amazed nobody has yet mentioned the lack of IPv6. I've setup a few machines with IPv6-only network connections, and it makes pulling my dotfiles from github a pain since I need an IPv4-proxy/tunnel to access github.com

Given up complaining for now. They just don't seem to get it.

Re: Things I would build if I worked at GitHub

#127

These are great, but they're bugfixes. You'd finish them in the first few months. Then what are you going to do? Stare at an aquarium all day? Here's what I would build if I worked at github: * Github CI - simple CI for every language, integrating with: * Github Artifacts - repository for versioned deployable build packages (binaries, tar.gz files, ios builds, android builds...), integrating with: * Github Deploy - d…

Non of the items in the author's list is a bugfix. They all are enhancements. A bugfix would fix a bug, which means something would not work as it is supposed to, fail, and that is not the case here.

Arguing semantics, maybe. But I think it is important to distinguish here. Polishing issues or enhancements or whatever you call it are things that do not need to be adressed, but they can. But bugs needs to be fixed. Choosing between what to do now is choosing between maintenance work and feature enhancement work, plumbing and UX.

I think it would be great if Github would hire and let him build these things, does not matter if he finishes in a month.

Re: Things I would build if I worked at GitHub

#129

I've gotta say, I strongly disagree with this: > GitHub already has a great code search At some point in the last year or so Github rolled out a new search engine which drastically reduced it's usefulness. Any moderately complex search query now has all of the modifiers and key bits stripped out making your search results unnecessarily cluttered and somewhat useless. I consider it to be one of the worst parts of the…

Git grep is really fantastic, if github search came close I'd be delighted

Could you please elaborate on what parts of git-grep you find most useful?

Re: Things I would build if I worked at GitHub

#130

Earlier quoted context omitted.

> If it's for general discussions about the "future of the project" or bigger-picture topics, I'd use Discourse. It's a really nice way to organize discussions that are one step removed from code-related issues. This is what is appealing and Github offering a builtin-to-github solution for it, with linking to Github accounts, autoformatting etc (like in issues) and so on. There is so much potential.

Why can't you just have those discussions in issues? Create a "future of the project" label.

That's an interesting idea (one of my big blockers for migrating my projects off SourceForge is what to do with the mailing lists).

The issue UI is a little forum-like but is pretty clunky, and, of course, doesn't interact with email very well. Plus you need people to manually tag each issue with 'discussion'.

Are there any UI tweaks that could simplify this? For example, a way to provide a 'new issue' link with default labels?

(Also, is there a good way to import data as issues? I have a tonne of mbox archives that need to go somewhere.)

Post reply on HN