12 ms·

Let's make GitHub better, together

175 points by experiment0 14y ago

wladimir 14y ago
Hmm my suggestions: - Please make the "show changes" scale to large code changes. I've been bitten by hanging browsers a few times while trying to review pull requests in which many files were changed significantly or added. One (simple) way would be to show just the changed files, in collapsed form, which can be expanded. - Add a way to increase the size of the diff context Sometimes the given context is not large enough, especially if a file has many similar functions. For example in vimdiff you can "expand the hidden lines" in this case.
- jakub_g 14y ago
  @wladimir Have a look at the Firefox userscript I wrote very recently: http://userscripts.org/scripts/show/153049 http://userscripts.org/scripts/show/153049 -- feedback welcome! Of course it doesn't eliminate the big initial fetch from the served, just collapses it once loaded to have more friendly UI.
  - wladimir 14y ago
    Thanks for the link, looks useful. That would be functionality that should be in Github itself. Good to see that I'm not the only one with that pet peeve.
- sdesol 14y ago
  Disclaimer: I'm the founder of a company that has been working on solving the problems that you have described for the last year. Having developed internal tools for large enterprise environments with over 50,000 developers with massive code bases (think linux kernel times 10), it has always baffled me why GitHub and others seem to think stuffing all the changes on a single page is a good idea. Sure it's great when the changes are small but having to deal with large changes is not an unusual edge case. Especially in the enterprise environment where process and politics tends to create backlogs in merging which forces us to have to deal with large changes at once. Below are some sample screen shots with how we deal with changes. Viewing pull request detail http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e.r94.cf1.rackcdn.com/pull-request-1.png http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e... If the changes are really massive, we offer the ability to navigate the changes as a code churn tree. We call this the divide and conquer way of managing large diffs. http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e.r94.cf1.rackcdn.com/code-churn-tree.png http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e... We also make it possible for you to break apart the commits that are included in the pull request with our commits browser. Note the revisions tree on the left that shows you all the revisions. http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e.r94.cf1.rackcdn.com/commits.png http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e... As for the diff issue. We have the ability for you to create your own custom diff views. See the following screen shot. http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e.r94.cf1.rackcdn.com/add-diff-view.png http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e... With the custom diff view, we make it very easy for you to manipulate the diff output.
thiderman 14y ago
No localization, please. Sure, the languages mentioned came from countries where english is not the main spoken language, but the languages themselves are always in english, and so is everything relating to collaborative software development. If a user comes to a site that is using her primary language, she will interact with that site using that language. That is very much not desirable at a site like Github. Other than that, the suggestions listed sound nice to me.
- TeeWEE 14y ago
  +1 If you can't speak english, you can't program for sure. I work with some people who are not very good english speakers. I can see it in their code. Sometimes its a mix of english and their own language. Very bad. NO-HIRE
  - Adirael 14y ago
    Last year I worked as a freelancer for a company which sold physical stuff over the Internet (ecommerce). All the code I inherited was procedural PHP written with Swedish comments and variable names. I speak three languages, Swedish is not one of them. That was an awful summer.
  - deleted 14y ago
    [deleted]
  - pilsetnieks 14y ago
    In such cases even if you make it a policy to use only English, it can still bite you - for example, subtle grammar errors in variable names in a large codebase will be maddening for anyone except the original programmer.
- damian2000 14y ago
  Inclined to agree with you about this, but isn't the post talking about localisation only for the github website UI itself .. a separate issue to the language used in comments, commit messages, code, etc. It just brings down a barrier that might be stopping some people using it.
upinsmoke 14y ago
Better search in Starred projects! I can rarely find a project I have starred.
zalew 14y ago
I don't know if i18n is such a good idea here. I've thought about it on a project I'm currently working on, and my conclusion is that sometimes you need to make the audience interact in a common language (in most cases English). If you i18n your UI, it may encourage your users to communicate in their native tongue and it will be a mess. > Documentation, you neglected necessity of open-source. [..] Nothing too fancy; just click a button, parse my repository, and provide a list of public classes and members. uhm, Sphinx?
- masklinn 14y ago
  While I do completely agree with you (coming from a non-english-speaking country), from the "MONEY!" POV, localization makes sense even if it siloes communities, some countries's communities mostly (if not only) communicate in their mother tongue and tend to have little involvement outside that (russian and asian communities tend to do that a lot in my experience, though it may only be because they have the numbers and are thus easier to notice than e.g. italian or french)
  - zalew 14y ago
    I'm not so sure. I mean, what's the point especially in the context of programming? I am aware that contrary to popular opinion, there are a lot of geeks who don't speak English very well, yet localizing opensource IMO doesn't make much sense (except some rare cases of very specific local projects). I'm from a non-en too, but frankly speaking I sometimes got problems reading docs when they use local nomenclature. Programming == English, like it or not. btw, are there any localized words for 'forking', 'pull request'?
    - kmfrk 14y ago
      btw, are there any localized words for 'forking', 'pull request'? As someone who lives in a country where English is not the native language, non-English languages will never be able to keep up with developing terminology and neologisms. It is fine to translate "plain" language, but the terminology and jargon won't work very well when translated. It also has the additional downside of defeating look-ups and google-ability, which is one of the points of terminology. Not just considering the importance of Google, but Stack Overflow in particular.
Tehnix 14y ago
I don't know why, but for some reason I found that localizing github would in fact not contribute to the better, but to the worse. I know there are a lot of programmers for whom english is not their native language (heck, I'm one of them), but as almost all programming languages are in english, I think it would make sense to keep github in english. My reasons are, more of less, the following: - As it stands now, the majority of repositories are in english. If github were localized, it would most likely contribute to more non-english repos since the author would be less inclined to give it any thought. - It would require a lot of extra effort on githubs side to, first of all localize it, but also to keep it updated and correct. They would need translators and probably also need to put a lot of effort into localizing the site (which I'd rather they focused on other things). I know these may not be the best reasons, but I'd rather people learned english than doing it in their native language (english opens it op to more people, ie more people can benefit/contribute to the project). But hey, those are just my two cents...
porker 14y ago
Code search would also be useful, even if just string search. Or filename. E.g. somewhere in this repository there's a file called mysettings.xml [Yes, I know I could check it out, but still...]
- simonw 14y ago
  Filename search is available for all repositories - hit "t" and start typing your search query. It's fantastic. A "search source code" box is available for my paid for private repos, so I guess it's a premium feature.
  - porker 14y ago
    Thank you!
- mgrouchy 14y ago
  for filename, go to the repository (code) window and press 't' , it will give you a command-t type interface to search for filenames in the project.
- a9entroy 14y ago
  On any repo page you can just press t and you can search by filename.
- Zakiazigazi 14y ago
  Code search is available - if somewhat hidden. Add /search to the end of the repository url on github (eg. https://github.com/rails/rails/search https://github.com/rails/rails/search ).
- boyter 14y ago
  Shameless plug, searchco.de allows you to search over github's public repositories, http://searchco.de/?q=irq_create_mapping+url%3Agithub http://searchco.de/?q=irq_create_mapping+url%3Agithub
jakub_g 14y ago
+1 for "likes" in issues.
- orefalo 14y ago
  Another feature missing: per branch access control
  - tomeric 14y ago
    Yes! This would allow developers to set up premium branches: http://premium-branch.org http://premium-branch.org
Adirael 14y ago
"Bifurcar", that term may be correct, but it sounds awful to my ears.
- rbonvall 14y ago
  It sounds weird indeed. The literal translation of branching would be «ramificar», which also doesn't seem right. That's the problem: everyone comes up with their own translations that are not what people refer to them in real life. I say «crear una rama» (create a branch), while most of my friends just say «hacer un branch» (make a branch). And there are also the ugly anglicisms like «branchear» and «forkear».
zbowling 14y ago
You should add the stuff I posted about last year about this time. Basically my beef is forking being not very in the spirt of how it's supposed to work with git. http://zbowling.github.com/blog/2011/11/25/github/ http://zbowling.github.com/blog/2011/11/25/github/
mbesto 14y ago
Slightly meta - If I was a business owner and a customer wrote something like this, I would be absolutely ecstatic. It shows that you've created an awesome product. So awesome that people want more out of it, and are willing to spend considerable time ($$$) to help you make it better. This is the real reason profit margins are so important to a good company. It means you can re-invest back into the growth of your product and continue to delight your customers. Good on ya Github, keep it up.
niels 14y ago
So apparently this is the new standard in job applications.
NicoJuicy 14y ago
Github shouldn't be localized... Some projects wouldn't be viewed if it ain't in english, no one here almost speaks Chinese do they? :-) Facebook should be localized, not github.
- alxndr 14y ago
  我会讲中文。
  - derleth 14y ago
    > 我会讲中文。 Google Translate renders this as "I can speak Chinese.", which speaks volumes about how far it's come with East Asian languages.
mpeg 14y ago
I know this is a call for help, but I find it funny that their big screenshot in spanish makes no sense to this native speaker.
neilmiddleton 14y ago
Someone wants a job
facorreia 14y ago
"Ruby came from Japan. Lua came from Brazil. Python came from the Netherlands." And all of them use English terms for language identifiers. English is the lingua franca of IT & software development. As a Brazilian I can tell you that programmers that don't learn at least how to read technical English won't become good practicioners. And GitHub is a social platform for collaborating on projects. In the vast majority of projects, English is the common language spoken by all participants. Learn English and get over it. (I didn't read further into the article. I hope the other suggestions make more sense.)
- wildchild 14y ago
  Agree, but this is business. They need more customers.
- FiloSottile 14y ago
  Totally. I am Italian, and seriously, most of the blog posts, tutorials and such written in my native language are so bad that only bad programmers can grow out of them. Also, an open source project maintained in, say, Spanish is one I and others can't easily contribute to. That would be a disaster.
  - to3m 14y ago
    Projects would have to pick a language that makes sense, given their goals. Perhaps some would be keener on optimising mainly for the existing set of contributors?
    - FiloSottile 14y ago
      I'm not sure about this, it would restrict the future changes, limiting innovations and putting the project at risk of dying when the developers leave, IMHO.
- Svip 14y ago
  I disagree. My position is not that English is bad (English has some advantages here and there, but it is hardly the best language I know), it is very practical - and necessary - to learn if you want to work in IT. No doubt about it. However, confining ourselves to one language makes us all think the same way. Research has proven time and time again, that learning other languages will help us apply different ways to think about problems, because different languages uses different grammar to convey the same meaning. Effectively, if we continue to strive to eradicate localised IT and software related words from non-English languages and replace them with English words instead, language development will stagnate and all languages will eventually become English. And that is not a positive prospect. I don't need Github localised, but I would like to localise it for the purpose of creating technical terms in my own language. I fear that most of the localisation into Danish would simply be English words instead, despite the fact that Danish actually has words for 'push' and 'pull' (»puf« and »hal«, respectively). And English shouldn't be so cocky either, by its current usage, English is slowly becoming less than a language and more of a tool. And with both foreign and native speakers' continue abuse of the language, English will soon be derived of all its beauty, for the purpose of minimising communication. Are we really that lazy?
minikomi 14y ago
I think i18n makes sense - for docs. For getting people up and running. For explaining the benefits of github.
pixxa 14y ago
The #1 missing feature in github for our team is that we can't attach files directly from Issues Web UI. Usually we need this for screenshots, but sometimes data files, logs and other artifacts. Workarounds are aplenty but all painful and problematic. See https://github.com/thisduck/gh-attachment https://github.com/thisduck/gh-attachment or http://feeding.cloud.geek.nz/2012/06/attaching-files-to-github-issues.html http://feeding.cloud.geek.nz/2012/06/attaching-files-to-gith... not to mention countless internal homegrown hacks that exist out there. This lack of attachments makes it a lot harder for non-techies to use Issues (e.g., for casual or QA testing). Don't get me wrong, I absolutely LOVE the minimalist approach of Issues, and it is definitely _almost_ good enough feature set, but this one missing feature makes it difficult for one to imagine the use of issues at-large in broad organizations--an undiscovered area of growth for github. I would definitely add this to the "I <heart> github, but..." list. P.S., experiment0, great execution of a "feature request".
- pixxa 14y ago
  My wish came true in less than one day! Check it out https://github.com/blog/1347-issue-attachments https://github.com/blog/1347-issue-attachments
morefranco 14y ago
This is a great personal effort to bring improvements to a platform we all know and love - I've got many friends overseas who all speak (and most critically - think ) in English to varying degrees. Localization is never a wasted effort. I hope they hire you Garen!
Hawkee 14y ago
While it may be an intentional shortcoming, I feel GitHub is lacking in general discussion. Sometimes I just want to ask the developer a question about their code. Usually what I do is look for their Twitter account and @mention the question over to them. It would be nice to find a discussion around a particular repo just as we have here on Hacker News.
juanbyrge 14y ago
How do people have so much free time lol?
why-el 14y ago
I think localisation makes sense for the docs. Maybe we can branch off from here and coordinate the efforts. I myself am ready to work on Arabic and would love to have people join me.
- nicholassmith 14y ago
  I agree, that's where the localisation should go. Github has many things and for a first timer the docs are invaluable, but if you're a non-native speaker having them in your own language is going to help you ramp up to speed on using it that much quicker.
fphilipe 14y ago
Didn't GitHub have localization at some point in the past? If I remember correctly, the footer had a world map background with links to other languages.
- tomeric 14y ago
  Yes they did: https://github.com/blog/679-github-in-your-language https://github.com/blog/679-github-in-your-language
- deleted 14y ago
  [deleted]
- foca 14y ago
  We did, and then we dropped it because a _very_ small percentage of users were on non-English locales.
dmritard96 14y ago
Doesn't chrome have translation capabilities? I don't know if the translation capabilities can avoid translating code but if it could somehow (a do not translate tag or something) then localization could be done, locally...
d0m 14y ago
Would be nice to have a mega refactor function that could check for duplicate all over the public repos. So, for instance, my "capitalize function" could be tagged as duplicate and I could see multiple projects having a better one.
purephase 14y ago
A few items I'd like to see: - Attachments in the issue tracker. Pictures tell a thousand words and it would be infinitely easier for user submitted issues to have screenshots. - Better code search. - More granularity in the notifications. For instance, I'd love the ability to toggle email for my own repos but leave it to web notifications for my watches. I've missed pull requests because of the deluge of messages. - Better reliability. It's a great tool. I really enjoy using it, but with a few additions it would be near perfect.
- lifeisstillgood 14y ago
  You can add attchements to issues - please look at my https://github.com/lifeisstillgood/githubkoolaid https://github.com/lifeisstillgood/githubkoolaid (it has one helper script - ghgrab.sh that, well, fires off xwd, and then uploads the resulting screenshot through the github API (mediuated by the excellent ghi) I have no idea if it works outside of FreeBSD - drop me an issue on github if it does :-) WIth a screenshot!
- jamesgeck0 14y ago
  > More granularity in the notifications. This. If you're part of a big organization with a lot of repos, you'll automatically watch all of them (and forks) as they are created. I'm currently watching 451 repos and have a mess of Gmail filters to (mostly) ignore notifications from repos I don't care about. Priority Inbox helps some in that it makes email actually mostly usable, but Github really needs to fix this. There's an option to turn off auto-watching and a button to stop watching all repos, but there's not really an easy to to say, "I care about this repo and all it's forks, but nothing else." Or, as you mentioned, a way to watch some repos via email and everything else on the web.
- dewski 14y ago
  We just shipped Issue Attachments: https://github.com/blog/1347-issue-attachments https://github.com/blog/1347-issue-attachments
- boyter 14y ago
  Shameless plug, searchco.de allows you to search over github, http://searchco.de/?q=irq_create_mapping+url%3Agithub http://searchco.de/?q=irq_create_mapping+url%3Agithub You just need to add the url:github portion to any search. You can do the same over bitbucket, codeplex, google code, sourceforge and the fedora source tree too. See, http://searchco.de/blog/view/variety-of-updates http://searchco.de/blog/view/variety-of-updates
wildchild 14y ago
I think new pricing strategy could make github better.
- benmanns 14y ago
  What would you suggest?
  - wildchild 14y ago
    First of all, it's too expensive. $7 for 5 repos? I'll use bitbucket instead and keep github account for opensource projects. Probably price should depend on a number of collaborators and some special features.
- webology 14y ago
  I agree. I moved to bitbucket after canceling their small service because jumping from $12 to $22 just for a few more private repos. I wish they had more a of a hobbyist plan with maybe a storage limit or a $1 a repo type pricing. I didn't care for their practice of deleting forum posts every time someone would ask about similar questions. I still recommend them for my clients though.
FiloSottile 14y ago
Actually, more than labels (that would be good anyway) I would LOVE seeing the open/closed state of issues in notifications. I spend a lot of time checking new issues already closed by the other project maintainer.
gavanwoolery 14y ago
The famous "hacker faq" recommends using English for a few reasons: http://www.catb.org/esr/faqs/hacker-howto.html#skills4 http://www.catb.org/esr/faqs/hacker-howto.html#skills4 Other than that... Since code is shared across many different countries, we cannot be too wishy-washy about which one to use. English is rated as "the most influential language in the world" in terms of how many countries use it and the socio-economic standing of these countries. I hate to be the one to push English (as a native speaker myself), but as you can see others on this thread recommend it, even though it is not their native tongue. By all means, I do not promote destroying cultures, but learning a common language brings us all closer together. :)
- lifeisstillgood 14y ago
  I like the sentiment, but might I point out that the early inventors of television believed that it might end war by showing the great similarities between peoples and nations. And that from domestic violence to wars, we tend to fight those who are next-door, closest to us in mind body and spirit. (If you are not too sure about that, think how easily a rural Shinto Chinese would be able to explain the vast differences between Christianity and Islam)
  - alxndr 14y ago
    Shinto Chinese?
    - lifeisstillgood 14y ago
      Yeah that was dumb of me. I may have been thinking Shenism, but I am sure there are some Shinto Chinese. Anyway the point I am making still holds I think - you can barely squeeze a credit card between Islam and Christianity if viewed from a distance - yet billions are on the edge because of the "vast gulf" between the religious
prezjordan 14y ago
I thought this was a GitHub promotion at first, but this is a genius form of self-marketing. Very creative, and very convincing!
pbiggar 14y ago
I slightly agree about CLAs. Contributor Licence Agreements are largely ignored by most small open source projects because they're a pain in the ass and prevent contributors from contributing. However, I think they could go further than the support discussed here. It would be great to see CLAs tht you could get asked to sign when you make a pull request. You could also make it easy to sign - maybe instead of printing and scanning, you could sign using a PGP key. If Github incorporated this stuff, every project could seamlessly use CLAs.
- apaprocki 14y ago
  Paperlex has a public free CLA manager which integrates with GitHub: http://clam.paperlex.com/ http://clam.paperlex.com/
  - pbiggar 14y ago
    I took a quick tour, and I believe this would be too cumbersome compared to an integrated solution.
louischatriot 14y ago
Very interesting proposals overall, not too sure about the localization (don't most programmers speak English ?) though.
hunvreus 14y ago
From what I remember, Github had localization going on but pulled the plug at some point because it was too much of a clusterfk. I was surprised not to see any mention of the only thing that irks me: the "Switch account context" dropdown menu being available only on the front page and not in the top bar where your account is displayed. That would save me quite a bit of gymnastic to have that displayed on all pages.
hoggle 14y ago
I'm a native German speaker and this localization thing seems like a really bad idea. I can understand where the github folks are coming from but it really is a thing not worth putting any effort into. I sympathize with the humanism but programming and programmer communication should be mostly pragmatic. The open source community is a global thing and English has won a long time ago as the definitive choice for a global language. It seems like it's easy enough to pick up for a lot of people all over the world. In my opinion it works especially well for technical writing.
- jlarocco 14y ago
  Actually, as far as I can tell, it has nothing to do with "official" GitHub. It's some guy with the GitHub username "letsmake" using GitHub pages [1]. I really wish GitHub would start doing something about people using that feature to make it look like they're part of (or speaking for) GitHub. It's incredibly misleading some times. [1] http://pages.github.com/ http://pages.github.com/
  - shabble 14y ago
    Sites that allow users [to have significant control over] personalised subdomains are also problematic for things like NoScript and other whitelisting tools. Since I have github.com permitted, all the subdomains inherit that permission. I'm not even sure what a good model/UI would be to selectively white/blacklist subdomains.
    - gsiener 14y ago
      Maybe github should use a different TLD for pages? Like Githubpages.com ?
    - alter8 14y ago
      That is a problem only because Github uses the root domain for its own pages. They could rather use www.github.com. To solve your case on NoScript, whitelist the full address https://github.com/ https://github.com/ and that will keep http subdomains out.
wildchild 14y ago
I suggest read-only SSH keys for deployments.
moe 14y ago
The first thing I do when I come across a site that tries to speak my language? I switch it back to english. Localization makes sense when you're a shopping site aiming at mom & dad and non-techies. For technical services (pretty much all SaaS) the translations usually turn out so terrible that everyone turns them off. Also good luck googling for the solution to a problem in any other than the primary language of the site...
rsanheim 14y ago
GitHub used to have localization, back before I joined, but it got dropped. Many non-native speakers switched to English anyways, and it just wasn't worth the effort and maintenance hassle.
jelder 14y ago
I appreciate this guy's effort, but honestly most of his concerns has ever impacted my productivity. Sure, the editor isn't great yet. What I really want to see, and I'm not the first to say this: * Explicit licenses: If a repo lacks a LICENSE file, this is almost as annoying as it lacking a README, and GitHub's interface should complain to the repo owner. Searching and filtering by license would be nice, too. * Explicitly "official" forks. It's way too hard to find the right fork when you just want to improve a public gem, for instance. I was there was an explicit "why does this fork exist" field on each repo. acts_as_solr is a particularly morbid example of why this is important. * Their code search is basically useless. Last I checked, they don't even index branches. They should just buy or reimplement Ohloh.
- boyter 14y ago
  Shameless plug, searchco.de allows you to search over github, http://searchco.de/?q=irq_create_mapping+url%3Agithub http://searchco.de/?q=irq_create_mapping+url%3Agithub You just need to add the url:github portion to any search. No branch support yet, but working on it. I doubt they will be able to buy Ohloh though as that's owned by BlackDuck. I also find Ohloh search lacking in some areas such as the following search, http://searchco.de/?q=%3D~+lang%3Aperl http://searchco.de/?q=%3D~+lang%3Aperl http://code.ohloh.net/search?s=%3D~&browser=Default http://code.ohloh.net/search?s=%3D~&browser=Default
digerata 14y ago
Infinite scrolling? Yuck.
- deleted 14y ago
  [deleted]
webology 14y ago
I'd love to see a "grouped" pull request option. Something that would let me say show me changes from repo1 + repo2 because they depend on each other. Think refactoring code into a smaller repo, etc. I deal with this quite a bit with clients as they grow from small apps into much more complex apps with lots of inner dependencies and tests.
- sdesol 14y ago
  We (my company) actually take this to another level. We provide branch level grouping. http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e.r94.cf1.rackcdn.com/search-result.png http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e... The reason why we've created this feature was because in the enterprise world, it is not uncommon to construct a release based on branches from various repositories. We also have a smart attributes technology that will allow you to assign arbitrary meta data to a pull request. With this technology, you'll be able to ask questions like show me all the pull requests that have a priority greater than X.
themgt 14y ago
What if we spent our time making GitLab (http://gitlabhq.com/ http://gitlabhq.com/) better instead, since it's open source and users can host their own for free?
- nuclear_eclipse 14y ago
  One of the biggest draws of Github (to me) is that it's one central place for me to go for a wide array of projects that I work with, and where a lot of people I know can host their code to share with the large community of developers already on Github. By using Gitlab on your own hosting, you lose all of that convenience of having everything in one place. Imagine that every time you want to contribute to a project, you have recreate yet another user account, upload all of your SSH keys again, and more. And then further imagine that you want to fork and work on repos from multiple projects that all have their own Gitlab instances, and now checking on your projects requires visiting N different sites to get the same information that you already get from a single login to Github. Now I'm just as big of a fan of open source as the next person, but having a single central place to visit for projects is a Good Thing, and IMO Github has proven time and again that they actually care about the open source community as much as we do, and have done so much to foster communication and interaction between developers that their contributions are far more important to me than the value of having my code repositories hosted on an open source platform.
  - themgt 14y ago
    I agree, and I think GitHub is a fantastic resource for open-source projects, but it's a bit of a lobster trap in the sense that its existence lessons the need for an open-source alternative, but then locks you in to a paid model once you need private repositories. What we should be looking for is an open-source project that allows people to keep their own projects private on their existing hosting, and allows easy sync with github for public projects.
FiloSottile 14y ago
Issues images, headshot: https://github.com/blog/1347-issue-attachments https://github.com/blog/1347-issue-attachments And don't tell me that you Githubbers don't lurk over here ;)
reledi 14y ago
Some good points, but I disagree with the following. - i18n and l10n For reasons already stated by many others in this HN thread. - Notifications should be more like email Please no. I'm already terrified of my email inbox. It's a mess, so many messages. Sometimes I'll leave a message unread or mark it as unread if I want to return to it later but instead it gets buried by newer messages. So now I have a couple of hundred unread emails and I have no idea what they are but they surely can't be important. Keep notifications how they are. It makes using GitHub stress free. If I read a notification, get rid of it so I never have to see it again. If it was so important, I should remember it anyway or I would have set it as my highest priority and worked on it right away. - Revamp Inline Editing Themes? Multiple cursors? Command line? Live linting? ... No thanks, sounds like feature-creep. I like the editor how it is, nice and simple. Want a full-blown editor? Don't use the web interface. - Infinite newsfeed There are reasons why many websites choose not to include infinite scrolling, see [1] for some good reasons. One thing I'd like to see added to GitHub: - View all public activity history There's been many times when I want to look at my own history or someone else's and I can't because it stops after the first page. [1] http://www.quora.com/Infinite-Scrolling/What-are-the-downsides-of-using-automatic-scrolling-pagination http://www.quora.com/Infinite-Scrolling/What-are-the-downsid...
freshhawk 14y ago
Let's volunteer to work for a commercial entity for free? No thanks. They're doing fine, they can easily afford to pay people to do this if it's necessary. Volunteer your time for non-commercial projects that do not have the option of paying people a fair wage for their work.
hmsimha 14y ago
I thought it worth mentioning that everyone opposed to this idea is capable of communicating in English. I am guilty of being monolingual, but if the most popular online source code management community used a language X that I did not know how to speak (especially if X was considered the lingua franca of software development), it would be a huge barrier of entry to me. While I would do well to learn X, an english localization of that platform would greatly ease my transition and encourage me to communicate with the predominantly-X speaking community. I would like to get the opinions on localization of github from people who are currently unable to communicate in English with a high enough proficiency to read these comments and voice their position here.

175 points by experiment0 14y ago

Hmm my suggestions: - Please make the "show changes" scale to large code changes. I've been bitten by hanging browsers a few times while trying to review pull requests in which many files were changed significantly or added. One (simple) way would be to show just the changed files, in collapsed form, which can be expanded. - Add a way to increase the size of the diff context Sometimes the given context is not large enough, especially if a file has many similar functions. For example in vimdiff you can "expand the hidden lines" in this case.

jakub_g 14y ago
@wladimir Have a look at the Firefox userscript I wrote very recently: http://userscripts.org/scripts/show/153049 http://userscripts.org/scripts/show/153049 -- feedback welcome! Of course it doesn't eliminate the big initial fetch from the served, just collapses it once loaded to have more friendly UI.
- wladimir 14y ago
  Thanks for the link, looks useful. That would be functionality that should be in Github itself. Good to see that I'm not the only one with that pet peeve.
sdesol 14y ago
Disclaimer: I'm the founder of a company that has been working on solving the problems that you have described for the last year. Having developed internal tools for large enterprise environments with over 50,000 developers with massive code bases (think linux kernel times 10), it has always baffled me why GitHub and others seem to think stuffing all the changes on a single page is a good idea. Sure it's great when the changes are small but having to deal with large changes is not an unusual edge case. Especially in the enterprise environment where process and politics tends to create backlogs in merging which forces us to have to deal with large changes at once. Below are some sample screen shots with how we deal with changes. Viewing pull request detail http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e.r94.cf1.rackcdn.com/pull-request-1.png http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e... If the changes are really massive, we offer the ability to navigate the changes as a code churn tree. We call this the divide and conquer way of managing large diffs. http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e.r94.cf1.rackcdn.com/code-churn-tree.png http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e... We also make it possible for you to break apart the commits that are included in the pull request with our commits browser. Note the revisions tree on the left that shows you all the revisions. http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e.r94.cf1.rackcdn.com/commits.png http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e... As for the diff issue. We have the ability for you to create your own custom diff views. See the following screen shot. http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e.r94.cf1.rackcdn.com/add-diff-view.png http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e... With the custom diff view, we make it very easy for you to manipulate the diff output.

thiderman 14y ago

No localization, please. Sure, the languages mentioned came from countries where english is not the main spoken language, but the languages themselves are always in english, and so is everything relating to collaborative software development. If a user comes to a site that is using her primary language, she will interact with that site using that language. That is very much not desirable at a site like Github. Other than that, the suggestions listed sound nice to me.

TeeWEE 14y ago
+1 If you can't speak english, you can't program for sure. I work with some people who are not very good english speakers. I can see it in their code. Sometimes its a mix of english and their own language. Very bad. NO-HIRE
- Adirael 14y ago
  Last year I worked as a freelancer for a company which sold physical stuff over the Internet (ecommerce). All the code I inherited was procedural PHP written with Swedish comments and variable names. I speak three languages, Swedish is not one of them. That was an awful summer.
- deleted 14y ago
  [deleted]
- pilsetnieks 14y ago
  In such cases even if you make it a policy to use only English, it can still bite you - for example, subtle grammar errors in variable names in a large codebase will be maddening for anyone except the original programmer.
damian2000 14y ago
Inclined to agree with you about this, but isn't the post talking about localisation only for the github website UI itself .. a separate issue to the language used in comments, commit messages, code, etc. It just brings down a barrier that might be stopping some people using it.

upinsmoke 14y ago

Better search in Starred projects! I can rarely find a project I have starred.

zalew 14y ago

I don't know if i18n is such a good idea here. I've thought about it on a project I'm currently working on, and my conclusion is that sometimes you need to make the audience interact in a common language (in most cases English). If you i18n your UI, it may encourage your users to communicate in their native tongue and it will be a mess. > Documentation, you neglected necessity of open-source. [..] Nothing too fancy; just click a button, parse my repository, and provide a list of public classes and members. uhm, Sphinx?

masklinn 14y ago
While I do completely agree with you (coming from a non-english-speaking country), from the "MONEY!" POV, localization makes sense even if it siloes communities, some countries's communities mostly (if not only) communicate in their mother tongue and tend to have little involvement outside that (russian and asian communities tend to do that a lot in my experience, though it may only be because they have the numbers and are thus easier to notice than e.g. italian or french)
- zalew 14y ago
  I'm not so sure. I mean, what's the point especially in the context of programming? I am aware that contrary to popular opinion, there are a lot of geeks who don't speak English very well, yet localizing opensource IMO doesn't make much sense (except some rare cases of very specific local projects). I'm from a non-en too, but frankly speaking I sometimes got problems reading docs when they use local nomenclature. Programming == English, like it or not. btw, are there any localized words for 'forking', 'pull request'?
  - kmfrk 14y ago
    btw, are there any localized words for 'forking', 'pull request'? As someone who lives in a country where English is not the native language, non-English languages will never be able to keep up with developing terminology and neologisms. It is fine to translate "plain" language, but the terminology and jargon won't work very well when translated. It also has the additional downside of defeating look-ups and google-ability, which is one of the points of terminology. Not just considering the importance of Google, but Stack Overflow in particular.

Tehnix 14y ago

I don't know why, but for some reason I found that localizing github would in fact not contribute to the better, but to the worse. I know there are a lot of programmers for whom english is not their native language (heck, I'm one of them), but as almost all programming languages are in english, I think it would make sense to keep github in english. My reasons are, more of less, the following: - As it stands now, the majority of repositories are in english. If github were localized, it would most likely contribute to more non-english repos since the author would be less inclined to give it any thought. - It would require a lot of extra effort on githubs side to, first of all localize it, but also to keep it updated and correct. They would need translators and probably also need to put a lot of effort into localizing the site (which I'd rather they focused on other things). I know these may not be the best reasons, but I'd rather people learned english than doing it in their native language (english opens it op to more people, ie more people can benefit/contribute to the project). But hey, those are just my two cents...

porker 14y ago

Code search would also be useful, even if just string search. Or filename. E.g. somewhere in this repository there's a file called mysettings.xml [Yes, I know I could check it out, but still...]

simonw 14y ago
Filename search is available for all repositories - hit "t" and start typing your search query. It's fantastic. A "search source code" box is available for my paid for private repos, so I guess it's a premium feature.
- porker 14y ago
  Thank you!
mgrouchy 14y ago
for filename, go to the repository (code) window and press 't' , it will give you a command-t type interface to search for filenames in the project.
a9entroy 14y ago
On any repo page you can just press t and you can search by filename.
Zakiazigazi 14y ago
Code search is available - if somewhat hidden. Add /search to the end of the repository url on github (eg. https://github.com/rails/rails/search https://github.com/rails/rails/search ).
boyter 14y ago
Shameless plug, searchco.de allows you to search over github's public repositories, http://searchco.de/?q=irq_create_mapping+url%3Agithub http://searchco.de/?q=irq_create_mapping+url%3Agithub

jakub_g 14y ago

+1 for "likes" in issues.

orefalo 14y ago
Another feature missing: per branch access control
- tomeric 14y ago
  Yes! This would allow developers to set up premium branches: http://premium-branch.org http://premium-branch.org

Adirael 14y ago

"Bifurcar", that term may be correct, but it sounds awful to my ears.

rbonvall 14y ago
It sounds weird indeed. The literal translation of branching would be «ramificar», which also doesn't seem right. That's the problem: everyone comes up with their own translations that are not what people refer to them in real life. I say «crear una rama» (create a branch), while most of my friends just say «hacer un branch» (make a branch). And there are also the ugly anglicisms like «branchear» and «forkear».

zbowling 14y ago

You should add the stuff I posted about last year about this time. Basically my beef is forking being not very in the spirt of how it's supposed to work with git. http://zbowling.github.com/blog/2011/11/25/github/ http://zbowling.github.com/blog/2011/11/25/github/

mbesto 14y ago

Slightly meta - If I was a business owner and a customer wrote something like this, I would be absolutely ecstatic. It shows that you've created an awesome product. So awesome that people want more out of it, and are willing to spend considerable time ($$$) to help you make it better. This is the real reason profit margins are so important to a good company. It means you can re-invest back into the growth of your product and continue to delight your customers. Good on ya Github, keep it up.

niels 14y ago

So apparently this is the new standard in job applications.

NicoJuicy 14y ago

Github shouldn't be localized... Some projects wouldn't be viewed if it ain't in english, no one here almost speaks Chinese do they? :-) Facebook should be localized, not github.

alxndr 14y ago
我会讲中文。
- derleth 14y ago
  > 我会讲中文。 Google Translate renders this as "I can speak Chinese.", which speaks volumes about how far it's come with East Asian languages.

mpeg 14y ago

I know this is a call for help, but I find it funny that their big screenshot in spanish makes no sense to this native speaker.

neilmiddleton 14y ago

Someone wants a job

facorreia 14y ago

"Ruby came from Japan. Lua came from Brazil. Python came from the Netherlands." And all of them use English terms for language identifiers. English is the lingua franca of IT & software development. As a Brazilian I can tell you that programmers that don't learn at least how to read technical English won't become good practicioners. And GitHub is a social platform for collaborating on projects. In the vast majority of projects, English is the common language spoken by all participants. Learn English and get over it. (I didn't read further into the article. I hope the other suggestions make more sense.)

wildchild 14y ago
Agree, but this is business. They need more customers.
FiloSottile 14y ago
Totally. I am Italian, and seriously, most of the blog posts, tutorials and such written in my native language are so bad that only bad programmers can grow out of them. Also, an open source project maintained in, say, Spanish is one I and others can't easily contribute to. That would be a disaster.
- to3m 14y ago
  Projects would have to pick a language that makes sense, given their goals. Perhaps some would be keener on optimising mainly for the existing set of contributors?
  - FiloSottile 14y ago
    I'm not sure about this, it would restrict the future changes, limiting innovations and putting the project at risk of dying when the developers leave, IMHO.
Svip 14y ago
I disagree. My position is not that English is bad (English has some advantages here and there, but it is hardly the best language I know), it is very practical - and necessary - to learn if you want to work in IT. No doubt about it. However, confining ourselves to one language makes us all think the same way. Research has proven time and time again, that learning other languages will help us apply different ways to think about problems, because different languages uses different grammar to convey the same meaning. Effectively, if we continue to strive to eradicate localised IT and software related words from non-English languages and replace them with English words instead, language development will stagnate and all languages will eventually become English. And that is not a positive prospect. I don't need Github localised, but I would like to localise it for the purpose of creating technical terms in my own language. I fear that most of the localisation into Danish would simply be English words instead, despite the fact that Danish actually has words for 'push' and 'pull' (»puf« and »hal«, respectively). And English shouldn't be so cocky either, by its current usage, English is slowly becoming less than a language and more of a tool. And with both foreign and native speakers' continue abuse of the language, English will soon be derived of all its beauty, for the purpose of minimising communication. Are we really that lazy?

minikomi 14y ago

I think i18n makes sense - for docs. For getting people up and running. For explaining the benefits of github.

pixxa 14y ago

The #1 missing feature in github for our team is that we can't attach files directly from Issues Web UI. Usually we need this for screenshots, but sometimes data files, logs and other artifacts. Workarounds are aplenty but all painful and problematic. See https://github.com/thisduck/gh-attachment https://github.com/thisduck/gh-attachment or http://feeding.cloud.geek.nz/2012/06/attaching-files-to-github-issues.html http://feeding.cloud.geek.nz/2012/06/attaching-files-to-gith... not to mention countless internal homegrown hacks that exist out there. This lack of attachments makes it a lot harder for non-techies to use Issues (e.g., for casual or QA testing). Don't get me wrong, I absolutely LOVE the minimalist approach of Issues, and it is definitely _almost_ good enough feature set, but this one missing feature makes it difficult for one to imagine the use of issues at-large in broad organizations--an undiscovered area of growth for github. I would definitely add this to the "I <heart> github, but..." list. P.S., experiment0, great execution of a "feature request".

pixxa 14y ago
My wish came true in less than one day! Check it out https://github.com/blog/1347-issue-attachments https://github.com/blog/1347-issue-attachments

morefranco 14y ago

This is a great personal effort to bring improvements to a platform we all know and love - I've got many friends overseas who all speak (and most critically - think ) in English to varying degrees. Localization is never a wasted effort. I hope they hire you Garen!

Hawkee 14y ago

While it may be an intentional shortcoming, I feel GitHub is lacking in general discussion. Sometimes I just want to ask the developer a question about their code. Usually what I do is look for their Twitter account and @mention the question over to them. It would be nice to find a discussion around a particular repo just as we have here on Hacker News.

juanbyrge 14y ago

How do people have so much free time lol?

why-el 14y ago

I think localisation makes sense for the docs. Maybe we can branch off from here and coordinate the efforts. I myself am ready to work on Arabic and would love to have people join me.

nicholassmith 14y ago
I agree, that's where the localisation should go. Github has many things and for a first timer the docs are invaluable, but if you're a non-native speaker having them in your own language is going to help you ramp up to speed on using it that much quicker.

fphilipe 14y ago

Didn't GitHub have localization at some point in the past? If I remember correctly, the footer had a world map background with links to other languages.

tomeric 14y ago
Yes they did: https://github.com/blog/679-github-in-your-language https://github.com/blog/679-github-in-your-language
deleted 14y ago
[deleted]
foca 14y ago
We did, and then we dropped it because a _very_ small percentage of users were on non-English locales.

dmritard96 14y ago

Doesn't chrome have translation capabilities? I don't know if the translation capabilities can avoid translating code but if it could somehow (a do not translate tag or something) then localization could be done, locally...

d0m 14y ago

Would be nice to have a mega refactor function that could check for duplicate all over the public repos. So, for instance, my "capitalize function" could be tagged as duplicate and I could see multiple projects having a better one.

purephase 14y ago

A few items I'd like to see: - Attachments in the issue tracker. Pictures tell a thousand words and it would be infinitely easier for user submitted issues to have screenshots. - Better code search. - More granularity in the notifications. For instance, I'd love the ability to toggle email for my own repos but leave it to web notifications for my watches. I've missed pull requests because of the deluge of messages. - Better reliability. It's a great tool. I really enjoy using it, but with a few additions it would be near perfect.

lifeisstillgood 14y ago
You can add attchements to issues - please look at my https://github.com/lifeisstillgood/githubkoolaid https://github.com/lifeisstillgood/githubkoolaid (it has one helper script - ghgrab.sh that, well, fires off xwd, and then uploads the resulting screenshot through the github API (mediuated by the excellent ghi) I have no idea if it works outside of FreeBSD - drop me an issue on github if it does :-) WIth a screenshot!
jamesgeck0 14y ago
> More granularity in the notifications. This. If you're part of a big organization with a lot of repos, you'll automatically watch all of them (and forks) as they are created. I'm currently watching 451 repos and have a mess of Gmail filters to (mostly) ignore notifications from repos I don't care about. Priority Inbox helps some in that it makes email actually mostly usable, but Github really needs to fix this. There's an option to turn off auto-watching and a button to stop watching all repos, but there's not really an easy to to say, "I care about this repo and all it's forks, but nothing else." Or, as you mentioned, a way to watch some repos via email and everything else on the web.
dewski 14y ago
We just shipped Issue Attachments: https://github.com/blog/1347-issue-attachments https://github.com/blog/1347-issue-attachments
boyter 14y ago
Shameless plug, searchco.de allows you to search over github, http://searchco.de/?q=irq_create_mapping+url%3Agithub http://searchco.de/?q=irq_create_mapping+url%3Agithub You just need to add the url:github portion to any search. You can do the same over bitbucket, codeplex, google code, sourceforge and the fedora source tree too. See, http://searchco.de/blog/view/variety-of-updates http://searchco.de/blog/view/variety-of-updates

wildchild 14y ago

I think new pricing strategy could make github better.

benmanns 14y ago
What would you suggest?
- wildchild 14y ago
  First of all, it's too expensive. $7 for 5 repos? I'll use bitbucket instead and keep github account for opensource projects. Probably price should depend on a number of collaborators and some special features.
webology 14y ago
I agree. I moved to bitbucket after canceling their small service because jumping from $12 to $22 just for a few more private repos. I wish they had more a of a hobbyist plan with maybe a storage limit or a $1 a repo type pricing. I didn't care for their practice of deleting forum posts every time someone would ask about similar questions. I still recommend them for my clients though.

FiloSottile 14y ago

Actually, more than labels (that would be good anyway) I would LOVE seeing the open/closed state of issues in notifications. I spend a lot of time checking new issues already closed by the other project maintainer.

gavanwoolery 14y ago

The famous "hacker faq" recommends using English for a few reasons: http://www.catb.org/esr/faqs/hacker-howto.html#skills4 http://www.catb.org/esr/faqs/hacker-howto.html#skills4 Other than that... Since code is shared across many different countries, we cannot be too wishy-washy about which one to use. English is rated as "the most influential language in the world" in terms of how many countries use it and the socio-economic standing of these countries. I hate to be the one to push English (as a native speaker myself), but as you can see others on this thread recommend it, even though it is not their native tongue. By all means, I do not promote destroying cultures, but learning a common language brings us all closer together. :)

lifeisstillgood 14y ago
I like the sentiment, but might I point out that the early inventors of television believed that it might end war by showing the great similarities between peoples and nations. And that from domestic violence to wars, we tend to fight those who are next-door, closest to us in mind body and spirit. (If you are not too sure about that, think how easily a rural Shinto Chinese would be able to explain the vast differences between Christianity and Islam)
- alxndr 14y ago
  Shinto Chinese?
  - lifeisstillgood 14y ago
    Yeah that was dumb of me. I may have been thinking Shenism, but I am sure there are some Shinto Chinese. Anyway the point I am making still holds I think - you can barely squeeze a credit card between Islam and Christianity if viewed from a distance - yet billions are on the edge because of the "vast gulf" between the religious

prezjordan 14y ago

I thought this was a GitHub promotion at first, but this is a genius form of self-marketing. Very creative, and very convincing!

pbiggar 14y ago

I slightly agree about CLAs. Contributor Licence Agreements are largely ignored by most small open source projects because they're a pain in the ass and prevent contributors from contributing. However, I think they could go further than the support discussed here. It would be great to see CLAs tht you could get asked to sign when you make a pull request. You could also make it easy to sign - maybe instead of printing and scanning, you could sign using a PGP key. If Github incorporated this stuff, every project could seamlessly use CLAs.

apaprocki 14y ago
Paperlex has a public free CLA manager which integrates with GitHub: http://clam.paperlex.com/ http://clam.paperlex.com/
- pbiggar 14y ago
  I took a quick tour, and I believe this would be too cumbersome compared to an integrated solution.

louischatriot 14y ago

Very interesting proposals overall, not too sure about the localization (don't most programmers speak English ?) though.

hunvreus 14y ago

From what I remember, Github had localization going on but pulled the plug at some point because it was too much of a clusterfk. I was surprised not to see any mention of the only thing that irks me: the "Switch account context" dropdown menu being available only on the front page and not in the top bar where your account is displayed. That would save me quite a bit of gymnastic to have that displayed on all pages.

hoggle 14y ago

I'm a native German speaker and this localization thing seems like a really bad idea. I can understand where the github folks are coming from but it really is a thing not worth putting any effort into. I sympathize with the humanism but programming and programmer communication should be mostly pragmatic. The open source community is a global thing and English has won a long time ago as the definitive choice for a global language. It seems like it's easy enough to pick up for a lot of people all over the world. In my opinion it works especially well for technical writing.

jlarocco 14y ago
Actually, as far as I can tell, it has nothing to do with "official" GitHub. It's some guy with the GitHub username "letsmake" using GitHub pages [1]. I really wish GitHub would start doing something about people using that feature to make it look like they're part of (or speaking for) GitHub. It's incredibly misleading some times. [1] http://pages.github.com/ http://pages.github.com/
- shabble 14y ago
  Sites that allow users [to have significant control over] personalised subdomains are also problematic for things like NoScript and other whitelisting tools. Since I have github.com permitted, all the subdomains inherit that permission. I'm not even sure what a good model/UI would be to selectively white/blacklist subdomains.
  - gsiener 14y ago
    Maybe github should use a different TLD for pages? Like Githubpages.com ?
  - alter8 14y ago
    That is a problem only because Github uses the root domain for its own pages. They could rather use www.github.com. To solve your case on NoScript, whitelist the full address https://github.com/ https://github.com/ and that will keep http subdomains out.

wildchild 14y ago

I suggest read-only SSH keys for deployments.

moe 14y ago

The first thing I do when I come across a site that tries to speak my language? I switch it back to english. Localization makes sense when you're a shopping site aiming at mom & dad and non-techies. For technical services (pretty much all SaaS) the translations usually turn out so terrible that everyone turns them off. Also good luck googling for the solution to a problem in any other than the primary language of the site...

rsanheim 14y ago

GitHub used to have localization, back before I joined, but it got dropped. Many non-native speakers switched to English anyways, and it just wasn't worth the effort and maintenance hassle.

jelder 14y ago

I appreciate this guy's effort, but honestly most of his concerns has ever impacted my productivity. Sure, the editor isn't great yet. What I really want to see, and I'm not the first to say this: * Explicit licenses: If a repo lacks a LICENSE file, this is almost as annoying as it lacking a README, and GitHub's interface should complain to the repo owner. Searching and filtering by license would be nice, too. * Explicitly "official" forks. It's way too hard to find the right fork when you just want to improve a public gem, for instance. I was there was an explicit "why does this fork exist" field on each repo. acts_as_solr is a particularly morbid example of why this is important. * Their code search is basically useless. Last I checked, they don't even index branches. They should just buy or reimplement Ohloh.

boyter 14y ago
Shameless plug, searchco.de allows you to search over github, http://searchco.de/?q=irq_create_mapping+url%3Agithub http://searchco.de/?q=irq_create_mapping+url%3Agithub You just need to add the url:github portion to any search. No branch support yet, but working on it. I doubt they will be able to buy Ohloh though as that's owned by BlackDuck. I also find Ohloh search lacking in some areas such as the following search, http://searchco.de/?q=%3D~+lang%3Aperl http://searchco.de/?q=%3D~+lang%3Aperl http://code.ohloh.net/search?s=%3D~&browser=Default http://code.ohloh.net/search?s=%3D~&browser=Default

digerata 14y ago

Infinite scrolling? Yuck.

deleted 14y ago
[deleted]

webology 14y ago

I'd love to see a "grouped" pull request option. Something that would let me say show me changes from repo1 + repo2 because they depend on each other. Think refactoring code into a smaller repo, etc. I deal with this quite a bit with clients as they grow from small apps into much more complex apps with lots of inner dependencies and tests.

sdesol 14y ago
We (my company) actually take this to another level. We provide branch level grouping. http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e.r94.cf1.rackcdn.com/search-result.png http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e... The reason why we've created this feature was because in the enterprise world, it is not uncommon to construct a release based on branches from various repositories. We also have a smart attributes technology that will allow you to assign arbitrary meta data to a pull request. With this technology, you'll be able to ask questions like show me all the pull requests that have a priority greater than X.

themgt 14y ago

What if we spent our time making GitLab (http://gitlabhq.com/ http://gitlabhq.com/) better instead, since it's open source and users can host their own for free?

nuclear_eclipse 14y ago
One of the biggest draws of Github (to me) is that it's one central place for me to go for a wide array of projects that I work with, and where a lot of people I know can host their code to share with the large community of developers already on Github. By using Gitlab on your own hosting, you lose all of that convenience of having everything in one place. Imagine that every time you want to contribute to a project, you have recreate yet another user account, upload all of your SSH keys again, and more. And then further imagine that you want to fork and work on repos from multiple projects that all have their own Gitlab instances, and now checking on your projects requires visiting N different sites to get the same information that you already get from a single login to Github. Now I'm just as big of a fan of open source as the next person, but having a single central place to visit for projects is a Good Thing, and IMO Github has proven time and again that they actually care about the open source community as much as we do, and have done so much to foster communication and interaction between developers that their contributions are far more important to me than the value of having my code repositories hosted on an open source platform.
- themgt 14y ago
  I agree, and I think GitHub is a fantastic resource for open-source projects, but it's a bit of a lobster trap in the sense that its existence lessons the need for an open-source alternative, but then locks you in to a paid model once you need private repositories. What we should be looking for is an open-source project that allows people to keep their own projects private on their existing hosting, and allows easy sync with github for public projects.

FiloSottile 14y ago

Issues images, headshot: https://github.com/blog/1347-issue-attachments https://github.com/blog/1347-issue-attachments And don't tell me that you Githubbers don't lurk over here ;)

reledi 14y ago

Some good points, but I disagree with the following. - i18n and l10n For reasons already stated by many others in this HN thread. - Notifications should be more like email Please no. I'm already terrified of my email inbox. It's a mess, so many messages. Sometimes I'll leave a message unread or mark it as unread if I want to return to it later but instead it gets buried by newer messages. So now I have a couple of hundred unread emails and I have no idea what they are but they surely can't be important. Keep notifications how they are. It makes using GitHub stress free. If I read a notification, get rid of it so I never have to see it again. If it was so important, I should remember it anyway or I would have set it as my highest priority and worked on it right away. - Revamp Inline Editing Themes? Multiple cursors? Command line? Live linting? ... No thanks, sounds like feature-creep. I like the editor how it is, nice and simple. Want a full-blown editor? Don't use the web interface. - Infinite newsfeed There are reasons why many websites choose not to include infinite scrolling, see [1] for some good reasons. One thing I'd like to see added to GitHub: - View all public activity history There's been many times when I want to look at my own history or someone else's and I can't because it stops after the first page. [1] http://www.quora.com/Infinite-Scrolling/What-are-the-downsides-of-using-automatic-scrolling-pagination http://www.quora.com/Infinite-Scrolling/What-are-the-downsid...

freshhawk 14y ago

Let's volunteer to work for a commercial entity for free? No thanks. They're doing fine, they can easily afford to pay people to do this if it's necessary. Volunteer your time for non-commercial projects that do not have the option of paying people a fair wage for their work.

hmsimha 14y ago

I thought it worth mentioning that everyone opposed to this idea is capable of communicating in English. I am guilty of being monolingual, but if the most popular online source code management community used a language X that I did not know how to speak (especially if X was considered the lingua franca of software development), it would be a huge barrier of entry to me. While I would do well to learn X, an english localization of that platform would greatly ease my transition and encourage me to communicate with the predominantly-X speaking community. I would like to get the opinions on localization of github from people who are currently unable to communicate in English with a high enough proficiency to read these comments and voice their position here.