, or Tcl Improvement Proposal, is the mechanism by which changes to Tcl and Tk are introduced, accepted, and documented.See Also edit
- Documentation
- The top page for Tcl documentation
- List of TIPs
- a list of TIPs with a presence on this wiki
Documentation edit
- TIP 2, TIP Guidelines
- describes and defines the editorial process a TCT document (TIP) has to go through before accepted as official. Also provides a skeleton TIP.
- TIP 3, TIP Format
- describes the structure and formatting to use when writing a TIP
Description edit
The TIP process was established by the Tcl Core Team for proposing, discussing, and implementing changes to the core Tcl and Tk source distribution that would result in C API or script level API interfaces.TIP 7 is an good example of a TIP that is following the format, procedure, etc. except that implementations should be submitted as patches to the appropriate project and a link to the patch item made in the TIP itself. (This policy exists because TIPs are published on news:comp.lang.tcl.announce.)Votes require (an) implementation (plan).A "Feature Request" is a lighter-weight entry point for people with clearer ideas about needs than implementation.Q&A edit
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:donal.k.fellows@man.ac.uk (either as inline text or an attachment) or, if he's on vacation, just dump it on tcl-core@lists.sourceforge.net (though contacting the editor is a bit better, as he'll then publish it there once it's 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?A. Donal 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 donal.k.fellows@man.ac.uk 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. But wait! I'm not a C programmer. I just have a great idea that I want you guys to put into Tcl!A. DKF: Well, at least submit a Feature Request to SourceForge. Then the idea won't get lost. But since there's always more to do than people to do it, the things that get done will be the things that have someone really trying to get them done.Note that the Tcl C code is much easier to read than most projects.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. And some just slip for no good reason; prod a TCT member by email or on the chat if you feel that insufficient action is being taken!Q. Does submission of a TIP mean that the idea will go into Tcl's core?A. Not at all. In fact, a recent TCT posting by John Ousterhout mentions that there is, in general, 2 reasons for putting something in the core:- The existing Tcl C APIs don't permit the feature to be implemented as an extension (if this is the case, we should first consider adding the bare minimum API support to permit external implementation, as opposed to putting the entire feature into the core).
- The feature is needed by a substantial fraction of the entire Tcl community.
Misc edit
One possible ideal: TCT does as little as possible with TIPs. That is, TCT supervises/manages/oversees the process. Engineering work shouldn't be a TCT responsibility (in general? sometimes? ...).Note that a number of TCT members are also active TIP authors, but this does not let anyone off the hook. The TCT makes sure the engineering quality of suggestions is good enough and provides technical reviews of them. Implementations have to be supplied by the proposer though if (s)he can get someone to help, that's all to the good of course...Category TIP is given to wiki pages relating to TIP's. However, it might be better for the conclusions or major points of discussions to be added to the tips.
Suggestion: When a TIP is approved and implemented, add the feature, and TIP#[appropriate number] to the appropriate Changes in Tcl/Tk page. This effort has begun, but help filling in the older TIP info would be greatly appreciated.DKF: The info goes in the ChangeLog (the definitive detailed history) then the changes file, and only then to the wiki page (i.e. it's a part of the release activity). Unless someone puts it in first of course.
Taking a look at http://tip.tcl.tk/
reveals that- 1 non-technical TIP is in "Active" state
- 21 non-technical (process or informative) TIPs and 87 project TIPs are in "Draft" state
- 4 non-technical and 1 project TIP are in "Accepted" state
- 6 project TIPs are in "Deferred" state
- 4 non-technical and 206 project TIPs are in "Final" state
- 23 project TIPs are in "Rejected" state
- 1 non-technical and 36 project TIPs are in "Withdrawn" state
