A different way of saying the same thing
I was reading Chris Crawford's book On Game Design today. It is a mostly engaging combination of advice, philosphy and concrete examples. A nice read and a book that does not have to be read at all at once and you can jump around a bit inside it.
One particular page may change my thinking for a little while (the two paragraphs before the conclusion section in chapter 18, for those who own the book).
He was discussing how he handled suggestions from playtesters. Although his focus was on game design (rather than implementation), it had direct application to bug handling as well -- playtesting being in some ways equivalent to the beta-release phase of an open source project. Crawford classifed suggestions into four categories. The following is my own slight rephrasing into general software development terms:
- Additions: new features. Reject them out of hand during the playtesting (beta) phase of the project. If you need the addition, then the game needs a redesign.
- Embellishments: improvements to existing elements. Consider them, but the burden of proof is on the embellishment. Resist the urge to fiddle for the sake of it and only implement the improvements that are really worth it.
- Corrections: things which fix clumsy (or broken) aspects of the design (a.k.a. real bugs). Fix them.
- Consolidations: "Bring two dissonant aspects of the game into deeper harmony" (his words, not mine). Think of feature consolidation, reducing cluttered interfaces, or improving workflow. These you will generally want to implement, since they genuinely improve the product.
In the next paragraph he puts voice to some ideas that strike me as very applicable to open source projects. If lots of people are contributing, some will feel that their ideas are not being valued.
"...Some people think that open mindedness requires a designer to hear out every idea, to give every suggestion its day in court. This isn't noble; it's stupid. [...] If somebody surprises you with an idea you didn't think of, you should consider it a warning sign that you haven't thought through the design carefully enough. [...] Be courteous, but concentrate on doing your job."
Strong words and maybe not to everybody's liking (particularly in a partially edited quote like this, but I think I have kept the essence). Of course, this is not a universally applicable mantra. Many projects are lobbed out there as a mere framework in order to permit other people to brainstorm the future direction of the project. But at some point in most software packages that have a long life, features will be added after a certain amount of design. The design may be bounced around for a while and the rough edges smoothed off, but eventually we get to the point where the above quote becomes applicable.
I can think of maybe a half a dozen or so people in open source projects I am peripherally involved with whom I would immediately classify as "really good designers" (just considering people I have a lot of interaction with). Looking at the behaviour of these people, it seems that they have a good understanding of all of the previous points and apply these skills consistently. I think I realised this already as one of the things that separated this group from the crowd. But sometimes a restatement of known ideas can bring them into sharper focus, at least for a little while.
None of this is particularly revolutionary. Most of it is even fairly obvious. But today's reading is going to bounce around in my head for a bit; hopefully with some benefits.