This was mined by Joseph Bergin from a discussion with Manns and Rising and the Pace University Doctorate in Professional Studies Class of 2011 in February 2010. I (Joe) was trying to capture ideas about how experts write patterns. So these are patterns about writing patterns, though they are not yet developed. They are just ideas that can likely be developed into full patterns. Most of the suggestions here are the "solution" part of the individual patterns.
Some of this applies to writing in general, but we won't explicitly try to be that general.
Don't name a pattern too soon or you may find yourself committed to the wrong name. Keep lots of aliases. Both your own mindset and your readers will "force" you to use the name you first publish your pattern under.
e.g. The Evangelist pattern (Manns and Rising) should probably be named something like Energizer. ("Energizer Bunny"?)
Pattern writing is hard and you will have difficulty knowing how each of your ideas fits. You should expect to have difficulty with the scope of each pattern (how big a problem to try to solve). You should expect to have difficulty distinguishing (especially) between problem, forces, and context. It may take several versions and (Feedback) to get it right.
Patterns aren't written section by section. It is hard to know when a thought might result in a context or a force or a consequence or … This sorting is hard in general. Just gather thought about the situation initially. Is what you are thinking now the problem or a force or ????
The writer isn't inventing. He/she is just capturing what is already known by experts. Mine that expertise. Normally the writer is not the expert. Or at least others should contribute.
Don't try to do too much in any one pattern. Each pattern induces a small change that will be complimented by others. Leads to pattern languages.
To separate out the ideas from the muddle, focus on a specific case in which someone did the right thing. What was the context there, the problem, … You may be able to find several cases, similar or not.
Generalize from exemplars. Especially from different domains. But getting the right level of generality is hard.
It probably isn't worth even trying to write a polished pattern at first - even if you are an experienced pattern writer. Get it down and then fix and beautify it. Feedback on your early drafts will help immensely.
Patterns are never "finished" but always works in progress.
Capturing forces is a difficult part of pattern writing. Try to capture lots of ideas about what pushes you around in this situation.
Work a bit at a time. The only way to write something big is to write something small first.
Choose a form late in the process. Explicit meta-data is probably best early in the process.
Get lots of feedback on your ideas and your proto-patterns. Get feedback from domain experts, other pattern writers, and potential users/readers of your pattern. Listen hard to the criticism. If your readers aren't "getting it" that is up to you to fix, not them.
If it isn't best practice, it isn't a pattern at all. Not propaganda. Not the solution you necessarily "want."
Some problems can't be solved (maybe just advice) (Ref Lise Hvatum)