Guidelines
Patterns do not have to be very academic. You can dispose of the usually perfunctory academic abstract if you wish. PLoPs are about patterns. Patterns should stand alone. Envision a developer facing a problem and picking up your pattern for insight. You don't want to send them on a research journey, but want to give them a crisp insight. You don't want them to have to spend a lot of time reading it, either. Aim for one page or maybe two per pattern, and justify longer patterns carefully. Furthermore, in many cases, it is reasonable to split long patterns into two or more patterns.
If you are writing your first patterns, it might help you to know that:
- The pattern name is usually a noun, and usually comes from the solution.
- Patterns are about form: the essence of structure. If you can't draw a picture of it, it's not a pattern. In other words, you should have a drawing or picture in the pattern description.
- The solution should be general but concrete enough.
- Individual patterns are pretty simple; the power comes in combining them into sequences as they are used. Most first-time writers try to pack too much into one pattern. Maybe a big pattern is really three patterns in one.
- You're allowed to have a little fun, to use humour, and to do whatever it takes to make the pattern memorable.
- A good pattern is a piece of literature. Polish it so it's as readable as a good story.
- A pattern is never done but is always a work in progress. If you have a good idea for a pattern language, we will consider accepting a very early draft (non-polished) for review at the conference.
On the other hand, we're very fussy about giving credit where credit is due. Credit your sources of inspiration and the known prior art. Credit those who helped you clarify your ideas. You can collect these recognitions in a section that isn't in the critical path of the reader.
For more detailed guidance on pattern writing, see pattern language for pattern writing by Gerard Meszars and Jim Doble on Hillside web page.
