Talk:Wiki guidelines

Map Features pages

There seems to be a fair amount of inconsistency with the naming of map feature pages. Some of them are created as sub-pages of Mapping/Features, whereas others are given their own, shorter name (eg Harbour, Cycle routes). There's also inconsistency over whether the names should be plural or not. Finally, some features end up getting described extensively on the key pages (eg highways are described at Key:highway).

I'd suggest a few principles:

• Stopping the practice of using sub-pages of Mapping/Features - I don't think the use of sub-pages is helpful here, as it makes pages harder to link to, and doesn't help any form of automatic indexing (the index at Mapping/Features is manually written). Instead, we should use categories to keep the pages together, and simply link to the pages from Map Features.
• Every tag and key in active use (more than a dozen or so usages from a few different users) should get a corresponding tag and key page. These should describe how the tag is used, and contain the appropriate infobox.
• Where there is a close 1-to-1 match between a feature and a tag (eg 'post boxes' and amenity=post_box), simply redirect from the feature page to the tag page. Where the feature has a 1-to-1 match with a key (eg 'Tunnels' and tunnel=*), redirect to the key page. Where the feature uses multiple tags across multiple keys (eg 'Railways' uses railway=*, tunnel=yes, highway=platform, etc), have a separate Railways page which links to the relevant tags.

Frankie Roberto 12:35, 2 September 2009 (UTC)

Removing all Mapping/Features pages for no prefix. Feature Index Martin Renvoize 09:22, 18 December 2009 (UTC)

• Completed --Martin Renvoize 12:14, 19 January 2010 (UTC)

'WikiProjects' Prefix for articles about places

Conversation moved to Talk:Wiki organisation

Archival

There's plenty of articles floating about in Category:Out of date which could simply be deleted or Archived in some manner. What is our policy here?

A good example is Winter Mapping which was written in 2006 about events and idea's that were floating around that December. The page could be re-written as a portal to all Winter Mapping Projects (Piste Map maybe?) but then the original data would be lost to the depths of history. It's more of a conversation than an article so does that even matter? It's nice sometimes for nostalgia reasons to be able to go over old articles seeing what has been accomplished, so maybe some sort of archival system would be useful. I did notice the Past_Events_2006 page which is I suppose is what I'm really thinking of but am unsure of it's use. Should the contents of an article be copied to a new page for archival, or renamed (keeping the history) so that the original name can be used once more for a more current article?

Martin Renvoize 15:48, 2 December 2009 (UTC)

I've moved it to Winter Mapping 2006 and added some explanatory sentences at the top. In general pages relating to a specific event should have the year (I often also include the month) in their title. This page describes several events, but they're all in 2006 so...

What we don't want, is for people to do a search, find that page, and expect to read up-to-date information about winter mapping. With "2006" in the title, I think that makes it clear.

-- Harry Wood 19:31, 4 October 2010 (BST)

Duplication Section

Nice clarification there Harry. If the duplication is within the simple summary or introduction to a topic you mentioned

"we may decide to leave a summary section on one page, with a link leading to a whole page dedicated to the topic with more detail."

An alternative to this, which may also be useful is to take the Wikipedia view on this (prolific in their help sections especially) where a summary or introduction is often included in pages using a template link to another page. i.e. If a good summary exists to a large topic, then a page is created with said summary. It is then placed as a template at the beginning of any page deemed relevant. As such the summary can be edited in much the same way as a template affecting all pages simultaneously and limiting the scope for duplication while allowing the user to read their entire article as one flowing text rather than jump to a summary page, then jump on to find the specific bit their interested in.? Martin Renvoize 12:12, 3 December 2009 (UTC)

Commons images that were uploaded locally

With Talk:Wiki/Archive01#Allow use of images from wikimedia commons in effect, should some of the Commons images that were uploaded locally be purged? Some of them are lacking attribution and licensing, and I'm guessing many aren't translated into different languages. And of course any improvements at Commons aren't here. --goldfndr 10:18, 8 January 2010 (UTC)

I'de agree with that. another target for cleanup. --Martin Renvoize 11:53, 8 January 2010 (UTC)

Link vs unlink self redirects?

A number of uses of the {{Tag}} templates are redirects to the key page or redlinks. For example, access=yes and access=no and oneway=-1 are unlikely to ever become individual articles, so the (in my opinion) proper use is access=yes and access=no. But the Key:access and Key:oneway pages have the values wikilinked.

When I come across these, at first I think, hey, more information about a specific tag (key/value combination). But it's anticlimactic.

Is there an advantage to using self-redirects that tease/taunt more information? Was this edit improper? Will key=number or key=* eventually have their own articles? --goldfndr 11:38, 13 January 2010 (UTC)

In my opinion, tag values that are properly documented in the key page can be redirected to the key page. Red links should be used only where "this could be documented, but nobody have done it yet". Where "this is documented elsewhere" a redirect is in place. For access=* and many derived pages of it such as oneway=* all common values can be redirected to the key page where all common values should be explained. For oneway that means that the values yes, no and -1 should be, and are, explained on Key:oneway, therefor redirected. --Skippern 12:04, 13 January 2010 (UTC)

Ah, I mistitled this section. I've corrected it/clarified it for what I'm after.

I'm not questioning the existence of the redirect pages (the symptom), I grudgingly concede that. I'm questioning the linking to these redirect pages (the cause). I'm not advocating red links, I'm advocating black unlinked text by putting the value in the tag template invocation's third parameter instead of the second parameter. Although Tag:type=foo had five incoming pages earlier this hour, it now only has one (and I'm tempted to edit that Proposal page). If I hadn't edited the vending machine pages, I'm wondering if a Tag:type=foo redirect page would have come into existence. (Drat, now there will be two. :p ) --goldfndr 12:45, 13 January 2010 (UTC)

I think we should try to remove all instances of access=yes and replace with access=yes (and likewise for similar tag situations) But in the meantime (and actually even after removing all instances) there's no harm in having a redirect 'Tag:access=yes' -> 'Key:access'

I'm not so sure I agree with "tag values that are properly documented in the key page can be redirected to the key page". I actually prefer red links. I recently created the page Tag:leisure=swimming_pool replacing a redirect which you'd put in place. I'd like to think that page would have been created a lot sooner by somebody if it had been left as a red link. Visitors to the wiki who are unlikely to edit anyway, may benefit from the redirect, but on the other hand they may be confused/disappointed by it as goldfndr says. Red link gives a fairly clear indication that the page can be created by somebody who wants to contribute. Meanwhile replacing a redirect is more tricky. Some potential contributors may not realise how to do it.

That's my thinking the on the matter, but it is quite a niggling little point. I don't think it really matters either way :-)

-- Harry Wood 10:25, 22 February 2011 (UTC)

In my ideal vision, a page would only exist for a tag value if there were other tags specifically associated with that tag's value (e.g. sport=chess, leisure=track) or if there was a possibility of confusion with other tags (e.g. highway=raceway). For example, looking at the list of denomination=*, each of the religion=* values with a corresponding denomination could use its own page. But for sport=beachvolleyball and shop=furnace and emergency=water_tank, until some additional tags are decided, they aren't worthy of their own pages and should be redlinked or not linked, with the description+photo on the sport=* and shop=* and emergency=* pages sufficing.

If I recall correctly, Skippern's reasoning behind "tag values that are properly documented in the key page can be redirected to the key page" was that there was some editing software that could open a web page with the Tag:foo=bar page, and if one saw a "There is currently no text in this page" result instead of being redirected to the Key:foo page, one could be confused at where to go. I don't know if an editor with such a capability exists (perhaps the logs know) or if it was merely hypothetical, but I'd like to think that any such editor could check for the no text result and instead request Key:foo on its own without needing to inflate the size of the wiki to compensate for its lack of exception handling.

There was a rationale previously mentioned that I'd (at the time) found logical: each Tag:foo=bar page would have its own Taginfo/Tagstat/Tagwatch values, saving a click. But, on the other hand, when one visits Key:foo's Taginfo/Tagstat/Tagwatch page(s), one sees that the Tag:foo=bar's corresponding pages are only one click away, and saving only one click seems unworthwhile, so I withdraw that concurrence. --goldfndr 10:14, 28 February 2011 (UTC)

Screen Size/Resolution

OK, So I was wondering if anyone's got an opinion on what screen size/resolution the site is designed for. I edited Relation:route a few days ago, on a nice widescreen computer and the page looked great. However, when I went back to the square screen of my main desktop the layout of the page was all wrong, with pictures hiding behind each other. I'de assumed the Wiki software would sort this out, but I was wrong. Should we be aiming for a particular resolution, or changing the some of our templates to not use floats?

Martin Renvoize 12:19, 19 January 2010 (UTC)

Plurality VS. Singularity

Although very minor in the grand scheme of things, should nouns that we have pages for be in singular or plural form ?

For example:

• The page for a node is singular: node
• The pages for a way, a tag, a relation, each are plural: ways relations tags

-- User:Skorasaurus 18:25, 9 December 2011

Rules about overcategorization

The page currently advises against "overcategorization" in general, and against explicitly setting "super-categories" in particular. The section was extended a lot by the (now temporarily banned) user Xxzme, but I wonder if there is a consensus against these practices at all. I've seen multiple instances where useful categories were removed for no other reason than being super-categories of another category. While that logic makes sense to a computer, categories should also be useful for human visitors, and removing a page from the super-category causes it to no longer show up there - which is not always a good thing. So imo, this should not be a wiki guideline, but be decided on a case-by-case basis. --Tordanik 16:00, 16 May 2015 (UTC)

Whatever you write here may be used by someone who hasn’t got OSM’s best interests at heart or simply lacks judgement; perhaps we need to remind people that this wiki corresponds to the Wikipedia: namespace and not the article namespace and navigation reflects this. Obviously doing something like putting Europe into a category for each country drowning out every other category is a bad idea but what’s there at the moment really is a solution in search of a problem.--Andrew (talk) 19:38, 16 May 2015 (UTC)

Rules for arbitrary titles

Hi, I am imagining that, as in Wikipedia, there are rules for create arbitrary new pages: a page title must in the correct namespace context. Examples:

• All contents about a country or OSM Chapter are subpages. E.g. Brazil (BR) have as root WikiProject_Brazil, and any Brazilian's project must be a WikiProject_Brazil's subpage (e.g. WikiProject_Brazil/Modelos_de_Contrato).

• All key documentation must be into the key: namespace, e.g. key:wikidata.

• Any personal content or personal's initiative without use or utility for the community, must be an user's subpage.

• etc.

• No one here is "the owner" of the page, except in the case of the user's page or an user's subpage.

So, where the rules?   --Krauss (talk) 16:31, 30 August 2018 (UTC)

For your first item, I'm not sure if there is an existing convention. There are certainly pages that don't follow this naming style, e.g. DE:Verkehrszeichen in Deutschland – "Traffic signs in Germany". Which style should be preferred, and why?

The other topics have probably just not been sufficiently contentious that the creation of written rules was felt necessary. Do people commonly put key documentation pages outside the key namespace, for example? (Not counting newbies, who will not have read through the rules anyway.) --Tordanik 16:12, 13 September 2018 (UTC)