> > I'm thinking of creating a microPledge <http://micropledge.com/> project > to raise money to create the docs like they raised $17,000 for Ruby on > Rails <http://www.pledgie.com/campaigns/34> by merely accepting donations > (though I don't imagine that we'll make it that high because Ruby has a much > bigger following). I know that using a new microPledge feature you can now > *"pledge now, and pay later" *to get an indication of the level support > "out there", but I'd like to open this for discussion here before I even > start the project. > > As for who would do the documentation, we at microPledge would be willing > to do it as a job, and you can assess the quality of our > docs<http://micropledge.com/help>. > But we'd be happy if others quoted the job, too. After all, the object is > to make the docs, not the money. >
Berwyn, I'm glad to hear some more enthusiasm on the topic. I wonder, though, if web.py is ready for that level of commitment. A little bit of digging shows that there were several books<http://www.amazon.com/s/ref=nb_ss_gw/102-0500092-4436954?initialSearch=1&url=search-alias%253Daps&field-keywords=ruby+on+rails&Go.x=0&Go.y=0&Go=Go>written for RoR by the time the pledgie fundraising occurred. Because I can't backtrack at all at rubyonrails.com, I can only assume that at the point these books were written, rails was at least at 1.0 and production worthy out of the box. It is my strong opinion that with Django, Turbogears, etc. out there we're going to need more widespread support to justify a financial input at this time. I truly believe the organic approach is best for now. In other words, we need a reliable wiki and related discussion. Optimally they would coexist on the same website even though we already have conversations on this list. Aaron has mentioned this from the beginning but we've yet to realize any such solution. That said, and part of the reason I've withheld responding thus far, I'm going to begin a hosted solution to this problem. I'll probably post back by Sunday with my progress. I may or may not make use of Seddit's code considering it uses Prototype and Postgre and I've yet to see it in action. ** Sorry for postponing this long enough for you to become disheartened. That's the direct effect of a low activity project. Don't lose faith. > > - What is the average user of web.py like? Does she enjoy reading > source code? Can he program? > - How does one measure a great documentation? What goals it should > promote? > - Is less more in this particular case? > > Tommi, I don't think less is ever more when it comes to good documentation. When coding, absolutely. When looking for help, not so much. Great documentation = python.org. I believe the current one-pager documentation is actually quite useful but it could always grow and expand and that's where it's lacking -- depth. Where do we outline design idioms, the concept of REST, an HTTP roundup (headers, seeother, redirect) etc. This is where I have to be honest; I really just can not be arsed to log in. > I > know it sounds stupid, but this feeling of "let's fix that" always comes > in a whim and whenever I have to think hard to remember my password I > already feel like it's been too much trouble to begin with. I wonder if > maybe it is possible to allow anonymous edits to the documentation, > maybe with a captcha? > b^4 or should I say b*4 :), What you represent is the reality of micro contributions to an open source (free) project. The lower we can set the barrier to entry and the better we can make small contributions stick to each other, the stronger the overall documentation will be. I'm going to be using OpenID for the community pages I'll be building. Anonymous is just being too lazy. Maybe we should make some screencasts. Those seem to be popular with > these web frameworks. > Adam, But how would we make an anti-screencast for our anti-framework? I've never been too successful at making one of these. All the pretty ones seem to come from Mac software. I think screencasts are good for newcomers. Web.py is so simple that > there is no need for screencasts. > It is almost impossible to write hello world in a single file in any > other web framework, so they need screencasts. > > I think making good documentation with nice examples will be good > enough. > Anand, Screencasts are good for marketing and definitely good for newcomers who want a quick drilldown of the standard featureset. Good documentation should easily be 99% of the focus. Aaron, Will Jottit be using web.py? Until Sunday, Angelo -- Angelo Gladding [EMAIL PROTECTED] http://angelogladding.com (626) 755 - 1417 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web.py" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/webpy?hl=en -~----------~----~----~----~------~----~------~--~---
