Reporting Bugs in Inform

If you're not sure whether or not something surprising is a bug, you could try asking fellow Inform users at the newsgroup rec.arts.int-fiction. (If Inform produces what it calls an internal error, that's a sure sign - Inform should never do this, no matter how it's provoked.)

The Bug Report form contains instructions and contact information for reporting bugs in Inform's behavior. While bug reports are usually not acknowledged immediately on receipt, they are almost always addressed (and the bug report answered by email) before the next release of Inform.

Problems with the documentation may be reported to Graham Nelson (graham@gnelson.demon.co.uk), and do not require a form, just a description of the error.

Problems with the built-in examples may similarly be reported to Emily Short (emshort@mindspring.com) and do not require a bug report form.

Bugs in extensions should be reported to the maintainers of those extensions, who retain the individual responsibility for upkeep.

Making Feature Suggestions

Much of Inform's design has evolved through the suggestions of its users, as we receive feedback about what is useful for projects and what still stands in the way of authors. Fresh suggestions about Inform are welcome, and should be emailed to Graham Nelson.

That said, your suggestions are most likely to be useful if

• They are specific. If you would like to be able to do something new, can you give samples of the syntax that you would like to use? Can you explain what the results should be?
• They are grounded in experience. Ideas related to projects that you are working on or want to work on, and where you have done some exploration of the problem already, are more likely to be helpful than blue-sky speculation.

It's probably fair to say that we are more likely to accept suggestions if they follow the grain of Inform. There are well-established conventions used by all well-established conventional programming languages, but we don't necessarily follow them. We're not very interested in traditional computer-science syntax, and more interested in thinking about how natural language - and books, and newspapers - communicate.

Some suggestions are sufficiently easy to implement and uncontroversial that they are simply accepted and included in a future version of Inform.

The more ambitious suggestions, on the other hand, may be selected for some further community discussion. Periodically, the authors of Inform post a consultation document that lists current plans, explains why rejected suggestions cannot be taken up, and requests more feedback on suggestions that are still under debate.