Just wanted to note that a fork is automatically created and a pull request created when you edit a file in a repository you don't have push access to. So the workflow is even simpler: 1.) see file, 2.) edit file and save, 3.) land on send pull request page.

great. But perhaps a fork is still needed for editing multiple files and submitting as one pull request?

or the pull request would accumulate changes?

I cannot reproduce but I noticed a situation when I was issuing multiple pull requests and the previous pull request somehow got commits that weren't intended to end up there; so I begin to think that it was intentional.

(just asking because I would like to avoid creating a tmp github account just to try that out, otherwise I wouldn't bother you with silly questions)

Pull requests do seem to accumulate changes if you push to your fork while there's one open.

Ace is gradually gaining full IDE features like syntax checking, split views, and responsive behaviours such as auto-brace/bracket/parens insertion.

If you want an online-only workflow, Cloud9 already offers github as a backend for an Ace powered IDE. I think Ajax.org have hired someone to work on IntelliSense style auto-complete for Cloud9, not sure if those will be suitable to be put into Ace itself.

how is split views an ide feature?

Imho, if i'm going to download the code to run and test it anyway, i might as well use an editor on my computer (vim/e/sublime) and skip Ace.

> Just fork a project to your account on github, edit in Ace, and then making a pull request when you are done.

Github's edit feature does all that: if you're trying to edit a file in a third party's project, it creates a fork and opens the file for editing, and creates a pull request when you commit your edit.

> If not, is Ace just going to be for minor edits, etc?

Well yeah, since you can't really test the code (for now at least, maybe they'll build some sort of testrunner via VMs later on) it's not like you can perform significant code editions with it. But for docfixes, typos or minor stuff it's very handy.

    Just fork a project to your account on github, edit in Ace, and then make a pull request when you are done.

I'm not sure that would be plausible for anything other than documentation or maybe typo fixes in string literals. I would ask contributors to my projects to make sure they've run tests (and made new ones, if need be) before sending a pull request.

I wonder if joint support with somebody like heroku is coming. Being able to develop and deploy all from your web browser would be a very cool feature.

Of note, this was the core feature of Heroku when they first started out (no need to know git/command line).

Well, you can't run tests on code you edit this way; I'd say its intended usage is just minor edits such as typoes.

Well this sounds like a problem that could be fixed quite easily, albeit it would cost some money to do so. But for people willing to pay for this kind of workflow it would be no issue to provide them with a testing machine. Since you only run tests every few minutes or so it wouldn't even be too resource intensive for most people.

Travis-ci is already doing something to that effect. Check them out. https://github.com/travis-ci/travis-ci

I hope that someday you can work like that. But I doubt that people can work like that when they are not able to test their code. At least adding unit test capabilities is absolutely nessesary for that.

Well, I just did a fork -> edit with Ace -> pull request for two little documentation fixes in a library I use. It was quite convenient. But I don't see using it for a project I frequently contribute to, unless I'm stuck away from my usual dev environment (which would be strange, since it's my laptop).