I'm the writer of the blog entry. I agree: i "didn't give the community a fair shake." The blog post, (which I wrote in the bus, and just need to finish some things on before I post,) basically says: "You need community engagement, at this point, to do TurboGears. My big mistake was thinking that I could just sit down for 13 conseutive hours, and hammer it out. In fact, at this stage of growth, you will need to have some question-and-response time with the TurboGears community. That means that, instead of consecutive hours, it may be more valuable to break sessions into 2 hour blocks, spread over some days."
So, you're quite right: I didn't give the community a fair shake. I had come in with the expectation that I would be able to rely on documentation alone, and just figure my way through things. That's not the right expectation to have, and that's why I felt burned. But, since having those questions answered, I've been having a great time. This next post is *positive,* and I'll leave a note here after I've found the time to post it. (I'm at work right now.) I would like to write a tutorial/travel-log after I'm done, that tells about how I wrote my software, how I think beginners should approach learning TurboGears. It'll roughly go like so: * part 1: downloading, installing, IRC, mailing list, expectations * part 2: actually writing the code * part 3: disaster strikes, you need some info: IRC, mailing list * part 4: finishing the app, making it look nice It'll explain what I thought were rough points, and what things worked well- incredibly well, even. I'd be happy to pass it by you all, first, to make sure that it's not inaccurate. Again: I think my primary problem was thinking that I could just sit down with the documentation, and make an app in 13 hours. Since TurboGears is understandably not at that stage yet, I see now that it's better to work a couple hours every day, and ask questions about what I'm having difficulty with. That gives this hard-working community time to answer. And you do: My expectations have been exceeded, in that respect. I'm amazed at how responsive you all are! > Yes, that a good point. The problem is that the user still needs to > figure out if the solution to there problem is in CP, turbogears or > some other module. > Unified docs would solve that problem. Elvelend, yes: This was a problem I ran into many times. I was unsure about whether something is in CP, or in TG. They're both big, and they seem to sort of blend in with one another. So, it was very hard to know where I should be looking. Perhaps something that says, "For these kinds of problems, check the CherryPy documentation. For these kinds of problems, see the TG documentation." Of course, this assumes relatively complete TG documentation. I'd offer to help, but I don't think I can be much assistance; The time it would take you to communicate to me what needs to be in the documentation could well exceed the time it takes you to write the documentation yourself-- a classic problem.
