Software Development: Frequently Asked Questions
Frequently Asked Questions
Been taking some of free time to read through various mailing lists of projects which I am no longer involved (a project from which I was so rudely and unceremoniously and unilaterally banned). Not only are the same questions reoccurring but also the same condescending replies and complaints about the questions are reoccurring. Even if the people involved are not likely to read this I feel it is worth writing a little about the problems [and possibly make updates to this document in the future] so that others may learn from their all too obvious mistakes.
Question: Why do users keep asking the same questions?
Answer: Some users will always ask the same questions and never make any attempt to figure out the answer for themselves. It is easier and better to say nothing than respond rudely to these users, or failing that provide a short response that developers are aware of the issue. There are ways to reduce the number of questions asked but the sooner you accept the inevitable the better things will be for all involved.
Question: Why do developers keep asking why users keep asking the same questions?
Answer: Every question is an opportunity, questions often highlight various problems of some kind or another. Not all developers realise this. Many think they do but only understand it on a very superficial level.
If a project does not have good documentation and a clearly marked section for Frequently Asked Questions then developers should not be at all surprised when the same questions get asked over and over again. At the very least it is important to back link to previous discussions because it increases the chance of search engines leading users to the right answers.
If features of a program are difficult to find or understand then further testing and usability review may be needed. I know this sounds so obvious as to be patronising but all too often developers blame the user and fail to consider ways in which the software could be improved to make things even more obvious and questions avoided. If bug are known or features are missing long enough for the same questions to be asked frequently then once more it is worth expanding the list of Frequently Asked Questions or even creating a separate list of Known Bugs
Question: What to do? This isn't very encouraging!
Answer: Always try to create new contributors.
A collaborative system like a Wiki makes it easier to encourage users to help answer questions and write up the answers for future reference.
With more technical problems users should be encouraged to submit patches. Telling users to fork the project is not encouraging, not only that it is actively turning contributors away, and failing to instead of compromising and finding something mutually beneficial for them to work on.
Not all (not many in fact) users will be in a position to submit patches and even those who do may submit work that is more hassle than it is worth to maintain.
Expecting them to write patches with a very low chance of being accepted is not encouraging either. A project with clear goals where users get a sense of what is beyond the ordinary scope of the project can help reduce the number of unrealistic requests and proposals which would be too difficult to maintain.
I would hold up Inkscape and Abiword as projects which often do a good job of these tasks. Inkscape has been particularly successful in incrementally documenting problems, making it increasingly easier for the next brave soul to solve (case in point: better support for Macintosh users). Bullying unsuspecting users might amuse some but pointing people in the right direction is far more productive in the long run. There are far too many projects which fail to understand the need for maintainers to manage and guide as much as develop. Creating more contributors should create a self sustaining cycle and more active contributors should mean more time to work on the problems which really interest you.
Here's looking to the New Year and doing things a little differently, hopefully better.