Template talk:Ticket

SF.net migration

Need to update URL, e.g.: http://sourceforge.net/p/flightgear/codetickets/1686/

encapsulate registration/ticket creation ?

we could easily support all main use-cases by combining related templates, e.g. {{Issue Tracker}}, which also encapsulates the registration and ticket creation processes. --Hooray (talk) 15:00, 1 April 2015 (EDT)

Actually I consider them to have very separate use cases. I would rather split {{Issue Tracker}} into three separate templates, say {{tickets}} for a link to the page listing the tickets, {{register to sf}} to link to the SourceForge account registration form and {{create ticket}} to link to the ticket creation form. (I guess the jargon will shift from issue to ticket so that {{issue}} will be moved to {{ticket}}.)

The bottom line is that I do not particularly like having to use named parameter unless it really is necessary. I much rather prefer having more templates with more descriptive names with only unnamed parameters. One could of course have four separate templates using a meta template, but then one would have to maintain five templates instead of four.

Additionally the templates should preferably link to each other in the related templates section. They would then not have gathered up in one single template with a slightly ambiguous name (when used in running text) for the sake of maintenance.

—Johan G (Talk | contribs) 18:58, 1 April 2015 (EDT)

thank you for your cleanup and documentation work, much appreciated ! Also thanks for your feedback - I am not opposed to handling this the way you say, I just figured that it makes sense to keep everything in a single place - i.e. for better maintenance, the reason being that updating stuff later on takes usually many months (if not even years). So by having dedicated templates for these things, updating should become easier hopefully. I was also hoping that similar templates could be used for "encapsulating" processes related to mailing list subscription, forum signup/participation, or even wiki registration - i.e. if there's ever the need to update things for some reason, there's only a single place/template involved. I do think that the Git link/repo link work has demonstrated remarkably well that it pays off to follow the DRY principle - which is what I was trying to do here, too. If we had done that with our fgdata docs (on using gitorious/git), it would now be much easier to update things for svn/fgaddon - which would be one of my long-term goals to ensure that we don't have to update dozens of articles manually --Hooray (talk) 21:39, 1 April 2015 (EDT)