Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub package long-term vision notes #1372
Wordsmithing of the notes from a series of meetings with @kuychaco and @daviwil the last time we were at HQ. This is a collection of thoughts about our overall philosophy with this package and our current understanding of its scope and goals. It's also going to include a running list of farther-reaching ideas we'd love to explore.
Okay, I think I've transcribed all of my notes from our working sessions while I was in San Francisco. I'll likely merge this tomorrow-ish so we can find it in master. I'd
Apr 21, 2018
This is all very well written and without going too much into details. Perfect as a vision.
In the past, I wondered: "Why can't we make it easier, especially for beginners, by abstracting/hiding some of Git". But "this allows users to learn git" is a good point.
I'm not necessarily convinced. It's like suggesting we should have all our programming languages be more complicated so they map to terms and concepts to make it easier for users to learn assembler.
I think what holds us back from building an abstraction on top of Git is that if we do so, we have to commit to it end-to-end across GitHub and in a deep manner. Otherwise we end up in an XKCD standards scenario.
Think of it this way, our mission isn't to teach people to use Git. It's to help them write software together. Git is currently just a means to an end. I don't care about Git. I care about our users ability to write code collaboratively.
If we look at
Yeah, that's great point. It feels like an "all or nothing" deal.
Ok, maybe I should rephrase it to: If people learn how to use the GitHub package (with Git terminology), it makes it easier for them to move to the command line or other Git clients that also use Git terminology. I guess you could argue that that shouldn't be our goal either. But I still think there is some value in easing that bridge. At least currently.
At the same time I like how Desktop tries to be more beginner friendly by having only a single list with checkboxes and no mention of staging/unstaging. It becomes more a "just keep things selected that should be part of the next commit".
It's also intimidating for the uninitiated and even weaponized as tech gatekeeping. There are other projects that aim to make git more approachable by changing its terminology, but I would be afraid of creating a walled garden. We may be able to make users more comfortable within our own grounds, but if we aren't careful, they'll still experience a harsh awakening when they first attempt to venture outside.
What I want to do is have our cake and eat it too: I want to create novel graphical porcelain that makes git approachable for the casual user; but I want to do so in a way that uses the language that people already use when they're talking about git. If an Atom user tries to contribute to a project and is asked to "please rebase," they should be able to open the command palette, type "rebase", and figure out what they're being asked to do. Or, if an Atom user sees "rebase" in a context menu, they should be able to Google "rebase" and figure out what that means from existing git documentation.
A nice side benefit is that this helps us be more useful for the git expert as well. By using familiar terminology we improve the discoverability and comfort of our features that map to git CLI porcelain.
Of course, maybe I'm just underestimating our ability to make the world change
I'll also note that Desktop had a similar thought process in their design around the sync button, which was omitted from the redesign: