Many of you often have really neat ideas that the rest of us might really want to see involved. There's a joke even that if you have an idea, you have to: "Tell Walker and he'll get it in for you!" - Simply because I have a dozen mentions in the help files.
Well - for that dozen mentions, I put 2 dozen submissions in for consideration. And a lot of my good ones, I had asked for suggestions that they might have had on a big ol list of "features that might be neat but I don't wanna do right now."
So I've written a short little howto on getting your name into the "help changes" list:
All of those that got accepted are similar in the following ways (in no particular order):
*) The easiest way to get in: fix a bug. A few lines of code at most. ;).
*) They're written in a code format that's quite similar to the way the devs write. If you don't write that way - that's what "make indent" is there for. Nobody likes having to reformat other people's code into a way that's consistent with surrounding code. (And not doing so leads to really ugly spaghetti code)
*) Usefulness. How useful will it be? Think like a geek looking at a toy here: The more things you can do with it, the more it makes you giggle in anticipation, the better =)
*) Help files. No coder likes writing documentation, and this includes the devs. If your patch includes a new feature, write a clear helpfile for it.
*) Redundancy. Writing a big patch for something that can be done with 3 functions isn't likely to get accepted.
*) Thoroughness. No bugs, plenty of well done input checking, etc.
Put it all together, with a brief interest catching description atop the patch, and send it in to the devs. (NOT as an attachment - but as the body of the email itself)
And with a wee bit of luck, a few patchlevels after you send in the patch:
* . patch by YourNameHere.