Generally the UI is just poorly designed and unfocused. One specific thing: You can't mark them as approved in any way and doing something like +1 in a comment somewhere doesn't count.
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 command line to also support Markdown rendering/preview.
It seems like some of these (perhaps all of them other than fixing the "+1" problem) can be done via API clients instead of via GitHub itself implementing it. A third-party website can do wiki searches. A separate service can send you email notifications, and you can turn off built-in emails.
Even the +1 thing might be solvable with a bot that edits each bug report to add a clickable +1 badge (a la the CI build-passing badges) at the top; all you need is to give the bot ownership of your repository. The badge can display the current +n count, and the service can give you a sorted list of open issues by +n. For bonus points, have the bot also harvest and remove comments that consist of just "+1" or ":+1".
This is GitHub after all; why don't we build stuff ourselves instead of waiting for a centralized closed-source company to decide they care about our features?
>This is GitHub after all; why don't we build stuff ourselves instead of waiting for a centralized closed-source company to decide they care about our features?
Why would I build something for a centralized closed-source company?
Because then the only thing you're relying on the centralized closed-source company for is actual git hosting. This is a boring problem that dozens of other services solve well, and thousands of other services (like S3) solve poorly in a pinch. If you can migrate the interesting part of GitHub -- issue tracking, PRs, wikis, etc. -- to another provider, and GitHub just holds your data, then you're no longer locked in.
If you don't build it and you wait for the centralized closed-source company to, then you're putting your project even more in their hands.
Migrating issue tracking and other stuff out of Github seems like a good idea if you want to reduce dependency, building a bot on top of Github issues - what you implied in your parent post - not so much.
You could build the features for GitLab. We'll roll them out on GitLab.com that you can use for free. We can import repo's and issues already and are working on PR's and wiki's.
ZenHub was the name I was trying to think of, thanks, but it seems like a thing everyone needs to opt into to make good use of (I think? in that it's a browser extension?). The idea I had is more along the lines of the CI badges, which don't require any action on the end-user's part. It's just an image inside a link, so it works in every browser already.
If ZenHub supports making its features available to OSS projects without needing every contributor to install the extension, that's much more compelling, and also totally not obvious from their website.
>it seems like a thing everyone needs to opt into to make good use of
Yep! Which is why I gave up on trying to use it. I thought it would gain major traction given how useful it is - but I felt like the only person using it. So I eventually removed the extension.
>Not affiliated, used it, but without others using it it's largely...well.. useless. :)
I reported this a while back, so it's in their backlog somewhere but obviously not super-important:
I'd like to see an option to turn off fork notifications for org projects without turning off all org notifications. As-is, I get an email for every dev forking every project, sometimes more than once due to lack of git knowledge.
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.
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 dashboard for sprints, defect fixes, issues tracking, etc. That's the type of "enterprisey" thing that attracts more business subscriptions. They use the storage of sourcecode repositories to open doors to other sw development related business.
These are just my guesses. I haven't seen any explicit roadmap from github.
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.
I'd argue that's still a bit of a pain compared to a fulltext search in the browser. I can already search the rest of the repo and issues that way, so why not the wiki?
My biggest pet-peeve about GitHub is its issue tracker system. It's great for one-off issues or tracking a pull-request, but beyond that its design is super unwieldy. Such a missed opportunity to crush JIRA, et. al.
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
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 Deploy - deploy tooling for deploying runnable artifacts or artifact combinations to either your own infrastructure, or to aws/azure/google, or:
* Github Cloud - instances/containers as a service
and the 'fork' button would be a pulldown that would include the options 'fork', 'fork and test', 'fork, test and deploy'. Now that's a nice little 3-4 year career.
A github CI would be awesome! I imagine it would get very costly for them though. I love Travis-CI and the easy integration, but it's too expensive for my non-open source projects.
Continuous Integration. A good example of that service would be something like http://travis-ci.org or https://jenkins-ci.org. Basically it's a service that runs some predefined task (usually your test suites) at important points: when something is pushed to or merged into master, when a Pull Request is opened, etc...
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 :(
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, there's IRC, Gitter, and Slack, all great options for messaging/chat.
> 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.
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.
Actually opening issues via email would be nice to. Trac isn't perfect, but I remember email2trac[1] quite fondly. Combined with email notifications on change, it made it easy to forward bug/error-reports to a trac instance, and automatically create an issue. Or just let support@ go straight to trac.
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.
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.)
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 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.
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.
Great minds... I was talking about this the other day with the other engineers at work, after learning about GitHub's most recent monstrous funding round. It seems like CI/a deployment service and something that competes in the crowded PaaS field is the next logical step.
AWS enables us to do some pretty slick things, but OpsWorks is a giant bag of suck that frequently finds a way to drain my time troubleshooting why something crazy or random has happened on the production server--behaviors I never saw in my previous role running a bare-metal LAMP stack for 4 years. A tighter integration between our GitHub repo and a testing/build server... Swoon.
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.
All these are nice, but are not must-haves as they can be built outside of GitHub. The show-stopper for me is granular permissions - coming from the Gitolite [0] world, where I can permission even branches and do all kinds of checks and balances on the server, GitHub is a joke for a not-so-large enterprise! Another thing is the Wiki - why pages are based on Git and the Wiki is not?!
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.
You could always use CloudFlare directly for that... I would presume that their underlying connection to Github is very close and reliable in terms of risk for MITM.
> 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.
Lots of things. Github ships features like crazy. Lots of the features I use every single day were only released in the last few months. On a scale of years, all of their desktop clients, which are a huge experience improvement for new users.
Great list, we're working on making something that makes +1's less noisey. If you want the possibility to contribute to the tools you use daily consider using our GitLab. It is open source and more than 800 people have contributed already.
I think GitLab supports it https://gitlab.com/gitlab-org/omnibus-gitlab/issues/412 but we have not had the time to set it up for GitLab.com yet. We'll be moving our infrastructure to Azure soon so it is not a priority for us now.
Wiki search is #1 on my wish list for Github. I see others talking about cloning the wiki repo locally and searching it but for big projects this would be the equivalent of downloading something like the Python docs and searching them. It could be done but it would be a massive pain in the ass.
I have written most of the documentation for the project I contribute to the most and I organized the wiki like a two level tree where a top level page has links to category pages and each page on the wiki is linked to from one of those category pages. Then there are links interspersed among the pages like a normal wiki. This structure works okay but I know it can be better because sometimes I cannot even find information that I produced!
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 site these days.
144 comments
[ 3.1 ms ] story [ 149 ms ] threadI'd be much more enthusiastic if there was some magical way for the local git command line to also support Markdown rendering/preview.
Even the +1 thing might be solvable with a bot that edits each bug report to add a clickable +1 badge (a la the CI build-passing badges) at the top; all you need is to give the bot ownership of your repository. The badge can display the current +n count, and the service can give you a sorted list of open issues by +n. For bonus points, have the bot also harvest and remove comments that consist of just "+1" or ":+1".
This is GitHub after all; why don't we build stuff ourselves instead of waiting for a centralized closed-source company to decide they care about our features?
Why would I build something for a centralized closed-source company?
If you don't build it and you wait for the centralized closed-source company to, then you're putting your project even more in their hands.
https://www.zenhub.io/
Not affiliated, used it, but without others using it it's largely...well.. useless. :)
E:
Hmm... seems it has become $5/mo to use. I remember it being free. Wonder when that happened?
E2:
>ZenHub is free for the open source community.
Oh.
If ZenHub supports making its features available to OSS projects without needing every contributor to install the extension, that's much more compelling, and also totally not obvious from their website.
Yep! Which is why I gave up on trying to use it. I thought it would gain major traction given how useful it is - but I felt like the only person using it. So I eventually removed the extension.
>Not affiliated, used it, but without others using it it's largely...well.. useless. :)
I would also implement a button for reverting pull requests already merged in master. Reverting merges may be not trivial for less experienced users
I'd like to see an option to turn off fork notifications for org projects without turning off all org notifications. As-is, I get an email for every dev forking every project, sometimes more than once due to lack of git knowledge.
Maybe github is focusing on creating a full software development lifecycle management (ALM) in the cloud. (Like Microsoft Team Foundation Server and JIRA.) A dashboard for sprints, defect fixes, issues tracking, etc. That's the type of "enterprisey" thing that attracts more business subscriptions. They use the storage of sourcecode repositories to open doors to other sw development related business.
These are just my guesses. I haven't seen any explicit roadmap from github.
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.
QED.
Good tip though.
- 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
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
* 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 - deploy tooling for deploying runnable artifacts or artifact combinations to either your own infrastructure, or to aws/azure/google, or:
* Github Cloud - instances/containers as a service
and the 'fork' button would be a pulldown that would include the options 'fork', 'fork and test', 'fork, test and deploy'. Now that's a nice little 3-4 year career.
Anyway, if you want it today consider using our GitLab CI https://about.gitlab.com/gitlab-ci/ it is free if you bring your own runner.
I bet you could work on small polish issues like this for a lifetime and never finish. There's always something to improve.
Bugfixes are not feature enhancements.
Also this makes you sound like a pleasant person to work with.....a real go getter.
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, there's IRC, Gitter, and Slack, all great options for messaging/chat.
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.
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.
[1] https://oss.trac.surfsara.nl/email2trac
It sounds like what you really want is nested threads and top quoting and/or interstitial quote/response features?
(Arguably what you really need is commonly called a conference.)
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.)
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.
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 ]
AWS enables us to do some pretty slick things, but OpsWorks is a giant bag of suck that frequently finds a way to drain my time troubleshooting why something crazy or random has happened on the production server--behaviors I never saw in my previous role running a bare-metal LAMP stack for 4 years. A tighter integration between our GitHub repo and a testing/build server... Swoon.
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.
[0] http://gitolite.com/
After exploring Visual Studio Online (its free for 5 users), I am still not able to digest why there isn't a build and deploy system in GitHub.
There were great demos at Microsoft's BUILD15 for Automated Build and Release Management which demonstrates these features.
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.
* Change the target branch of a pull request pull-requests
* Delete / remove an issue completely.
* Gist comments and mentions don't trigger notifications
* Add HTTPS support to Github Pages
* Add ability to follow organizations like a user
* Insert automatically generated table of contents TOC on rendered markdown files like README.md.
* pre { tab-size: 4 }
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
So you traffic between CloudFlare and GitHub will also be secured.
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.
(Yes, by which I am saying their website has not improved much given their massive funding)
What are they working on?
Lots of things. Github ships features like crazy. Lots of the features I use every single day were only released in the last few months. On a scale of years, all of their desktop clients, which are a huge experience improvement for new users.
I have written most of the documentation for the project I contribute to the most and I organized the wiki like a two level tree where a top level page has links to category pages and each page on the wiki is linked to from one of those category pages. Then there are links interspersed among the pages like a normal wiki. This structure works okay but I know it can be better because sometimes I cannot even find information that I produced!
wireless site:https://github.com/esp8266/esp8266-wiki/wiki
> 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 site these days.
As for sorting things by file, here's a pretty cool project to do that using GitHub API - https://github.com/sivel/pr-triage