Template talk:Project infrastructure

From FlightGear wiki
Revision as of 01:29, 28 February 2016 by Johan G (talk | contribs) (→‎Slight variation of the current architecture: I thing I am starting to get the concept; an early draft of my alternative idea is available)
Jump to navigation Jump to search

Hijack

@Hooray: This idea is too useful, so I might hijack it ;) I'll move this from {{Project URL}} to {{project infrastructure}}. Then the default option can be mode=url. I would like to have a mode=name returning SourceForge, and mode=abbrev returning sf. I will then use this in the {{repo link}} family of templates to make the subtemplates 100% independent of the current infrastructure, so that the links will be timeless :) This single template could end up being the sole reference to SourceForge and other infrastructure on the whole wiki.

Bugman (talk) 02:08, 26 February 2016 (EST)

yes, that was the idea - I was just expecting to spend a few weeks doing this, and not to come back realizing that you finished the whole thing in a few hours. So, thank you very much for doing this. It is good for us to learn from the sourceforge transition and try to prevent certain issues in the future.--Hooray (talk) 06:43, 26 February 2016 (EST)

Forum

probably need to extend the template a little to support this use-case: http://wiki.flightgear.org/index.php?title=Template:Forum&action=history

--Hooray (talk) 06:28, 26 February 2016 (EST)

I guess an optional 'urn' parameter for appending to the URL, as well as a 'text' parameter to change the name of the link would do. Then {{forum}} could transclude this template.
Bugman (talk) 06:56, 26 February 2016 (EST)
Done.
Bugman (talk) 08:38, 26 February 2016 (EST)

Other URLs

  • scenemodels.flightgear.org
  • liveries.flightgear.org
  • multiplayer map
  • add ticket/issue tracker template here ?

Some suggestions

First off, implement this step by step, and think the architecture through during the process. Do not lock yourself in early.

I still have frustrations with annoying inconsistencies and non user friendly naming schemes in the FlightGear screenshot categories due to "flash-implementing" early ideas before thinking them through thoroughly.

Johan G (Talk | contribs) 16:26, 27 February 2016 (EST)

just for the record, I do agree with this, but on the other hand, had bugman not taken my original idea and developed it much further, I would still be dabbling that - so, basically within a few hours, bugman went through several iterations of this, without needing much in terms of feedback, and I am pretty satisfied with it personally. I do get your point though, so I would suggest to document "best practices" - I am not much a wiki guru myself, I really only use a tiny fraction of its markup/features, and I am always glad for your contributions to my templates, because it's not something that I am very good at/interested in - I would rather write php/javascript code than having to memorize wikimedia templates myself. But if there is anything that we/I can do better to lighten your workload (Johan, Red Leader, Gijs), please just document your suggestions somewhere. In terms of the overall idea here, I believe it is the right thing to do, and while it my not address all your concerns, it is certainly better than the existing practice - and had we done this a few years ago, we would not be having certain problems now. So I would politely suggest that "we should not let the perfect be the enemy of the good" here, this isn't core development after all - it's just a wiki, and anything that helps reduce our workload is a good thing, until someone comes up with something better somewhere down the road. All in all, let's also keep this in mind (which may have no immediate repercussions at all, or which may have unfortunate side effects in a few years/months. So, thanks again bugman for all you have handled so far - it's certainly much better, and much faster, than anything that I could have come up with in this timeframe, and I am very impressed with the quality of your wiki involvement - then again, thanks also to Johan for providing the kind of feedback that bugman asked for - but please let's not overthink this... Talking about the "architecture of a template" is a bit too much for my own taste --Hooray (talk) 19:53, 27 February 2016 (EST)

The mode parameter

I think the mode parameter is slightly ambiguous and maybe misleading. I would expect it to be something like for example type or infrastructure rather than mode.

As this is an unnamed parameter this is merely a change in the documentation.

Johan G (Talk | contribs) 16:26, 27 February 2016 (EST)

I agree. This was just a quick and random choice, as I've been generating a lot of template content very quickly recently with the aim of having practical and functional implementations. So no real thought has gone into this. I'd suggest type to allow this template to be a universal resource.
Bugman (talk) 16:37, 27 February 2016 (EST)

The name value of the mode parameter

I would say that even though it is an important part of the project infrastructure SourceForge is merely the host of the main repositories.

Here I would probably rather expect something like for example host or main-repo rather than name.

Johan G (Talk | contribs) 16:26, 27 February 2016 (EST)

Again a random and quick choice :) What about provider? Though SF is not the provider of everything FG related, so something along the lines of main... might be good. I have no real preference - this is the default value of the ex-mode parameter, so you wouldn't normally use it when transcluding anyway.
Bugman (talk) 16:44, 27 February 2016 (EST)

Slight variation of the current architecture

This might make for a slightly more complex template, but consider this:

{{project infrastructure|infrastructure|attribute}}

All parameters would be optional optional. If none is given it could e.g. default to the URL of the project page at SourceForge.

infrastructure
Name of the infrastucture, e.g. forum, wiki, main-repo, scenedb or website. Could e.g. default to main-repo
attribute
One of several attributes associated with the infrastructure, e.g. name, abbreviation, url, host etc. Could e.g. default to url

I think the template would be slightly more flexible this way.

It could be implemented with two levels of {{#switch: }} parser functions and use the #default = case to catch most errors. Something like:

{{#switch: {{{1|main-repo}}}
 | wiki = {{#switch: {{{2|url}}}
   | name = FlightGear wiki
   | short-name = wiki
   | url = http://wiki.flightgear.org
   | #default = {{error|Attribute '''{{{2}}}''' invalid for infrastructure '''wiki'''|project infrastructure}}
  }}
 | main-repo = {{#switch: {{{2|url}}}
   | name = Main FlightGear repository
   | short-name = main repo
   | host-name = SourceForge
   | host-short-name = SF
   | host-url = http://www.sourceforge.com
   | url = http://sourceforge.net/projects/flightgear/
   | #default = {{error|Attribute '''{{{2}}}''' invalid for infrastructure '''main-repo'''|project infrastructure}}
  }}
 | #default = {{error|Invalid '''infrastructure''' parameter|project infrastructure}}
}}

The template documentation should probably be complemented by a table of available infrastructure and attribute combinations.

Johan G (Talk | contribs) 16:26, 27 February 2016 (EST)

Please feel free to change :) This all sounds great. My focus is on recursive transclusion for simply pulling out sf, so we can pragmatically change the behaviour of templates. I can quickly adapt all usage of this template to match. For example {{flightgear source}} uses it to completely avoid the SourceForge reference, to then pass it into the now very powerful {{repo link}} template. The table idea is good as well. It could replace the examples section by absorbing the examples. I just have some suggestions:
  • A code value for the second option (replacing abbrev). This would return sf. This would be used as a simple internal wiki code for programmatically changing template behaviour.
  • Alphabetical ordering of values in the switches, in case this becomes quite big.
  • url return values of [http://wiki.flightgear.org FlightGear wiki].
  • main-repo name as "Main FlightGear infrastructure", as this is a collection of repositories, plus a lot of other FG infrastructure. Maybe main-infrastructure would be better for a value, though it is a little long. What about just main?
Bugman (talk) 17:02, 27 February 2016 (EST)
Is that ok for you? Only after I posted the above I saw how many places this template touches already. Though still I would like to have it done.
  • I am not sure I understand your first point. Is this for a switch in the templates?
  • Good point about alphabetical ordering of the attributes/values of the switches.
  • I would rather expect url to return a clean and somewhat more reusable url like http://wiki.flightgear.org. How about a link attribute to return the external link like [http://wiki.flightgear.org FlightGear wiki].
  • I am ok with main (even though I find it a slight bit ambiguous ;-) ).
Johan G (Talk | contribs) 18:35, 27 February 2016 (EST)
I think I have a better grip on what you and Hooray are aiming for now. You basically want to be able to get a link (with optional custom label), a name and the possibility to add an "URN" (not really an URN per see though ;-) ).
An early draft can be found at User:Johan G/project infrastructure.
Johan G (Talk | contribs) 20:29, 27 February 2016 (EST)