Or, maybe it could use a forking model? Let anyone fork their own PR from mine, make those forks prominently visible in my base PR, and make it easy for me to merge their edits back in.
Github is for people who accept centralization.
Some centralization is necessary, true, but you seem to be confusing GitHub with Google Code and SourceForge.
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.
wireless site:https://github.com/esp8266/esp8266-wiki/wiki
As for sorting things by file, here's a pretty cool project to do that using GitHub API - https://github.com/sivel/pr-triage
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.
Really useful to get updates on new releases of libraries you use.
1. git blame file 2. click on a hash for the change 3. show the file for that change
Right now, (3) shows you the diff for the hash
I agree with every you said but that first sentence. How are these bugs? They are features that never existed.
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 be much more enthusiastic if there was some magical way for the local git command line to also support Markdown rendering/preview.
Good tip though.
QED.
Something to build tools on top of.
;-)
* 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.
I bet you could work on small polish issues like this for a lifetime and never finish. There's always something to improve.
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.
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.
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.
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.
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.
Bugfixes are not feature enhancements.
Also this makes you sound like a pleasant person to work with.....a real go getter.
> 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.
* 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...
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?
Gah.
If today you see that a major repository has a fork with a lot of commits, you cannot know without looking through THEM ALL if they are just typo fixes or if the fork is really changing/improving things over the main 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 available for paid repositories.
The ability to then further facet and filter searches by author, file, directory etc would be unbelievably useful.
However, for non-members it would be far more useful to know what the file is. Here, enabling a one-line description would be hugely helpful.
Since GH knows if you're a member of the project it can show you the right text--description or latest update. And presumably, a button would allow you to see the other text if you needed it.
(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've setup a few machines with IPv6-only network connections, and it makes pulling my dotfiles from github a pain since I need an IPv4-proxy/tunnel to access github.com
code is read way more often than written. and on github website all you can do is read it. why the viewports don't take up the entire screen width i will never understand.
I'm sure there's an easier way to do this. I'm pretty certain I cribbed the method of setting a style from a StackOverflow article or other thing found online, but that was three years ago so I do not recall where it was. (Sorry.) I think all I did was poke around the Chrome debugger until I found the styles I needed.
- 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
- No ability to store the tab size setting. While appending '?ts=2' to the url is ok, it's not convenient and usable on a daily basis. The same for omitting whitespace changes in a diff / pr ('?ws=1').
- No ability to step through history on a single file while in blob view, or blame view. In blame view, the commit link goes to the commit, not the blame of the file at that commit.
- Agree with OP that notifications need to be grouped / summarized better. Perhaps expandable summary items per repo per type. This is mostly useful for private, work-related repos. Pulse and notifications are basically the same thing.
- Stars cannot be tagged. This makes managing hundreds of stars difficult. There's apps like Astral, but even those are lacking.
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.
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!
* Push conflicted branches so developers in a distributed team can work together to resolve conflicts.
* A git-powered version of Rake, which runs only those tests that need to be run based on the git history since the last run.
* A tool to identify what code changes caused a particular test to fail, based on the above.
* Language syntax detection for smarter diffs, improving the display when blocks of code are moved around or indented/outdented.
* Language linters built in, to detect when a change is introducing a syntax error. Same for coding style.
I'd also move the "Close Pull Request" button a little farther away from the "Comment" button, and make it possible to add comments to a diff when you've hidden whitespace differences (with `&w=1`... I'd also make it a bit more obvious that you could do that).
I think you mean "magic".
That is, this is not possible :) Not that I wouldn't like it to be.
* Gather coverage information when running tests or compiling assets.
* Use that to generate Rakefiles for running tests / compiling assets that have dependencies on the source files they would touch.
* Run the tests once, recording information about the git status of each dependency.
* When the git status of a file changes (i.e. you've just fetched some changes), mark the dependency as dirty
Even better, it you're gathering coverage data and know the test status for each commit, then not only can you show the commit that broke the build, you can show the particular part of the diff that broke the build.
Here's a guy who was trying to do some of this: https://github.com/Genki-S/ttnt
Though following the resolution of an issue usually means I'd like for it to be resolved, the converse isn't true: I've hit thousands of issues over the years but most of the time I've been able to work around them and haven't hit it since, resolving the issue would be nice for people coming after me, but I don't really care to be spammed by its status updates.
So yes, "subscribe" could count as a +1, but no "subscribe" should not be the only way to "+1" an issue.
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.
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.
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
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. :)
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.
So you traffic between CloudFlare and GitHub will also be secured.
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:
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.
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.)
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.
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.)