Textpattern Support Forum

We get many requests for new features. While there are plenty of subjective reasons for choosing or rejecting features, here are a few tips that might help.

The features that are most likely to make it in to Textpattern are:

• already written, tested, and submitted as a patch
• simple, minimal, obvious and well described
• clearly beneficial to many users
• unlikely to cloud the interface with Too Much Choice

The features likely to be rejected or ignored are:

• not described clearly
• of interest only to a minority of people
• easily (and more sensibly) implemented as plugins
• difficult to test
• potentially insecure
• full of complicated conditions or potential error cases that need to be handled

I’d really like feature XYZ to be added, how can I help?

By far the best thing you can do is write the code yourself, or find someone to do it for you. The dev team will be in a much better position to evaluate the potential benefits and drawbacks of a new feature if they have the code sitting in front of them. (The dev team members themselves work this way: when one team member wants a new feature added, he’ll produce a patch and send it to the others for evaluation).

It’s in our best interest to encourage submissions. But once we add something to the core, we’ll have to maintain it, fix bugs, and support it. For that reason, we’re most likely to accept patches that:

• don’t explode, obviously
• are brief and readable (beware of whitespace-only changes, they can easily bloat a patch and make it difficult to find the real changes)
• have already been field-tested as plugins or published hacks
• follow the Textpattern style (we’re not style thugs but we like short and sweet: it works for us)
• don’t duplicate code that’s already in Textpattern
• patch cleanly against a current version

Also helpful:

• anticipation of potential problems, and suggestions of ways to avoid or handle them
• if there are Textpattern tags involved, think through the syntax and provide some examples
• draft some documentation (you don’t have to wait until afterwards – sometimes writing the documentation first is a good way to find potential problems and improvements)

What’s a patch? I still want feature XYZ, dammit!

If you’re submitting a feature request, or have read someone else’s and would like to see it added to Textpattern, here are some things you can do to help improve its chances:

• make sure the description is clear and obvious (feature requests do come in that we can barely understand, let alone implement)
• as well as a general description, give some concrete examples of how it might work
• anticipate potential problems, and suggest ways to avoid or handle them
• if there are display or input elements involved, try mocking up a design and posting screenshots or HTML code of what it might look like

Things people often do that won’t help at all, and might make it harder to follow the discussion:

• vote, second, or say “me too!”
• bump the thread every three days
• keep adding bells and whistles to otherwise simple requests
• ask for anything and everything to be configurable