Purpose: to info the Wikit's community about the process by which one makes changes to the community's standard level Tcl distribution.
Also known as TIP, this is a proposed process being discussed and implemented by the Tcl Core Team also known as the TCT. The home base at this time for TIPs is http://www.cs.man.ac.uk/fellowsd-bin/TIP/ . To learn more about the process, visit this site and read TIP number 2 (which also includes a skeleton TIP). TIP number 3 is the article discussing the format of a proposal that you wish to submit for consideration. TIP number 0 contains pointers to documents describing how to move from a TIP to a change in the Tcl distribution.
TIP 7 is an excellent example of a TIP that is following the format, procedure, etc.
Tcl Improvement Proposal Q&A
Q. Why write a TIP instead of some other ad-hoc format?
A. Because it makes life much easier for virtually everyone if there is a document, conforming to some standard format, that details the design decisions involved. It is also archived properly, and published in a standard fashion in places which assure reasonably good amounts of eyeball-time from those with an interest. These are big advantages. Think of this as being a process similar to the IETF Request for Comment (RFC) or the Python PEP process.
Q. Will you accept my TIP?
A. Yes, provided it fits the formatting standard (I might help out if I'm not snowed under with work,) has reasonable spelling/grammar (it doesn't have to be perfect, but have a care for your readers,) and is not either a duplicate of an existing TIP (duh!) or not related to Tcl/Tk (I've not had to invoke this last clause yet.) I want to get as many TIPs published as possible, and you should remember that the publishing of a draft TIP is just the start of a process; you will still be able to make changes and it is quite possible that further discussion will ensue.
Q. How do I submit?
A. Just email it to mailto:[email protected] (either as inline text or an attachment) or, if he's on vacation, just dump it on [email protected] (though contacting the editor is a bit better, as he'll then publish it there once its in the archive.)
Q. It is a lot of work; why?
A. Getting your thoughts together into an organized-enough state for other people to comprehend them always is. It is worth the effort though, especially since if you wanted anyone to really get interested in the idea, you'd probably have had to put the effort in anyway.
Q. Why the arcane format?
A. It gives us a chance at doing all sorts of sophisticated processing, whereas doing so with random pieces of HTML is... hard... and if you allow several formats (Word, WordPerfect, HTML, XML, nroff, FrameMaker, LaTeX, plain text, etc.) it really doesn't give anyone a fair chance! The format is fairly close to the Wiki format used here. See TIP#3 for details...
Q. I've a great idea for Tcl - where do I start? At what point does someone submit the TIP?
Donal K. Fellows writes on comp.lang.tcl: "... TIPs are really intended for submissions with coding effort already arranged to back them up, and patches should be submitted to the SourceForge patch manager (for technical reasons; your TIP can always refer to them by URL.)
If there's no TIP to back up a patch, you can just submit the patch itself to SF (and contact me at [email protected] if you think a TIP might be needed; I might co-author/ghost-write one. :^) OTOH, if you have a suggestion but currently no opportunity to back it up with code, use the Feature Request tracker on SF instead (not that this guarantees that the feature will get implemented, as the core maintainers have quite big workloads already, alas.)
Q. I see some TIPs listed on the above web site that were submitted months ago. Do all TIPs take a year or more to be approved? A. Some TIPs are more intended to point the way towards how things are done, and so are being left open. Most of the TIPs intended for actual changes in Tcl or Tk, etc. are dealt with in a timely fashion. Some TIPs are either vague in their implementation detail or were mistakenly submitted without having code support and so are waiting further discussion.