@andyj: IF there's a default config file at the author's website, I find that's a great place to start. (Think of MySQL or PHP - theirs are like having the entire manpages in a single document.)
1. Your .info file should state "...the enclosed /usr/local/etc/filename.conf is for testing only, it is not guaranteed or expected to suit your specific needs." The .info should also state what defaults are implemented, if any, and which files to edit should they wish to make such changes.
When possible, add a link to .info pointing to help, install or "how to" pages at the
author website. Make .info do your bidding! Our jobs are not to teach people the basics of computing... or Linux itself (though we find ourselves doing no less at times) and even with the mainstream repos out there... help the masses as best you can, preferably with one or two attempts. For the Joe Schmo who wants this and that and the other thing which are very specific and helpful mostly just to them... we call those individuals "clients" depending on the circumstances.
2. The config(s) you do choose to enclose, just make sure that with those files, the application(s) start without error and can be tested using those configs. They may not do what the
user wants to do in the end... but there's no way to know what exactly that would be and they would be a great starting point as opposed to nothing at all. I lean toward averages - out of the next 100 people, these features/functions are usually requested by
most... and set up configs to match.
You can please some of the people, some of the time...
MariaDB example: Just have it configured to use path=/home/tc/mysql user=tc group=staff and have tce.installed just mkdir -p /users/tc/mysql if it doesn't already exist -- the user can alter the defaults as they please. Me, personally, I also run a check to see if the default mysql database was created; if not, run the basic initialize from /usr/local/etc/init.d/mysql.sh or mariadb.sh (this is also done with init.d files from Fedora, CentOS, RHEL and others so it tends to be accepted and sometimes appreciated. The goal here is to offer our users building blocks that work out of the box... and allow them to modify these OOBs to suit their specific desires. The Mods they implement tend to be what's most useful for the community to chip in with advice as long as there's a common starting point.
3. If and when there's a user who complains an extension isn't configured just the way they want it to be, point them to the .info file. If you've spent time helping someone set up a configuration, put the forum URL in the .info file! People helping people get stuck repeating themselves more than anything. Make your efforts truly
worthwhile. If over time there's 20 people we've helped in this fashion... put 20 links in the .info file! Some of our users actually READ those .info files before installing!! SOME. Not enough... but some!
Take care!