I chose Blogofile for this task because, while the project is still young, it is flexible enough to easily handle both "normal" pages and blog content and it is written in Python (which I've been learning for another project). I'm running a slightly patched version of Blogofile and the blogofile_blog plugin, and still fighting a bit with teaser generation.

Overall, it's been a good experience. The community is helpful, turning a simple html+css mockup into blogofile templates was easy (even for a non-themer like me), and there's something incredibly freeing about knowing that the site itself won't ever need a security update. All the code execution happens on my machine, then I push the resulting HTML and CSS files to my server. The only executable code in this whole blog is the snippet of js that integrates Disqus comments with my blog posts.

We lack a clear and inviting path from discovering Drupal and learning how to use it to becoming an active and productive contributor. As a result, our most active developers are plagued by the support demands of intermediate users who have outgrown the Drupal.org forums and don't know where to go. This effect is compounded both by our failure to attract and assimilate new highly qualified support-givers, and the myriad bad behaviors that newbies are learning in "newbie ghettos" such as the forums -- behaviors that make it difficult-to-impossible to adequately support them and bring them into the wider Drupal community.

The Solution

• Phase out the Drupal.org forums in favor of a more straightforward Q&A format resource.
• Treat posts that resource as not just the answering of this question here and now, but building a useful searchable reference into the future. Be brutal in eliminating off-topic chatter and duplication (but as kind as possible in explaining why a question was closed) ala StackExchange.
• Provide easy gateways from that resource to more active participation in the Drupal community: IRC, issue queues, doc team, translation teams, GDO, etc.
• Improve the consistency of IRC and Q&A moderation by setting up a venue for moderator docs and discussion.

Rationale

Why is this important?

Most users' first community interaction will be in the form of seeking support. That support-seeking experience will form the basis for how they interact with the Drupal community in the future.

If we can sufficiently improve our primary support venue, we can expect:

• Fewer people trying to get support in inappropriate ways, such as by clogging the issue queues or demanding the personal attention of our most active devs every time they have a problem.
• More new Drupal consumers to eventually evolve into active Drupal contributors.
• Fewer behavior problems in IRC and the issue queues.
• Users utilizing a search engine to solve their Drupal problems to get more useful results more often.
• The Drupal learning curve to seem a little less onerous to new Drupallers.
• Giving support on Drupal.org to suck a lot less for the support-givers.

What is wrong with what we have now?

The most active, experienced Drupallers are not active in the Drupal.org forums due to:

• Poor signal:noise ratio
• Too much overhead (read: time suck) in following discussion on the webforums
• A format that does not lend itself to passive participation (i.e. following well enough, with a minimum expenditure of energy, that one would know if a question one actually wants to answer has come up)
• The support mailing list suffers from the above, plus:
• Poor searchability
• Publication of participants' email addresses

• Intermediate and advanced questions in the venues above get too few helpful responses. There is no clear path to the "next level" of community participation and support. Thus, the post-newbie spillover tends to land in the issue queues, developers' inboxes, and other places where it interferes with active development.

• Though the forums especially, and to a lesser degree the support mailing list, are sometimes praised for their low barrier of entry due to the lack of behavior corrections present on IRC and the issue queues, this comes at an enormous cost. These newbies visit our supposedly newbie-friendly support venues, learn behaviors (reinforced in the forums) that are exactly what keep the experienced folks out, then are shocked to be treated with less than total acceptance in more active venues. After all, they learned the behaviors we taught them. Why shouldn't they fit in? They're doing it "right".

• Of course, some newbies never make it that far. Many get caught in the forum cul-de-sac and never find their way to the vibrant, geeky community that really powers Drupal.

What could we be doing better?

A new support venue should:

• Make it easy for participants to understand the venue's expectations, and how to best get support.

• Encourage behaviors and approaches (RTFM, search, ask smart questions) that will serve one well throughout one's entire Drupal career, not just among other newbies.

• Be thoroughly indexed and easy to search. Ideally, this should be part of the main drupal.org search so that the support-seeker has as few places to search as possible.

• Reduce duplication as much as possible so that answers are clearer and easier to find, and volunteers aren't needlessly burnt out by having to explain how to log in to a Drupal site in maintenance mode 4,000 times.

• Have extremely low participation overhead (that is, how much time you have to invest clicking around in order to ask/answer questions).

• Have an extremely good signal:noise ratio.

• Provide easy, obvious bridges to other parts of the Drupal community.

• Be a great example of the culture surrounding Drupal, rather than an isolated ghetto not particularly representative of or connected with our community.

• Address support questions across a broad range of skill levels and subspecialties within the Drupal ecosystem.

• Successfully help people with their problems and questions regarding using, theming, and developing for Drupal.

Conclusions

• In order to successfully address questions in all areas and at all skill levels, the support venue must be attractive to Drupallers with all levels of experience.

• In order to be of the greatest utility to both individual Drupallers and the Drupal community as a whole, a community support venue should go beyond just answering the question at hand: it should act as a reference for future support-seekers to find, and nudge people toward the behaviors and attitudes that will make their Drupal experience successful in the long run.

• The Q&A format would be a huge improvement over current venues for Drupal support, specificially because it:

• Has a good track record. Drupal questions are frequently asked and answered on StackOverflow, and there are nearly 200 people committed on a proposal to add a drupal sub-site to Stack Exchange. (No, this site isn't going to be created, for reasons beyond the scope of this post.)

• Has low participation overhead, while still being very searchable.
• Helps teach newcomers the mindset that this venue is a place to get things done, rather than a place to visit (as forums tend to lead them to believe).
• Puts moderators in the position of being able to close questions for not being real questions, for being duplicates, etc. without the lashback of confused forum users (who generally have expectations based on experience with discussion forums, not support venues).
• Is an easier format from which to bridge users to proper IRC and especially issue queue behavior: the Q&A format is, in a way, an issue queue designed solely around support issues rather than coding, docs, etc.
• NO support venue will serve the purposes described above without consistent, appropriate moderation. Consistency would be greatly increased if moderation procedures were documented, and if moderators had a place to privately sanity-check borderline situations before acting. Additionally, moderation standards should be set with the focus on encouraging the right attitudes and behaviors all the time, rather than letting things go until these poor attitudes become expectations and these poor behaviors become habits.

The Basics

Have Patience

Rome wasn't built in a day, nor will your Drupal-fu be. Prepare for trial and error; it's part of life in the open source world.

Speak Fluent English

While Drupal itself has been translated for use in many languages, the lingua franca for development is English. English is spoken in the issue queues, on the [contributor IRC channel)(irc://irc.freenode.net/drupal-contribute), and at DrupalCons. If you don't speak, read, and write English fluently, you will miss out on most of what is going on, and you will never reach a high level of Drupal developer-fu.

Use Drupal

You might think this goes without saying, but we do get wanna-be devs who don't really grok what Drupal is or how to install it. It's not necessary to be an expert Drupal admin before your first issue queue visit, but you should have installed drupal at least once and be be using it regularly.

Understand Your Computer

We're accustomed to walking new contributors through using git, rolling patches, etc. We'd rather not have to teach you how to use:

• Your OS (desktop and server)
• A web browser
• email
• IRC
• A syntax-highlighting editor with *nix-style line-endings
• SCP / FTP
• SSH
• Your web server
• basic set-up
• configure domains
• view logs
• Your database server
• basic set-up
• create databases
• create users
• dump and restore databases
• empty a database
• manage permissions
• A search engine
• A syntax-highlighting pastebin
• An issue queue
• api.drupal.org

Understand Markup

A basic understanding of HTML and CSS is needed, nothing extreme.

Understand Programming

It's not necessary to come in knowing PHP, but if you don't, you should have enough programming knowledge to pick up a new language quickly. Some of our devs also know Javascript (especially jquery), some don't; its usefulness depends on what kind of Drupal work you like to do.

Finally, and most importantly,

Know How To Be Worth Helping

• Ask each question in the right venue.
• Pay it forward by supporting others, doing issue queue triage, testing patches, contributing code, and documenting things.
• Be patient.
• Observe good IRC/forum/ML/issue queue courtesy.
• Have thick skin; take criticism well.
• Ask Smart Questions
• Don't be a Support Leech.
• Be willing to try things out.
• Embrace Best Idea First

Bonus Round

You don't really need to know this stuff when you first show up, but any of it that you do know will be helpful in some way:

• HTML5
• CSS3
• Important Drupal concepts:
• node
• field
• taxonomy
• content type
• view
• panel
• user
• role
• permission
• module
• theme
• Common Drupal modules:
• Views
• Panels
• CCK
• Sitedoc
• Pathauto
• Admin Menu
• imagecache and image
• wysiwyg
• Contemplate (and why it should never, ever be used for anything)
• Drush
• git
• how to roll or apply a patch
• general troubleshooting skills
• Drupal coding standards
• Hacker culture

Resources

Drupal.org docs api.drupal.org Drupal.org Forums Drupal IRC Channels groups.drupal.org Drupal Planet Drupal.org Mailing Lists The Cathedral and the Bazaar The Jargon File Using Drupal Pro Drupal Development New Drupal Developer Toolkits W3C

Then I had to explain to my housemate who Donald Knuth is... ...and tell a fellow Drupalista what the Jargon File is... ...and define "grok" for a colleague from the XMPP community... ...and stifle a laugh while my 7-year-old tried to describe the wumpus to someone who should know better... ...after which I read Eric Raymond's recent post on the social utility of hacker humor.

Then I grokked.

In the projects that have been around for a dozen or more years, or those run by hackers who have been, there is a common culture and identity shared by all: we're hackers. Whatever else we are -- country bumpkins, urbanites, gay, straight, bi, male, female, transgender, a particular religion or nationality, old or young, single or married, parent or not, rich or poor -- we are hackers, and all we need to know to work together is that we share that cultural bond of hackerdom.

In the younger open source projects, people are expected to recognize that we all come from different cultures. Not only are we to recognize it, but we are supposed to keep track of these cultural differences and be sensitive to them, which of course means being constantly aware of them. It's all about differences, and "what do people think because I'm a $whatever?"

Meanwhile, I've worked with old-school hackers who were evangelical Christians -- the kind that are as certain of the corruptive nature and future damnation of pagans as they are of the sun rising -- and never had an issue. To those of us immersed in hacker culture, a hacker is a hacker; hackerdom provides enough common ground for us to work together and enjoy it. Without that, people end up bailing out of development discussion because of cultural claptrap.

Successful open source draws on talented people regardless of their religions, sexual identities and preferences, nationalities, disabilities, ages, and other differences. A couple of decades have shown that an extremely successful way to do that is to have -- regardless of whatever else we are part of -- a common hacker culture.

So for the sake of harmony and productivity, PLEASE:

• Grok some Heinlein.
• Hunt a Wumpus or two.
• Remember to bring your towel.
• If you have trouble remembering your towel, consider investing in sapient pearwood luggage.
• Read The Art of Computer Programming (yes, the entire series).
• Read RFC 1149
• Play Adventure and/or Nethack.
• Try to "man woman"
• Keep in mind that Tux is not randy (that would be impolitic!) he's full of fish.
• And see what Alice and Bob are up to now. ...because failure to look up any of the above via the Jargon File or a search engine kills kittens.

Also, to those of you already indoctrinated in the ways of the hacker, help the newbies around you get some culture. Trust me, it makes us all less isolated from one another, less at odds with one another, and more able to focus on the code.

This time I'm writing about a brilliant article I came across on twitter (thanks @crell).

The tech industry isn't closed to women, or girls for that matter. I was welcomed from the first day I wandered into the open source world, a self-conscious twelve-year-old farm girl with no feel for tech culture. The problem is that most 12yo girls don't feel like spending their nights in front of a computer screen and line after line of code.

Jolie's article talks about what should be obvious, but no one talks about -- you can't raise a little girl with nail polish and baby dolls then expect her to magically become obsessed with tech at university. I'm sure my chemical sensitivities (which caused extreme illness when I was exposed to clothing stores, new clothes, make-up, etc) had something to do with my becoming a geek.

Will all girls raised in a more varied existence go into STEM fields? Of course not. But those with the talent will discover it early enough to have it inform their goals and personalities.

Please read the article I linked above -- it's really worth the read. I'm going to stop in the office of my son's elementary school this afternoon and offer to resurrect the junior high school computer club I used to run in an elementary version, so that more kids (boys and girls alike) can get into tech. :)

Not long after I diverted from my former career path to pursue life as a Drupal consultant, I received the following advice from a trusted friend: "Every good independent web developer has a project or two that is their own, besides what they do for their clients." It's turned out that he is right. Good speculative work gives me a chance to build a product I'm really happy with, free of portfolio-harming client compromises and NDAs. It also provides me with important experience following a project through its entire life cycle, so that I can jump into my consulting projects and easily answer "where do we go from here?" no matter what state the site is in. Finally, good speculative work gives me something potentially profitable to do when my consulting business slows down. Instead of having tons of work or no work, I have tons of paying work and a little speculative work to fill in the gaps, which is better than no work!

Despite the potential benefits of developing a few well-chosen speculative projects here and there, there will always be far more demand for speculative development than there are developers available to fill it. I, like every other developer who considers speculative work, must somehow separate the wheat from the chaff. There isn't a formula for a successful project (if there were, we'd all use it and be rich) but here are some key points to consider before taking (or offering) a speculative web development project:

Can I (as the developer) afford to take on this project? If it becomes worth $0, $100k, or $10m how will I feel about my share?

A typical speculative offer from an inexperienced businessperson looks something like this: Alice brings Bob idea and, if he's very lucky, some management or sales skill (none of which matters until there is a product to sell or someone to manage). Bob does all of the development and theming work, provides server resources and possibly graphics. Alice offers Dave 2%-10% interest in the venture. Any developer would have to be insane to accept such a proposal. A typical web start-up with no physical product and a moderate amount of custom development needed will cost $15-$30k in funds, labor, or some combination thereof to get off the ground. Many need more than that. Alice's offer has Bob putting in 100% of that investment (mostly in the form of his labor) for only 2-10% of the profits should the business take off. Meanwhile, Alice risks nothing (having an idea didn't cost her anything) and walks away having either broken even ( 0 investment, nothing to lose) or with 90+% of the profits!

There are some developers who will work with someone coming in with just an idea. I won't, even if I truly believe he/she has the next billion-dollar idea. I don't want to work with someone who has nothing to lose. Having nothing to lose changes the way one approaches a business venture. As the old saying goes, we should all have a little skin in the game. That said, most people with an idea don't want to give 50+% of the venture to their web developer, and few web developers can invest thousands of dollars in development time and other resources in a project from which they will at worst take a total loss, and at best receive only a tiny share of any profits that might come along some day.

What I have found works for me is to take a smaller share of a venture in exchange for a discount on any work performed on the project. This lowers my risk (I can still pay my bills while we get the site running), gets the other participant to invest something (the development money), makes start-up far more affordable for the "idea person", and has slightly better odds than a lottery ticket of getting me a pleasant bit of extra money down the road.

Is this person/group someone I want to work with?

You'll note that I haven't even gotten to evaluating the idea yet. This is on purpose. The idea matters, but it's only one part of the risk/reward equation. I take on very little speculative work -- on average less than one project per year. I'm not going to do work with no guarantee on what the return might be and deal with a giant pain in the rear doing it. I only take spec. work from people I've worked with before. I don't want to partner with someone and then find out he/she is a total crackpot, and I'm stuck with him/her! Whomever I am working with must above all be someone I know I enjoy working with. Who a developer will enjoy working with varies, but some things are (mostly) universally true: we want to work with people who value our work and expertise, and whose skills and expertise compliment our own. We don't want to have to argue with you for hours to talk you out of a flash splash screen or auto-playing audio on the web site. Remember, one of the primary benefits to speculative work (from a developer's perspective) is the chance to build a great product -- the best product we possibly can. In theory, this is exactly why the "idea person" brings in a skilled developer to begin with.

Is the "big idea" here viable?

There's no formula here (or if there is, I don't know it) -- for me, evaluating the "big idea" is tag-team between intellect and instinct. This is not to say that I have amazing business instincts -- if I did, I would have a much more expensive car and a much bigger yard -- but that I can usually tell if something's really hinky. The intellect part of the equation means asking questions like "who is the target audience?" "what is the product?" "how is this different/better than the competition?" "how does this generate income?" "what kind of overhead is involved?" "is there anything out there on which we can gauge the potential success of this project?" and "how will our target audience find out we exist?". Then I think of some other questions and ask them. Again, I must emphasize that I am not a business genius. I do, however, have years of experience watching web sites succeed and fail. If something is way outside my area of expertise, I probably know someone with the knowledge I need to guess if an idea will be worth my time. 90% of the time, when someone offers me speculative work, they either want to identically clone some existing, successful site, or they have a vague idea of making a web site about $something, but have not given any thought to how it will actually generate revenue.

Can my potential partner and I come together on a strategy?

A good idea, without execution, is just a daydream. I don't do handshake deals on speculative projects -- it's too easy to get cheated (or just recall the deal differently) two years down the road when real money starts coming in. Stratagem #1 is making sure that who is putting in what, who is doing what, and who is getting what out, are all down on paper. We also need things like a working budget, a strategy for promoting the site, etc. Hash out the basics early on, when the cost for walking away is minimal to none. Make sure everyone has realistic expectations.

What happens if it all goes south?

If I can't handle a project failing, I shouldn't be speculating on it. Of the four speculative projects I've taken on in the last few years, one was a total loss, one made me slightly more than I'd have made billing normally for the time spent on it, and two have futures yet to be seen. The one that was a total loss financially, ironically, is the one from which I've taken the biggest gain. I was very new to the business world, essentially fresh off the farm where I grew up, and what limited experience I had was working for the military and a military contractor -- which are a world all their own. Working on a venture capitalist (word I didn't know before this project) funded project with a business-savvy partner was very educational!

Commentary I heard today from parents I know -- really good parents -- was all along the lines of "I just want to hug my kids and never let them go" and "it makes me scared to let my children go anywhere". It's an understandable impulse -- as the parent of a kidnapped (and safely recovered) child, I certainly experienced the instinct to keep my child close at hand. Years later, I have an amazing and increasingly independent seven-year-old.

He's got a year of formal martial arts training, and a lifetime of instruction on basic tactics. At seven years old, and as he grows up, Little Fish deserves both a little freedom, and the skills to deal with the unexpected. Even if he never needs to defend himself, he's still learning discipline, gaining confidence, making friends, building character, and so much more.

No matter how we feel about it, we can't keep our kids on a short leash forever -- or at least we shouldn't. Kids need independence in order to grow into confident, capable adults. Our job as parents isn't just to protect our children: we must also teach our children to protect themselves. I cannot say enough about the benefits of martial arts, or of training with your child as I do with Little Fish, but if you can't be convinced visit the dojo twice a week, you can at least teach your child some basic tactics for staying safe:

• If you are being chased, do not hide. Remember, if no one can see you, no one can see if a BG (Bad Guy) steals you or hurts you, either. Instead, find a crowded place and ask someone there to call the police.
• Trust your instincts. If someone, even someone you love and trust, says or does something that gives you a bad feeling in the pit of your stomach, talk to a grown-up you trust as soon as you can. Parents, your child MUST learn from experience that you will believe them when they tell you something is wrong, or they simply won't tell you. This means that if they got in trouble for "no reason" or a kid at school pushed them, or whatever, no matter how small you MUST NOT blow them off. Look into it. Assume your child is telling you the truth until you have proof to the contrary. Most kidnappings and child molestations aren't by strangers, they are by someone the child knows and trusts, someone the parents may trust.
• Keep a safe distance from strangers, even friendly ones. It's okay to hug or lean on or stand close to your friends, but if you do not know someone well, never let them inside your personal space. It is impossible to tell nice strangers from BGs -- even grown-ups can't do it -- so you should always be at least one big grown-up step away from any stranger. This gives you time to run if they try to grab you or strike you, and they can't do it without attracting attention.
• Practice a commanding voice. If you say "no" or "stop" to someone, especially a grown-up someone, you must be able to show with your sound and your body language that you mean it. If you look at your toes and squeek out a soft "no", a BG knows they can pressure or scare you into doing what they want. If you stand tall, look someone in the eye, and use a commanding voice, they know you are not an easy victim. When we practice this at the dojo, the difference between how fast we stop for an unsure voice and how we stop for a commanding voice and body language is incredible -- even coming from a very slight, barely three-foot-high white belt.
• Practice for emergency situations. Nothing is as scary once you are ready for it. Practice what to do in case of a fire, a severe storm, an injury, in case a stranger asks you to leave with him/her, or anything else you can think of. If an emergency happens, and you already know what to do, it's that much easier to do it.

Anatomy

There are two subspecies of support leech, however hybrids are not uncommon:

• The clueless support leech is uninitiated in the ways of open source support, and possibly in IRC, mailing list, or forum courtesy in general. With proper education, some clueless support leeches can be persuaded to morph into community members -- a completely different, non-parasitic, species.
• The entitled support leech is hyper-focused on its own needs, and does not care to make the support process go smoothly for support-givers or others in need of support. This subspecies is the more persistent parasite (when compared with the clueless subspecies), as even when educated on "helping us help you" or even general courtesy, it will barrel forward, certain that only its own needs could possibly matter.

Habits

The examples below center around support leech behavior in IRC support channels, however the support leech's habits are consistent across support venues, including mailing lists, web forums, IRC, MUC, and user group interactions. Unless noted, habits below are common among both subspecies of support leech, as well as most hybrids. The easiest way to tell the difference between clueless and entitled support leeches is to note their general level of politeness, and how they respond to correction.

• Support leeches often require a show of support or expertise before asking a specific technical question. "Can anyone help me?", "Is anyone there?", "Does anyone use...?", or "Who here knows a lot about...?" are common forms for this demand, but there are others. The clueless support leech often does this because it thinks such behavior is polite, or because it feels some trepidation about asking its "real" question. The entitled support leech, in contrast, is motivated by the feeling that its time is so incredibly valuable that asking a detailed question without a promise of help is beneath it. Community members, the support leeches' non-parasitic counterparts, enter the IRC channel and immediately ask a detailed and complete technical question, so that they may be helped in the most efficient fashion possible.

A typical IRC channel has 2-4 community members trying to support 5-15 users at once, probably while trying to get their own issues handled. If for each of those 5-15 users we have to go through a round of greeting them, a round of telling them it's okay to ask a question, and a round of explaining that we don't know whether we can help until we know what we're being asked to help with, we're wasting five or more minutes per person, that could be dedicated to support -- 4 volunteers trying to help 15 people over the course of an hour have 240 minutes to go around. That's 16 minutes per person if we get straight to the support issue, and 11 minutes per person if we don't.

• Support leeches ask questions as vaguely as possible, so that support-givers must interrogate them in the process of troubleshooting an issue. The clueless support leech has no idea what information is relevant, and so may go the extra mile by including lots of irrelevant information (like what they were eating at the time), while not giving enough information about the problem to solve it.

Asking complete and useful questions is something of an art form, one that is learned with experience (by those not so entitled as to refuse to learn). However, the more complete the question, the better and more forthcoming a helpful answer will be. It is important to include at least what operating system the problem system is running, what version of the software in question is being run, versions of dependencies (if applicable), recent changes to the system (this stopped working since I...), and the precise symptoms being experienced ("it broke" or it won't work" are not precise.

• Support leeches generally will not consult existing documentation before asking for help. Clueless support leeches often lack an understanding of how to find relevant documentation. Entitled support leeches generally feel that they will dispose of their issue faster with a human support-giver walking them through it, and simply don't care that this takes time away from helping other support-seekers. When confronted with the admonishment to RTFM¹, support leeches often fail to follow the advice.

Community members create documentation so that information will be easy to find and use, and to prevent duplication of effort. Community members who encounter an issue with a particular technology will check the documentation for that technology to see if an answer can be found there, and then do a web search on relevant keywords, before asking a live support-giver for help. Exceptional community members document things they have learned, so that future support-seekers can find the information and be helped.

• Support leeches will often ask the same question nearly simultaneously in multiple channels, and/or repeat it unneccessarily. This is most typical of entitled support leeches who feel that their question is so important that their desire for attention far outweighs the inconvenience to support-givers who monitor multiple channels. Clueless support leeches display a variation of this habit in which they ask a question in one channel, give up an getting help there after just a few minutes, and then ask in another channel.

Community members will ask a question in the correct venue the first time, and then idle there for at least an hour in case someone becomes active who does know the answer. A community member will repeat a question only if about an hour has passed, or if they see a known topic expert suddenly wake up. If their question goes un-answered for a long time, community members understand that no one is active in the channel with the time/skills to answer, and will ask in another venue (mailing list, forum, etc.) or at a time when support-givers from a different time zone may be active.

• Support leeches often go so far as to argue with support-givers.

The incongruity of asking someone for their expertise, and then argue with the proffered advice, baffles me to this day. However it is a common MO² among support leeches. Asking a probing question when advice doesn't seem quite right, or simply not taking the advice are acceptable, but one should not be pugnacious with someone offering their time and expertise to others for free.

• Support leeches are known for PM³ing support-givers without permission. This is an attention grab made at the expense of others seeking support, and is even detrimental to the needs of the support leech itself -- but support leeches persist in doing it anyway.

Support should almost always take place in the public support channel. This way support-givers can juggle multiple support requests effectively, and recipients of support can benefit from the input of multiple support-givers. Additionally, PMing anyone without his/her permission on IRC is a lot like following a stranger to his/her car -- no matter how "innocent" your intentions, you will still give off a creepy stalker vibe. Always ask permission before PMing someone you don't know well, and only move a support discussion to PM if it either includes privileged information (such as login credentials) or has veered far off-topic from the channel in which it began.

• Support leeches exhibit an inability or unwillingness use the /topic command in IRC to read a channel's topic. This leads to them frequently breaking channel rules and/or asking questions in a totally inappropriate channel, where their question is naught but off-topic noise.

• Finally, the most virulent form of support leech, the entitled support leech, as well as most clueless/entitled hybrids, are demanding and rude to channel denizens whenever possible. They fail to internalize the fact that they are asking for free use of others' time and expertise, and that volunteers have no reason to spend their time on those who treat them discourteously. Free support venues exist because someone finds it rewarding to help others -- the less rewarding the experience, the less support will be provided, either due to community members refusing to subject themselves to entitled support leeches, or to volunteer burn-out.

I sincerely hope that this information will help others in preventing and dealing with support leech infestations before they overwhelm their support venues. When time permits, I intend to follow up with a post on support leech encounters.

This week the unpopular people are the investment fund managers, so we are going to tax them extra, and not let them eat lunch at the cool kids' table.

One of the reasons our tax system is so insanely complex is that it's not designed to be about raising needed money, it's not particularly "designed" at all in the sense that there's some overreaching vision that has created a coherent system.

The tax system is our legislature's favorite plaything. They take away money from whomever isn't cool this week, and give it to whomever is. Meanwhile, in their great concern that we all be a little cooler, they tax ugly shoes (or whatever else they deem uncool) a little extra and provide tax credits for funky wallpaper (or whatever they think is cool). Since, like ditzy teenage mallrats, congress can't be bothered to think for a minute about the fact that trends change constantly, and it really isn't their business to try to rid the world of ugly shoes (or -- gasp -- that they may have horrific taste to begin with), the tax code is a pile of unrelated and sometimes contradictory snippets of fleeting fashion sure to rival any sixteen-year-old girl's clothes closet.

Did you know that federal income taxes haven't always existed in America? It was not until the Revenue Act of 1861 was signed into law by Abraham Lincoln, to raise money for the Civil War, that we had an income tax. We did fine without one for nearly 100 years.

You may be wondering why "capital gains" are treated differently than other types of income when it comes to paying taxes. We hear a lot about "capital gains" from the talking heads on TV, who seem to agree that there is some vague evilness about "capital gains", but never talk about what it is or how it got that way.

Article I, Section 2, paragraph 3 of our constitution says, in part, "...direct Taxes shall be apportioned among the several States...according to their respective Numbers..." "Direct taxes", in a constitutional sense, are basically taxes on things you already own. So, if the federal government wants to tax things people already own, it must be done by taxing each state according to its population. The idea is that once you have worked hard and finally bought your family a home, the federal government can't say "give us this much money every year or we'll take away your home". (States and localities have no problem doing this to you, of course.)

Now, what happens if something you own causes you to have more assets (stuff, money, anything worth anything)? This can be an "on paper" sort of income, such as if your house becomes more valuable over time or some knicknack you bought becomes a valuable collector's item -- you don't actually have more money, because you aren't selling your home or your knicknack, but in a legal sense it is income -- or actual money coming into your hands, such as if you rent out a house you own, or if a farmer pays you to cultivate some of your property. If the federal government taxes that, is it taxing something you already own (a direct tax), or is it taxing new stuff you are getting (an indirect tax)?

In 1895, in a case called Pollock v. Farmers' Loan & Trust Co., the Supreme Court said that income from things you already own (such as when those things become more valuable, or someone rents them) is a direct tax. That special income -- income from things you already own -- is today most often referred to as "capital gains". Congress, because it doesn't like being told it can't tax things, soon passed the Sixteenth Amendment, which changed the constitution to allow Congress to tax individuals for all kinds of income, including what we now call "capital gains".

There's a political theory that says "we don't like people who don't work for their money, so we need to tax capital gains more". It sounds good on TV! Unfortunately, it really hurts people. If you own a house, raise your children there, and want to keep raising your children there, but your neighborhood suddenly becomes more desirable, you may find that the house you bought for $120,000 ten years ago is now worth $200,000. That is an $80,000 capital gain! Do you want to pay taxes on $80,000? Is it fair to lose your home over it? Is it fair to go to jail over it? Remember, it's "income" you "didn't work for".

Now, here's the kicker: even if we did pretend that capital gains are all evil, and should be taxed like crazy, WHY should they be taxed differently for people with one job description than for people with another? That's like saying "there was a plane accident this week, so we're down on pilots, everyone who is a pilot will now pay extra income tax". This week people are freaking out about Wall Street, and we understand what those people do less than we understand what pilots do, so it's easier to make the argument while sounding good on TV.

At least the tax preparers, accountants, financial advisors, tax consultants, IRS auditors, and government beurocrats are all making lots of money trying to sort through all these exceptions and special cases.

Also posted to Political Illiteracy.

There's big business in selling tactical gear to people who don't know how to use it, and convincing America that a thousand other mundane consumptions (roller coaster rides, taxes, etc) are empowering, but there's nothing you can buy or ride, and nothing that the government can take from someone else to give to you that will make you a warrior. Unfortunately, consumption is how mainstream America approaches life.

The warrior ethos outright rejects passivity and non-responsibility.

The warrior knows that with a trigger pull, a well-aimed slice, or a powerful strike, he or she can end someone's life. The resulting corpse will be equally dead regardless of whether the warrior meant well or not, so the warrior had better do more than mean well -- he/she had better be right. In that moment, there is no one else. Inaction and action are equally weighty decisions -- either can save a life, or end one.

The warriors I know do not live passively. They don't whine about how "somebody" should fix education, or unemployment, or the crime rate. They mentor, teach and run for school board, they start businesses or share their skills with others, and they protect themselves and others. Mainstream America, by contrast, feels powerless and cynical -- that's how government has ended up in the role of national nanny -- making decisions about food, education, housing, religion, showers, and more that used to be made independently by citizens across the country.

In Ethics From the Barrel Of a Gun: What Bearing Weapons Teaches Us About the Good Life, (worth reading in its entirety) Eric Raymond writes:

"The Founders had been successful armed revolutionaries. Every one of them had had repeated confrontation with life-or-death choices, in grave knowledge of the consequences of failure. They desired that the people of their infant nation should always cultivate that kind of ethical maturity, the keen sense of individual moral responsibility that they had personally learned from using lethal force in defense of their liberty."

That "keen sense of individual moral responsibility" is lacking in our culture, and whether mainstream America realizes it or not, thirst for it is growing. We see it in the national obsession with action movies and video games, and the fact that people will actually travel to Ohio and buy $50 theme park tickets just to get a little closer to that cheezy "ride warrior" image and a little adrenaline. Consuming is the only "action" or "power" we "normal" citizens are supposed to want.

"To believe one is incompetent to bear arms is, therefore, to live in corroding and almost always needless fear of the self — in fact, to affirm oneself a moral coward. A state further from the dignity of a free man would be rather hard to imagine. It is as a way of exorcising this demon, of reclaiming for ourselves the dignity and courage and ethical self-confidence of free (wo)men that the bearing of personal arms, is, ultimately, most important.

This is the final ethical lesson of bearing arms: that right choices are possible, and the ordinary judgement of ordinary (wo)men is sufficient to make them."