User:Yunshui/Give a man a fish...
 | This is an essay. It contains the advice or opinions of one or more Wikipedia contributors. This page is not an encyclopedia article, nor is it one of Wikipedia's policies or guidelines, as it has not been thoroughly vetted by the community. Some essays represent widespread norms; others only represent minority viewpoints. |
"Give a man a fish and he eats for a day, but teach him to fish, and he eats for the rest of his life." Proverb
"Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life." Terry Pratchett, Jingo
Often, when new users appear at the Help Desk or Teahouse with questions, there's a strong temptation for responders to immediately go to the article and fix the problem. A new user can't get the infobox image to display properly, so an experienced editor fixes it for them. A new user wants to make a table, so an experienced editor creates one for them. A new user needs to find sources, so an experienced editor locates some and inserts them into the article.
On the surface, that seems like a nice thing to do. After all, the newbie is struggling, and the solution is just obvious - why not step in and save them the trouble? The problem is that this keeps all the knowledge in the hands of the experienced editor, and prevents inexperienced editors from learning how to do something new. In essence (although few, if any, editors intend this effect) it disempowers the newer editors - yes, you've solved their immediate issue, but to them, Wikipedia is just as arcane and impenetrable as ever. Incomprehension is a major factor in our falling rates of editor retention, so by keeping all the know-how on the old hands' side of the fence, we're not doing a lot to increase our influx of new blood.
That's not to say that fixing dodgy infobox images or broken tables is A BAD THING - clearly it's helpful, and improves the encyclopedia (which is rather the point of the whole exercise). Rather, if there's a small technical improvement to be made, it's better to tell the editor how to do it so that they can fix it themselves, learning by doing in the process. If it's sufficiently urgent to warrant an immediate fix, then after doing so we should explain exactly what we did, so that the new editor gains a better understanding of Wikipedia as a result. The optimum goal, though, is for new contributors to be guided through - not shown - the processes, until they are competent and confident enough to do it themselves. Then they too can answer questions - and hopefully, read this essay before reflexively fixing the problem themseves.
Acronyms are not a substitute for explanation[edit]
The temptation, if you want a new editor to fix something, is to tell them: "See WP:STRINGOFCAPS." This takes them (hopefully) to the appropriate policy, guideline or Help page for their query. Hooray! you think, they now have all the information they need. How helpful I am!
Technically, yes, you've given them the information they need. However, many if not most of these pages contain far more information than the newbie needs to solve their problem. If they want to know how to insert a reference, is giving them the 64kB of WP:CITE really more helpful than telling them how to put <ref> tags around a citation? Sooner or later, they will need to read the "official" guidelines, but saying, "Oh, you want to add a reference? Here's a four-and-a-half-thousand-word document laden with technical terminology and links to other gigantic pages that explains every aspect of the process, as well as the many options and variations involved. Bye now!" is not likely to encourage them to carry on editing here.
Instead, explain it to them yourself. Summarise the Help page, or extract the relevant answer from it. There's nothing wrong with briefly explaining how to cite a reference and then adding, "see WP:CITE for more information", but the explanation is the important bit. It's good for you, too; often the process of condensing a huge policy document into a few sentences will help you yourself to get a better handle on what the policy means. Avoid using acronyms as a substitute for explaining things yourself, and Wikipedia will become more welcoming, less arcane, and hopefully, filled with better editors.