Rails Documentation 15

Posted by Bob Silva Wed, 25 Oct 2006 17:08:00 GMT

Improving the Rails documentation has been an ongoing discussion for awhile now. Over $15,000 has been raised by the community to improve them but nothing has come from that yet. I'm going to outline some of my thoughts about it here. These are just random thoughts and do not provide complete solutions. NOTE: This is not a rant against court3nay or the Rails Documentation Project. It's only my opinion on how it could have been handled differently. And for full disclosure, I did not donate any money to the project, I'd rather donate my time.


  • Not to take anything away from court3nay but the timing of the Rails Documentation Project was off for several reasons. First, you should have a game plan before you ask for the money. It's been many months now since everyone donated and nothing has been done with the money. This leads to other problems, mainly it breaks the trust of the community. The next time something worthy comes along, likely contributors will be a little more cautious before they hit that donate button.
  • With everyone waiting to see what comes from the Rails Documentation Project, the number of patches for documentation to core has dropped.
  • Has anyone answered exactly what is wrong with the existing documentation? I'll outline a few things I see:
    • Easily gets out of date, need to place documentation on the same level as tests when accepting or rejecting patches.
    • The API docs on rubyonrails.org need a version selector. People using older versions of Rails (for whatever reason), should be able to access the appropriate docs for their version. This problem will be even more evident once Rails starts shipping with OS X and other Linux distros. The public website should support this, not a message explaining how to generate local documentation for your Rails version.
    • No style guide. You have to refer to existing documentation to determine the style to use. Could be improved with a style guide.
    • Are they docs or an API reference? Currently, its a combination of both and both are lacking. I think the examples need to be expanded (and possibly even follow a common theme, more on this later) and the API's more complete. When rewriting the docs for some of the ActionView Helpers, I found a quite a few options that weren't documented.
    • Core should have a dedicated person(s) to handle documentation issues. Making sure patches are properly documented (or willing to do it themselves) and reviewing/committing documentation patches. This person should also create the style guide or written standard for documentation.
  • I see two different audiences for documentation. The new users who really need a tutorial like approach and the more experienced who really need an accurate API reference. I'm not sure the inline documentation in Rails can serve both audiences, but it can come closer than it does currently. I think it would be great if Rails shipped with a default example application that all the documentation examples pulled from and referenced back to. This maintains a common theme throughout and acts as an excellent teaching tool.
  • So what should be done with the $15,000? Pay an author (a good one preferably) to write an open source book on Rails. This book should be completed by the author and then maintained by the community to stay current with Rails development. This is the best way I can see to spend the money.
Update: Better explanation of the "open source book" idea.
By open source book, I mean a separately maintained API reference 
maintained in book form, organized into logical chapters and topics
with full API coverage and plenty of examples. Take the API docs 
for AR associations. ActiveRecord and its associations are documented
across many files making it difficult to provide full and complete
examples of its many use cases inline. Having a dedicated chapter to
cover each association with full example coverage and feedback 
capability would be better than the inline docs. The inline docs 
should provide full API coverage, but leave the examples out. This
other "officially" maintained documentation would contain the 
example coverage and many use cases as well as user feedback.

Yes this is extra work, but I think you could find plenty of 
volunteers, including myself, to make up an official rails-doc 
team with full commit rights to the documentation in rails trunk.
Comments

Leave a response

  1. Sebastian about 2 hours later:
    Thanks. I'm very glad you brought this up and i couldn't agree with you more. In fact, during RubyConf, i talked to several people who brought up the Trust issue ("Whatever happened to the 20K?"). I'm sure that there's nothing sinister going on here, but collecting that much money and not providing some clear open outline (or at least the occasional progress update) is a risky proposition and invites all sorts of misgivings. There are plenty of valid ideas posted to the Caboose Wiki. The organizers need to step forward and get this thing going now!
  2. Sebastian about 2 hours later:
    btw, Bob, since you seem to be one of the most active documentation contributer to the Core API right now and the documentation project apparently seems to lack leadership, i'd like to nominate you to be in charge of implementation. Do you mind?
  3. Bob Silva about 2 hours later:
    Actually, I think court3nay will do a fine job. He's been responsible with the money and I think thats the core problem. He's being extremely cautious on how he handles it. One one side, this is a good thing, on the other, it prevents forward progress. He has a difficult task ahead of him. Unfortunately, he got himself in a bind as he can't please everyone. Some will want tutorial information, others will want cleaner API docs. Thats partly why I concluded an open source book which covers both in depth is a good solution. You don't get into the whole bounty stuff which will start all kinds of wars on who deserved what etc...

    They are currently working a cool application to make submitting documentation updates much easier and enabling participation from the community, but this doesn't solve the money issue which is what everyone wants to know more about.
  4. PJ Hyett about 2 hours later:
    I agree with all of your points except for your conclusion. I paid to have the documentation improved, not so can newbies have an easier time understanding the framework. There are new books being released every six months trying to capitalize on ROR's popularity. If you look at the people that donated, the vast majority are rails professionals that are constantly digging through the source to find answers.
  5. Bob Silva about 2 hours later:
    On a different note, if core asked me to head up the documentation management like I suggested (which I doubt at this point), I would be more than happy to back up my words with actions. In the meantime, I'll keep working on my own documentation patches and doing my part to contribute back to a project I get so much out of.
  6. Alex about 2 hours later:
    Whatever form the final project takes, I personally think it's important that any documentation be released under a free documentation license. GFDL or CC-BY-SA or similar. This is documentation paid for by the community, to be supported by the community. It should be released in a way to allow it to be used effectively. The project seems to be heading towards making infrastructure to make updating the documentation easier. I think that's where Conor Hunt was heading with rannotate (though seems to have disappeared off the face of the planet). This project is really promising. If this or something like it could be completed, that would really help the community. I'm excited to see what appears from the documentation project.
  7. Joe Ruby about 2 hours later:
    Totally disagree with the last point (write a book) -- keep the docs in one place.
  8. Bob Silva about 2 hours later:
    PJ, I can see your point as well. I just think doing that is going to be hell and potentially tear up the community with spats over who gets paid what and how much. And what happens when more than one person submits docs for the same thing? How do you decide who gets paid? No matter which you choose, someone will be pissed off. Processes can be put in place to prevent this specific issue, but other issues will arise as well such as, quality control. Should you pay for poor documentation and how do you judge that? Again, just a difficult situation. I wish the donations were never asked for and just the participation to improve the docs was organized and implemented. But, short of returning the money or redirecting to another worthy project to benefit Rails, I don't see any easy answers of how to make use of it.
  9. Bob Silva about 2 hours later:
    Joe Ruby, I didn't expand on the open source book stuff much, but one of the things I really see missing is centralized community feedback. One of the successful features of the PHP docs is the comment mechanism. A properly outlined book/reference manual with feedback ability would be as if not more useful than the docs in their current form. Where is the trade off on how much you cover in the docs versus the size the files become and how difficult it becomes to find the source code in the expanded docs? Feedback from core would be nice on this point.
  10. Sebastian about 3 hours later:
    i have no doubt court3nay is responsible with the money. But i'd honestly be worried about perception at this point. We have a great community and distrust leads to all sorts of nasty things, as you mentioned. i think everybody who donated was aware that this is going towards an unspecified solution to be determined by the organizers. That means that we put our trust in court3nay & co. to do the right thing with it -- and for good reason. While i personally rather see the funds applied to improving the API directly, i realize it's impossible to accommodate everybody's opinion and i'd be fine with anything the organizers decide to do. Listing to opinions on how the money should be spent is all fine and good, but in the end it will not lead to any conclusions and we'll be stuck in limbo indefinitely. So i'd say to court3nay or whoever will lead this effort: spend it on whatever you personally feel serves the community best, just don't let another 3 months go by. We need better documentation now.
  11. Bob Silva about 3 hours later:
    By open source book, I mean a separately maintained API reference maintained in book form, organized into logical chapters and topics with full API coverage and plenty of examples. Take the API docs for AR associations. ActiveRecord and its associations are documented across many files making it difficult to provide full and complete examples of its many use cases inline. Having a dedicated chapter to cover each association with full example coverage and feedback capability would be better than the inline docs. The inline docs should provide full API coverage, but leave the examples out. This other "officially" maintained documentation would contain the example coverage and many use cases as well as user feedback. Yes this is extra work, but I think you could find plenty of volunteers to make up an official rails-doc team will full commit rights to the documentation in rails trunk.
  12. Daniel 6 days later:
    Bob, perhaps you would consider contributing to Jamie van Dykes project at rails.devjavu.com ?
  13. smerickson 7 days later:
    As someone who donated to the project, thanks for bringing this up. Has anyone seen the latest "beta" version of the Django documentation book? It looks pretty slick so far. http://www.djangobook.com/en/beta/
  14. Jamie van Dyke 3 months later:
    Thanks for the mention, Daniel. The problem I've found with doing an open source book is funding and time, every minute I spend on the book (although I love doing it and helping out the community is highly satisfying) I don't earn anything. My plan has changed slightly since I started and hopefully it will be more useful for everyone, but I'm going to re-write the latex (the most up to date pieces) into markdown and then set up a site that will have the book in html format (mephisto backend). This would allow me to use the markdown to latex plugin for mephisto, and then I can spit out a pdf periodically that you can download...as well as pass it over to lulu.com to get a print version. All I lack at the moment, is time, but that will change soon as I get some side projects out of the way.
  15. Jamie van Dyke 3 months later:
    On a side note, I really like the layout/plan of the django book, and because 'Getting Started with Rails' is in such early stages, I'd be willing to change the plan to be similar.
Comments