Hi Ron,
The typical approach is for people to use the `rbt post` command to post a change for review. The workflow generally looks like this:
1) Create a branch, work on code, commit.
2) When ready for review, run: `rbt post`
3) Go to URL provided, fill out any fields you want to fill out, then publish the review request.
4) After receiving feedback, make changes on your branch. Then update your review request with: rbt post -u
5) Repeat until you get approval to land.
6) When ready to land, go to your destination branch (say, master) and use: rbt land <feature-branch-name>
RBTools (rbt post, and other related tools) give a lot of control for interfacing with review requests. rbt post and land, in particular, are very useful tools that we highly recommend when working with Review Board.
rbt post is responsible not only for creating/updating review requests based on local changes, but also making sure that diffs are generated correctly. There are a lot of ways to generate diffs, most of them useless to us (even by default), so RBTools takes care of generating them correctly (and even working around issues in the way that some types of repository tools generate diffs).
rbt land verifies that your review request has been approved (by default this means 1 or more Ship Its and no open issues -- this logic can be customized through Review Board extensions), and then lands it, formatting the commit message to include the review request description, testing that was done, bug numbers, and a link to the review request itself.
The GitHub webhook that Review Board provides looks for the link to the review request in any pushed commits. If it sees any, it closes that review request, keeping the dashboard nice and tidy.
So that's the standard approach, and it's what we recommend and design for. It gives developers complete control over their review requests and means you don't need to maintain any scripts that duplicate any of that work. If you did decide to write something to listen for commits and to post them automatically on behalf of users, you're still going to want to use RBTools to do the actual work. At that point, you might as well let the developers run it themselves, so they're in control.
We do not have a GUI wrapper for this, though I know some people have added shortcuts to their IDEs to invoke these commands (I do not have anything I can point you to there -- I think it's all been internal at companies).
Christian