Ever feel frustrated on the #plone IRC chat or the mailing lists because you don't get any answers? This can often mean that you've asked your question in a way that is difficult to answer. Solving problems is a skillset with fairly well-established parameters, and fortunately (like any skillset) you can improve through practice.

One helpful exercise is to write a semi-formal error report. Discipline in analyzing your problem increases your chances of solving it. And if you don't find the solution while writing, your report will efficiently bring the rest of us up to speed. Here are the five elements that every report should contain:

1. The big picture. Start off with one sentence stating the general problem you are trying to solve. This orientation helps us see if your attempted solution is even in the right ballpark.
2. A snapshot of your environment. Give us version numbers for Plone and Archetypes, and perhaps another relevant Product. If we need more than that we'll ask for it.
3. Steps to reproduce the error. This should be a numbered list that someone who went to the trouble of reconstructing your environment could follow to reproduce your error. Try really hard before deciding that your error is not reproducible.
4. The expected result. This is usually pretty obvious, which doesn't get you out of stating it.
5. The actual result. Specific is terrific. If your error produces a traceback or other error message, this is where you give it to us.

Depending on the difficulty of the problem and your problem-solving skills, it may take you 5, 10, 15 minutes or more to write your first error reports. However, like everything, you will get better with practice. Also, as you build relationships in the Plone community, you will find us more willing to debug with you conversationally rather than through a formal error/problem report.

But to start with, you should simply submit your error reports to the plone-users mailing list with a brief introduction, or paste them to paste.plone.org and announce it on #plone if you prefer IRC. Those with time and inclination will ask you for more information. Sometimes instead of asking questions that go deeper into the specific error, we will ask questions a frame or two up from your immediate problem. So be ready to think outside the box.

Other times your error will represent a limitation of the software. Plone as it stands today may not solve your use case, either by accident or by design. At this point you have four options:

1. Leave. #php is right next door. Tell 'em limi sent ya. ;^)
2. Stay and Bitch. I mean, we can't really stop you.
3. Stay and Mooch. The ranks of the Plone welfare state grow every day.
4. Get involved. Write code or docs, or hire someone else to do it — we value both approaches equally.

Our preference of course is that you get involved. Plone is a community. Ultimately people talk to each other in the chat room and on the mailing lists because they have worked together and drunk beers together for years. We do want to be welcoming to newcomers, but if you as a newcomer want to demonstrate good faith, asking for help as described here is a good place to start.

Notes

• This howto is intended to be a user-friendly alternative to Eric Raymond's How to Ask Questions the Smart Way. ESR's doc is long and offensive, though once you realize that ESR is your crusty old merchant-marine uncle it can be fun and helpful.
• The error report format is adapted from Joel Spolsky's comments on bug tracking, e.g., in Joel on Software.
• A special consideration when posting to the mailing list: remember that people with answers usually only open mail that seems intelligent and clearly pertains to their area of expertise. In other words, your subject line is your "sales pitch," so make it specific and non-annoying. Examples:

Bad subject line

"GET METHOD!! URGENT HELP!!!!"

Good subject line

"Passing GET variables to FormController scripts returns FooError"

• A special consideration when using IRC: Don't ask meta-questions. Be specific. People look at the channel once in a while, and answer questions when they have time to do it - they are not under any obligation to help you. They most likely will, but you have to be able to state your problem in a good way. Example:

Bad way to ask

"Anyone here using Product XYZ? Anyone here have problems installing Product XYZ?"

Good way to ask

"Hi, I'm using Product XYZ, and I have a problem with using the feature that is supposed to do ABC - it gives me an error saying BlahBlahError - what is wrong?" — additionally, if you can't install a product, please provide the error message. Although there are hundreds of add-on products out there, it's usually possible to troubleshoot what's going wrong from the error message. Without it, it's very hard to help.