101–110 of 145 posts
Earlier quoted context omitted.
Because then users can't simply send an email to create a new topic to talk about...
So that's the one blocker? Creating an issue via email?
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…
Earlier quoted context omitted.
Of all the things I wish Github had, a mailing list service would be really amazing, and the kind of thing that wouldn't be done in the first few months. Sourceforge offers atrocious mailman-based email, larger foss projects on github suffer :(
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,…
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 maintain group membership, user-meta-data either in different user-databases, or via some form of federation.
No longer is removing a user/ssh-key from a github project enough to plug a hole in case of a hacked account.
Discourse isn't (that) bad -- but mailinglists are a lot better IMNHO. If you have a half-decent email program, like mutt, or even (al)pine.
At any rate, the ability to work via email (get bugs via email, close bugs via email) leverage what email is good at: off-line+synchronization. Which is one of the things git is good for. You know, distributed work.
Earlier quoted context omitted.
So that's the one blocker? Creating an issue via email?
No, the blocker is setting up mailing lists with a forum-like interface (cf. discourse), but integrated to github (uses the github account) and without actually having to do the setup. Also, without polluting issues.
I still think having an email interface (as in: in addition to a REST API) is very useful. Having a web interface as well isn't bad either.
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'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…
Earlier quoted context omitted.
> Add HTTPS support to Github Pages This is technically already available, though not officially documented anywhere [1]. Example [2] [1] https://github.com/isaacs/github/issues/156#issuecomment-377... [2] https://beltex.github.io
While that's true, I think the discussion in that issue has gone more towards HTTPS support for custom domains.
A huge number of those "+1 for HTTPS on custom domains" don't seem to understand/appreciate the difference in providing HTTPS on the *.github.io (one wildcard cert) vs. HTTPS support for custom domains.
The latter would require an interface (UX being key here) and storage for uploading your own domain certificates to GitHub, which is nothing like any other part of GitHub right now. I also presume that most of these "+1's" would want this service to remain free.
I understand this will be a huge amount of data (they must have hundreds of millions if not billions of commits by now). I'd be perfectly happy if this was only available for paid repositories.
The ability to then further facet and filter searches by author, file, directory etc would be unbelievably useful.
The biggest thing I want from GitHub is the ability to search commits. GitHub are pretty good at search (their issue search is fantastic, and their code search is decent enough) - but the data I most want to search are the commit messages in my repo. I understand this will be a huge amount of data (they must have hundreds of millions if not billions of commits by now). I'd be perfectly happy if this was only availabl…