Github does all kinds of non-standard stuff like putting the requested response format in the URI path instead of as an extension, e.g. "http://github.com/api/v2/json/repos/search/ruby+testing. So just because Github has done it, doesn't mean everyone else should too.
That could be related to their decision to use only JSON as the interchange format though.
match 'jobs' => 'jobs#index', :via => :get, :as => :jobs
match 'jobs' => 'jobs#create', :via => :post
resources :job, :controller => 'jobs', :except => [:index, :create]
It's your call as to whether you think this is worthwhile, but we think that these small details matter, even in URLs.
Any rails helpers that depend on default resource routes will break or require special decorators to maintain consistency. Experience rails developers entering your code base will be confused why their newest partial didn't just work, and will have to learn in one form or another the customization this gem provides.
So now you maintain an entire "system" on top of rails for the benefit of reversing the pluralization of models, something a well placed monkey patch could do with less lines and overall maintenance.
All of this of course is limited to my opinion, your miles may vary. Generally, I've learned from those more experienced that quick and dirty will get you farther, faster, than building things you will never use.
BTW I think in the case of pull requests, pulls isn't a nice shortened version of pull_requests, and pull_requests is just too long for how often it's used. GitHub still uses the plural form for issues. https://github.com/kriszyp/rql/issues/14
It removes flawed tradition and makes it a lot easier to see which routes matter vs. which ones exist just because rails added them. Note that the example routes also avoid new/edit routes since this app actually generates those views on the client side.
Beyond that, plural or not, that's pretty much going to add zero value. Some people claim that the URL is an interface. While it might be, that's usually the lack of a better UI and a poor excuse to call something usable. I'll happily hide my URL bar when I can and rarely care to even write a proper URL by hand. Not because I can't but because I'm not a machine.
Now I do care about nice URI design but that's for me to care about, not the user. More and more I see people linking to things through shortening services anyway... so when do you really read a URL before following it? Probably never. Things like this are just for developer sanity.
So if you're going to bother writing a library, make it easier to express URIs that won't need to change and are explicitly designed, rather than worry over developer vanity and hiding details behind poorly thought out CRUD that people like to pretend is REST.
my biggest problem with the default crud routes is create/update url mapping. if create fails, it will usually re-render edit, but now you have it over non-edit url. create actually shares url with index, and so if controller doesn't support index you might have a page with edit form and url at the top that can't be resolved for a GET request. so if you do Control-L, Enter you get error page, duh!
I think a better default would be for create to map to same url as new, and update same url as edit