This is an *excellent* summary of the tension between being welcoming to new contributors and staving off maintainer burnout. Because if there was a bug / deliberate nefarious thing hidden in that "innocent" 300-line refactoring patch, the maintainer's the one who's gonna be on the hook for it, not the contributor who may be long gone. :\

Whereas, if you take work *off* a maintainer's plate by doing a "thankless" task like improving docs or writing test cases, it's good things all around.

Yep. That is exactly the point of Codes of Conduct, so that **everyone** can just have fun and not worry about being harassed, berated, singled out for some immutable trait, and so on.

If having fun for you necessitates having the freedom to do this to other people, maybe carefully sit down and consider your life choices. ;)

Sometimes you're too immersed in things and forget what assumptions you're making! :)

I actually think the comment by Pseudonymous Powers at https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fdevelopers.slashdot.or... does a *fantastic* job of laying out some of those pitfalls, but to be more explicit, I've now added a new section towards the bottom of the article that itemizes them more explicitly: https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwebchick.hashnode.dev%2F...

Hope that helps, and thanks again the candid feedback!

Disclaimer: I am one of the book authors (Angela - hi! :))

I share your feelings about the extent to which many tech books dwell on these basic concepts. I'm like you. I don't need 3 pages telling me how to extract a tarball. I don't need an entire chapter dedicated to how to use various FTP clients to transfer files. I can get a web application installed, that's not the hard part. I want to hurry up get my hands dirty with the tool and start being productive! This is why we chose a completely different approach while authoring Using Drupal.

The book does include Drupal installation instructions, of course, but it's very brief, and it's in the back (Appendix A). Out of your way unless you need it.

What you're asking for seems to be a task-based guide to using Drupal day-to-day. Writing such a guide for general public use is unfortunately basically impossible. This is because Drupal can literally look like *anything*, depending on what modules are enabled and how much customization was done in the design.

This book instead is a task-based guide to *building sites* with Drupal. If Prudence is a "hands-on" learner, she might find it valuable to work through a few of the earlier chapters. There's definitely jargon like nodes, blocks, taxonomy, cck, and views (sorry, but you really can't be very effective in Drupal without having a little bit of familiarity in these). However, instead of these things being described as abstract concepts, she would instead be doing practical things with them, and see how they fit into the overall process by building out several types of websites from scratch.

Not sure if what I described is quite up your/her alley, but it might be worth taking a browse at the local bookstore (or on Safari Books Online) and see if it'd work for you/her.

The problem was the module quite simply wasn't ready for Drupal 6 at the time our publishing deadline came up, and anything we tried to write about it would be fortune-telling at best, completely and utterly inaccurate at worst. And we (both the authors and O'Reilly) didn't really feel comfortable with that...

In hind-sight, we perhaps should've started a whole new access-control chapter from scratch that didn't use this module (I rather like the case study posed by the author of the review), but it wasn't clear until it was kind of too late that this was going to be a show-stopper. :(

There is a sidebar in Chapter 2 that alludes to access-control modules you can use to protect your content, however. So the book is not *completely* devoid of this information. It just isn't gone into to the same extent as other topics.

Disclaimer: I am one of the book authors (Angela - hi! :))

All of us are contributors to the Drupal handbook. In fact, Addison Berry is the Drupal project's documentation team coordinator. We definitely did NOT want to write a book that simply packaged up the Drupal community's hard work and slapped a $50 price tag on it. :P

The Drupal handbook is a fantastic resource, and is very useful to get you past installation and upgrading hurdles, provides collection of "snippets" for doing common (and not so common) tasks code-wise, is a great reference for Drupal developers, and offers many other things. So to that extent, yes. Chapters 1 (Intro to Drupal) and Appendix A (Installing/Upgrading) could be easily gleaned with the free, readily-available community documentation. If all you want to do is learn how to install Drupal and get a simple vocabulary lesson, do not buy this book! :) Read http://drupal.org/getting-started.

However, something the Drupal handbook is not very good for is a project-based, soup-to-nuts, "Here's how you DO stuff in Drupal." Nor for "here are the modules that are awesome and here are modules that are less awesome, and here's why this one is awesome for certain things but not others." A cohesive guide on this type of information is single-handedly the biggest obstacle people getting started with Drupal face, and is something that really doesn't lend itself well to 500+ documentation contributors scattered across the globe writing piece-meal page-by-page.

And that stuff is the focus of the book.

Disclaimer: I am one of the book authors (Angela - hi! :))

Just to address a couple of points:

There is a change log for the download file, and yet no mention on the page â" or even in the book itself, as far as I can tell â" as to which version in the 6.x release series was used for the book and in the download package.

In Appendix C, there are version numbers of all the modules and themes used in the book, including the version of Drupal (6.4). I've now added a note to the http://usingdrupal.com/source_code as well. :)

Oddly, neither the publisher's site nor the authors' site appears to mention the free downloadable chapter (Chapter 9, "Event Management"), although it is offered in an article posted in the blog section of Do It with Drupal.

*forehead slap* I can't believe we forgot to put that there. I blame the holiday rush. ;) Added a note to the front page of http://usingdrupal.com/.

I'll also speak with our contacts over at O'Reilly about mirroring these items on their "official" infrastructure.

But clearly the book would have been more complete if it contained a chapter explaining how to allow content to be viewable by a limited set of authenticated users.

Yes, the very first chapter written for this book (back on Drupal 5 at the time) was one on Organic Groups which covered the access control aspects in-depth. Unfortunately, due to our book schedule vs. Drupal 6's contributed module release cycle, we had to chop this one. :( I'm hoping that if we end up doing a second edition of the book for Drupal 7, we can add this chapter back in. :)

The flaws of this book are few and minor. There are unreported errata, most of them grammatical â" e.g., "as [the] ability" (page 10) and "modules [that] were" (page 89) â" which are to be expected in the first edition of any technical book.

If you have a chance, please report those! While we fell behind a bit during the holidays, we're hoping to get back caught up on errata review within the next couple of weeks.

Also, a quick correction to the review. In the author list, Jeff Robbins is listed twice, both in the review text and the book info table.

Thanks again!

(Disclaimer: I'm the person in the interview who blabbed on and on about how awesome open source is as a career move. ;))

This actually is far more an argument *for* working in an open source project than against.

When people think about the idea of using open source as a career launching pad, they generally think of two things:

1. It's volunteer, which means you're not being paid. Ha! Sucker.
2. It's IT, which is a dead-end in the U.S. due to shifts in the larger global markets. DANGER DANGER! SWITCH MAJORS NOW!

But that ignores entirely one of the biggest advantages of getting involved in an open source project with a large, thriving community such as Drupal: there are nearly limitless networking opportunities, and those can (and do) lead directly to careers.

Most of my first paid gigs as an independent consultant were from people I helped in the forums who needed some more "hands-on" assistance with their websites. The more people I helped, the more my reputation grew, and the more "human" connections I made. These connections, and the work I was doing out in the larger open source community, led directly to full-time employment with a Drupal shop. And this all happened within a matter of a couple months, mind you, not years.

Open source economies seem to exist independently of the larger global trends, from what I've experienced. It might very well be that if I tried to apply down the street at a local IT place, I'd be turned away. But within the Drupal community, at least, it certainly seems like we can't find people to fill positions fast enough. And with more and more companies depending on technologies like Linux, Subversion, Python, and Drupal, experience working directly on those tools with the very people who built them can only help your employment potential even at the local IT place, no?