Things I would build if I worked at GitHub • Hacker News Board

Re: Things I would build if I worked at GitHub

#61

Post by tacone » Wed, Aug 05, 2015, 9:38 PM UTC

kelukelugames wrote: post #51

felixgallo wrote: post #17

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…

What is CI and why do people want it? I looked up the acronym on wikipedia but couldn't figure it out.

It stands for continuous integration.

Re: Things I would build if I worked at GitHub

#62

Post by baddox » Wed, Aug 05, 2015, 9:38 PM UTC

foolfoolz wrote: post #52

git hubs worst problem: FIXED WIDTH CODE READING code is read way more often than written. and on github website all you can do is read it. why the viewports don't take up the entire screen width i will never understand.

Yeah, that's a puzzling one. I've been using a browser script for a long time now to make the code view full width.

Re: Things I would build if I worked at GitHub

#63

Post by tracker1 » Wed, Aug 05, 2015, 9:39 PM UTC

jasode wrote: post #10

Those are interesting suggestions, but my guess is that they are probably focusing on features to make github more enterprise friendly. If a16z invests $100 million in github, it doesn't seem like streamlining emails will have the ROI that investors expect. Maybe github is focusing on creating a full software development lifecycle management (ALM) in the cloud. (Like Microsoft Team Foundation Server and JIRA.) A dash…

I'm actually hoping they bring something into GH for business/enterprise that is better, or as good as TFS or JIRA... I like TFS, but non-VS projects are a pain... and JIRA is just well, not pleasant at all.

Once they have some sort of better issue tracking system, then migration tooling will become another big issue in that space.. getting from SVN+JIRA or TFS itself would be really useful to a lot of orgs, willing to pay. Something between TFS and Axosoft's OnTime would be pretty nice as an addition to GH.

Another area with a lot of potential would be a CI/CD toolset that uses your own cloud.. EX: you use api keys for Azure, GCE, AWS, DO etc, and then you can setup testing/limits and Github could just manage the provisioning of the test servers, and ease setup/deployment of test/stage/prod classes of servers for multiple languages.

GH wouldn't have to manage a huge infrastructure itself, just build/sell tooling that extends it's current product line.

Re: Things I would build if I worked at GitHub

#64

Post by tacone » Wed, Aug 05, 2015, 9:40 PM UTC

To be frank, it is pretty much ok for the +1 to be annoying: it's often what they are meant to. Thus, if a vote button were to be implemented, it would not be used all the time.

Re: Things I would build if I worked at GitHub

#65

Post by jberryman » Wed, Aug 05, 2015, 9:43 PM UTC

danielsamuels wrote: post #40

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…

I regret every single time I try to use github search, even for the most basic "where is X defined" type queries.

Re: Things I would build if I worked at GitHub

#66

Post by ma138 » Wed, Aug 05, 2015, 9:45 PM UTC

bqe wrote: post #45

anton_gogolev wrote: post #35

Earlier quoted context omitted.

What do you miss the most or find cumbersome or unusable?

- Issues that span multiple projects - Searching all issues for an organization - Voting on issues (not just :+1:) - Public issues for private repos - Attaching files (repros, necessary files, etc.) - Dependencies/links - Priority (you can label priority but not sort by it) - Metrics of any kind

Check out ZenHub -

https://www.zenhub.io/

It adds these features to improve the GitHub Issue tracker directly into GitHub.com, allowing you to:

- Display issues on a task board by priority and progress - Attach any file type to an issue - Add estimates and view burndown charts / metrics attached to them - +1 issues to avoid excess comments - Improved search functionality - Link repos together to view issues that span multiple projects

Without having to context switch out to a separate issue tracker or UI

----

Disclosure - I work at ZenHub, and use it with GitHub all day :D

Re: Things I would build if I worked at GitHub

#67

Post by dlib » Wed, Aug 05, 2015, 9:49 PM UTC

lhnz wrote: post #8

Personally, I'd like a nice GUI to pick and squash commits with new commit messages against them on creating a pull request. I don't enjoy using the CLI for this, and it would be nice to thread thoughts on the solution into the commits themselves rather than explaining solely in the PR description.

I second this, also I'd like to see an overview of the (files with) merge conflicts if any instead of a message saying the PR can't be merged. Fixing the merge conflicts might be another thing in the web interface would be cool but I guess I'll stick to the CLI for this.

Re: Things I would build if I worked at GitHub

#68

Post by tracker1 » Wed, Aug 05, 2015, 9:55 PM UTC

thinkbohemian wrote: post #18

Better filters for emails. Would love to subscribe to only new issues on a repo or random issues on a repo. Basically http://codetriage.com

For that matter, on the issues page, and labels/markers for new issues vs. old ones with a "me too" comment. or for that matter issues that you've commented on.

I follow a couple dozen projects and after a couple days, my GH notifications page gets insane. Making issues more usable would be a big win imho.

Also, a "priority" follows would be nice too.. so your org/project issues can be viewed separately from your follows. Seeing adoption of something closer to ontime/tfs/jira would be nice too.

Re: Things I would build if I worked at GitHub

#69

Post by tracker1 » Wed, Aug 05, 2015, 9:57 PM UTC

geofft wrote: post #24

Linell wrote: post #4

I'd also love for commit messages to be parsed as markdown. I can't really think of a downside to it.

Ugh, that should be an opt-in thing. I've had trouble with Trac parsing commit messages as trac-wiki syntax, which is generally a great idea. The problem is occasionally you'll use markup characters in a semantically meaningful way, e.g. "Switch from `foo` to $(foo)", and rendering the markup will make the commit message confusing to read. I'd be much more enthusiastic if there was some magical way for the local git…

You could set something like markdownpad as your git editor.

Re: Things I would build if I worked at GitHub

#70

Post by fogonthedowns » Wed, Aug 05, 2015, 9:58 PM UTC

I would really like to have the ability to Edit commit messages using the web interface. I'm often stuck with a poorly crafted message and an edit function would help that.