There are several github cli clients that might be of interest — the one I use is called hub, which has support for creating pull requests by running: hub pull-request And optionally takes some arguments like: hub pull-request -b github-username:their-branch-name -h my-username:my-branch-name It can't list open requests, however it does support checking out a branch straight from a pull request url, so if you have the url, you can just do: hub checkout https://github.com/username/projectname/pull/12 custom-branch-name Then after reviewing the changes, merging them into the target branch, and pushing upstream, github will automatically close out the request. The hub github page is: https://github.com/github/hub On Sep 4, 2014, at 8:46 PM, Aaron Cannon <cannona@xxxxxxxxxxxxxxxxxxxxxx> wrote: > I agree. GitHub is a very efficient way to manage an open source > project, and while it doesn't have perfect accessibility, it's > sufficiently accessible as to not pose much of a challenge. > > Aaron > > On 9/4/14, Ken Perry <kperry@xxxxxxx> wrote: >> Um why does it rule out blind developers. I as one 100% blind user with >> Jaws felt that I would hate github but when I started using it I found that >> it was extremely accessible. What seems to be the problem with it? >> >> Ken >> >> -----Original Message----- >> From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx >> [mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of Mesar >> Hameed >> Sent: Thursday, September 4, 2014 10:16 AM >> To: liblouis-liblouisxml@xxxxxxxxxxxxx >> Subject: [liblouis-liblouisxml] Re: Doing fork from CLI >> >> Hi Christian, >> >> On Thu 04/09/14,14:10, Christian Egli wrote: >>> Hi all >>> >>> On 09/04/2014 12:36 PM, Mesar Hameed wrote: >>>> github only allows for a very strict workflow with git, which may >>>> not be suitable for all people or all projects. >>> >>> It might be strict and simple but it makes it easy and efficient for >>> me. I can not sink endless amount of time into liblouis and using the >>> github workflow makes it very efficient for me. >> >> It might be efficient for sighted developers, but if it rules out blind >> developers or contributors then I think this is not really a tenable >> position, especially considering the nature of the project. >> >>> If the patches come in via pull request I will look at them. If they >>> are hidden on some branch with no pull request they will be forgotten >> >> $ git branch -r >> >> will show remote branches, and is accessible. this is not hidden. >> >> There are some good online git resources if you need to be more comfortable >> with the git command line client. >> >>> just like in the last release. >> >> It was our first release as the new team, and things can always be improved. >> These are teething problems while we settle with git and our new >> responsibilities. >> >>>> We can apply your patches in seperate branches until they are ready, >>>> much like we have with tables/ueb, hammera_hu etc. >>> >>> To be honest I'd prefer if this stuff was in a separate repo with pull >>> requests. >> >> Idealy yes, but remember that the screenreader user has very little power in >> getting github to make their product more accessible. >> So we should not add additional burden for those that are screen reader >> users, especially since this doesn't give us any real benefits. >> >> thanks, >> Mesar >> For a description of the software, to download it and links to >> project pages go to http://www.abilitiessoft.com >> > For a description of the software, to download it and links to > project pages go to http://www.abilitiessoft.com