Talk:Proposal process/Archive 1

From OpenStreetMap Wiki
Jump to navigation Jump to search

Tag messiness

Apologies if this isn't the best place to raise a general question. I'll happily move it if there's somewhere more appropriate. I also apologise if it's presumptuous of me to be critical of work done when I'm a consumer rather than a creator.

Looking at all the tags as a prelude to creating a specialised map, I was struck by how many tags there are that make no sense to me at all, how many others are confusing because what the word itself means in OSM is not what it means in the larger world (e.g. "highway"), and how the language granularity/focus varies in irregular and non-intuitive ways (e.g., "junction=roundabout","highway=mini_roundabout", "highway=turning_circle", "junction=circular ).

Although I can solve at least some of the problem for myself by running a filter on the data, I'm wondering whether the language aspects of the tagging system aren't overdue for a general cleanup and regularisation. Niemand (talk) 13:47, 28 March 2017 (UTC)

marine-tagging approved now?

it's 18:2 now. Should be and appropiate number of votes to be approved and let it move to the final-localtion and set as a tagging basement for OSM. What do you think? --Cbm 10:42, 15 August 2010 (BST)


Sign your comments on Proposed features sub-pages?

Perhaps if somebody adds a comment to the subpages here, you should sign them like this- ~~~~? - Bruce89 13:02, 13 Jun 2006 (UTC)

Agreed, if the subpages are to function like talk pages. Wikipedia says sign your posts on talk pages. OSM Wiki is not Wikipedia, but Wikipedia's style guidelines are the result of vast experience of what works best. Teratornis 17:59, 7 Aug 2006 (BST)
  • Another option might be to put the talk-style comments on the talk pages of the sub-pages, while trying to keep the sub-pages proper relatively less chatty, and reflecting the current consensus. For example:
That makes sense, it's just that currently, some of the subpages are treated as talk pages. I think your idea of keeping all discussion to the talk page is best. Bruce89 18:44, 7 Aug 2006 (BST)

Moved page

I've just moved this to use the same name as the now sub pages --Dean Earley 10:46, 4 Jul 2006 (UTC)

Template for sub pages / actually doing something

Perhaps we could have something on each sub-page to show which renderers have actually implemented any given feature Ojw 05:10, 6 Jul 2006 (UTC)

Approved features

What process should we go to to move a feature from "proposed" to "approved"?
Accept votes (Comments/signature on each page) and whichever reaches 5 more then the other first wins? --Dean Earley 23:25, 19 Jul 2006 (BST)

Personally I think if they fit with the current format of Map Features they can be included after a short time here to alow for anyone to comment on duplication or alternatives. I don't see the need for a vote. Blackadder 09:59, 20 Jul 2006 (BST)
I agree, if no one has said a proposed feature is a bad idea, then after a short while it should be transferred to the Map Features page. Dmgroom 11:27, 20 Jul 2006 (BST)
Just move anything older than 2 weeks into Map Features unless there's a load of objections to it? Ojw 20:00, 25 September 2006 (BST)
Proposed features Sandbox--Nickvet419 22:21, 12 June 2008 (UTC)

Ordering

Are the proposed features in any particular order? - most recently at the top for example? --Gwall 10:53, 5 September 2006 (BST)

It started out in chronological order, most recent at the bottom. But this order doesn't seem to have been adhered to. The advantage of having it in date order is that it is relatively easy to identify potential transfers of the oldest to the approved map features page. Dmgroom 11:22, 5 September 2006 (BST)

Procedure to add a new proposed feature

Is it as simple as adding it to this page or is there a discussion before on some other page and someone in charge edits this page ? Pov 14:21, 1 October 2006 (BST)

"send out a request for voting to the mailing list and set the voteStartDate" however it does not state what mailing-list is ment (osm-talk? osm-dev? osm-talk-<country>?). --MarcusWolschon 12:07, 28 November 2007 (UTC)

different signs for different nationalities

If I see an american police sign, I think of a parking lot. Is it possible to do some default sign lists for us, en, de...? Jk 21:25, 23 October 2006 (BST)

The Tables

I feel bad about the column "Rendered as" in the tables of the page. In my oppinion the way how something should be rendered is strongly dependend of the purpose of the map (if rendering a map is the purpos at all). It may also be dependend on cultur, nation etc, see the parking lot issue above.

I suggest to remove this column completely and instead put in a column, that gives a short description of the proposed feature. --Kumakyoo 18:34, 27 April 2007 (BST)

  • I agree. Osm's data shouldn't be built up around 1 renderer, and what something renders like misses the point. What's inportant is what the tag covers and what the key/value is, and how it fits in with other tags. Ben 03:15, 28 April 2007 (BST)
  • I also agree. --Hawke 22:11, 5 August 2008 (UTC)

Cleaning Up this Page, and Making this work more like a wiki

I think that unless there are objections, or a proposal is still in an active discussion, then everything should be added to the features page. We shouldn't really be voting on everything, but just discussing it. At least if things are put onto the map features page, then they will be noticed and can be removed when valid reasons are made. So on the 21st of June, I propose that this page should have a mass filtering. Anything else, should sit here for a week/fortnight and then the same. Objections? (Some things should be shifted right away really)Ben 23:04, 7 June 2007 (BST)

  • The content of text should not be changed generally. Please respect, the OSM project is not only a dictionary. This is also a software project. Descriptions are free, but determinations with influence to the software are to be discussed. This concerns, for example, the acceptance for keys and names. OnTour 21:56, 11 July 2007 (BST)
  • OSM is mapdata. Its not a dictionary, and its not a softwear project. Acceptance isn't the same as a vote. The only softwere effected by changing tags is the rendering and that is not what OSM is. OSM is the data. Renderer's render. Renderer's should not dictate how people tag. Please try to be more constructive, and less aggressive when replying in the future. Ben 00:30, 12 July 2007 (BST)

How to suggest something?

I wonder how I am supposed to tag a Kindergarten/Playschool/Nursery/daycare? Balu 02:52, 16 September 2007 (BST)

  • I've been tagging them amenity=preschool in the absence of other suggestions/proposals/standards but it would be nice if someone proposed something and got it approved. Karora 08:49, 31 December 2007 (UTC)

It's clear that many visitors with features to suggest don't know the procedure or don't want to follow it (I for one don't want to participate on a mailing list). Perhaps we could have an area on this page or maybe on the Proposed features page where people can just plain suggest a feature. Other folks, who care, can enter it in the right place or start a discussion on the mailing list (if it tickles their fancy). I got to this point because I want to know how to code red-light cameras, speed cameras, and radar traps. I suppose I could use the hazard tag, but a standard method would be more useful. Muir

  • Yeah. The mailing list is kind of daunting. It seems to get a zillion messages a day, but if I want to cut to the chase and discuss a new feature I feel it will be lost in the noise. Meanwhile the wiki has perfectly adequate features around watchlists and discussion pages that don't require me to parse all that noise just to hear the one conversation that I am interested in. Karora 10:39, 4 January 2008 (UTC)
  • I think Catagories can do good use for this. We can wor this into the template page somehow to add the correct catagory via the status of the proposal. Also see Proposal Page test --Nickvet419 07:28, 14 June 2008 (UTC)

Using a template to populate the proposal page

  • I think this is a good idea for people making proposals to use a template on their page that would populate the proposal page, if that can be done. --Nickvet419 22:23, 12 June 2008 (UTC)

Template:Proposal_Page

Proposal Page test --Nickvet419 00:18, 13 June 2008 (UTC)

Auto-generate table of proposed features

What appears to be needed is a way to autogenerate the various tables. Has anyone investigated whether Mediawiki supports this? The table should be generated from pages that include Template:Proposal Page, or from all pages in a category, such as Category:Proposals with "Proposed" status. So far, I haven't found a way to do this. Anyone? Robx 11:45, 14 July 2008 (UTC)

I don't know how to do this in unmodified wiki, but there is a nice extension Semantic MediaWiki which can be used for that. --Jttt 20:04, 14 July 2008 (UTC)
That looks great, thanks! I'll look into whether it's a possiblity for this wiki. Robx 11:12, 15 July 2008 (UTC)
Some related discussion at User_talk:Harry_Wood#Semantic_Mediawiki. Robx 16:26, 6 August 2008 (UTC)

We now have a prototype for the OSM wiki with semantic extensions up and running. It demonstrates how tables of map features can be generated using Semantic MediaWiki. Gubaer 19:59, 3 February 2009 (UTC)

Page format change?

Why was the page and proccess changed? This was not dicussed and will be reverted. —Preceding unsigned comment added by Nickvet419 (talk • contribs) 01:40, 1 November 2008

Why the change was needed:
  • It was hard to find the current events (Therefore current votes got too less attention)
  • that is what the talk request is for, and I do have a system in place for that already as a catagory, this can easily be taken care of. --Nickvet419 05:19, 1 November 2008 (UTC)
  • The list was full of abandoned and invalid entries (They are still not moved to Rejected_features but the site is usable now)
  • I agree that they should be moved.--Nickvet419 05:19, 1 November 2008 (UTC)
  • The categories was questionable (They are still, but it does not matter if sorted by status)
  • They were set up to match the feature page for the ease to find and propose--Nickvet419 05:19, 1 November 2008 (UTC)
  • With "Category" as part of the table you can still sort by that, but default to the more useful sort-by-status-and-date (So nothing is lost)
  • Where did tagging go???--Nickvet419 05:19, 1 November 2008 (UTC)
--Phobie 04:43, 1 November 2008 (UTC)


It is OK to do major changes on a Wiki, but it is not OK to do major reverts without prior discussion (unless it is vandalism)! Your revert to 15:48, 30 October 2008 must be considered as vandalism, because you also deleted all other changes not only the change of the categories (i.e. deleted Proposed_features/aeroway_obstacle or the changes by User:Frederik_Ramm)! I will revert your revert for now. If we (the OSM-users) find a consents about sorting by Category and not by Status, I'll accept that if no other changes get lost! --Phobie 04:43, 1 November 2008 (UTC)
  • yes I am a vandalizor and I mean no good to the project... I am kidding of course, Things should be dicussed befor a major edit and posted to the proper talk page. That is edicate--Nickvet419 05:19, 1 November 2008 (UTC)
  • and yes I saw the other changes and would add them back in. --Nickvet419 05:25, 1 November 2008 (UTC)


What is better with the old sorting (many categories)? --Phobie 04:43, 1 November 2008 (UTC)
  • They were set up to match the feature page for the ease to find and propose--Nickvet419 05:19, 1 November 2008 (UTC)
Why do you revert first and than sent me an email asking for my intentions? --Phobie 04:43, 1 November 2008 (UTC)
  • I did ask first.--Nickvet419 05:19, 1 November 2008 (UTC)
Like told via email before: I asked on the IRC-Channel #osm before doing that big change and there were no objections. And no, I can not send a link to that discussion! irc://chat.freenode.net/#osm --Phobie 04:43, 1 November 2008 (UTC)
I sent you another email stating why. I was the one who set up the current proccess and I know all the interlinkings with the templats and catagories. I am willing to help and discuss this with you. --Nickvet419 04:50, 1 November 2008 (UTC)

We finished that discussion via email and IRC-chat... The only thing left is about sorting entries by category or by date. --Phobie 02:08, 7 November 2008 (UTC)


Sorting by category or by status and date

Nickvet419 implemented the structure of Map Features on Proposed features. While I think that is good for Map Features, sites like Proposed features and Rejected features should be sorted by status and date! Please have a look at [1] and [2] and write down your opinion! --Phobie 02:08, 7 November 2008 (UTC)

  • The reason I categorized the proposals is so it mimicked the Map Features page. I think this allows users to easily locate add a new proposals. I also made the tables storable to easily sort the tables. The problem with seporating tables by status and date is it is not as simple to locate a proposal. Also, without an auto list filler the users would have to manually move the proposal from list to list during the proposal process. It is hard enough to get them to update the status let alone move the listings.--Nickvet419 06:11, 7 November 2008 (UTC)
Well, sorting by status and date is interresting for people trying to clean-up the existing list of proposals, where sorting by category is interresting for people who wants to find if their new idea has already been proposed by somebody else. I think that the majority of the people looking this page are in the second case, meaning that, imho, the current sorting is good enough (although we must be thankful to contributors who try to clean-up the list). -- Pieren 09:39, 7 November 2008 (UTC)
+1 --Cartinus 22:11, 7 November 2008 (UTC)
The biggest problem we have is people not updating the status, and not updating the list. This leads to a long list of unfinished and abandoned proposals. Once we get autofill lists, I think the process will be much easier to maintain.--Nickvet419 13:07, 7 November 2008 (UTC)

Solution

If you want to solve this you do this:

  1. change the proposed featured guidlines
    1. create a new page with proposal
    2. the page should contain
      1. template with categories and dates
      2. categories for status
      3. description

if you want to change the way things are sorted you just change the categories that you have on the pages. There are lots of tools to do mass edits based on categories if you need that. Erik Johansson 14:50, 7 November 2008 (UTC)

Change of the approval process

Take 1 (2008-12)

Recent discussions have shown that the current voting process introduces some problems.

I have some recommendations:

  • remove the vote-end-date, just check every week after the vote-start if the approval condition have been met
  • replace "vote" with "approval", to stop people counting the votes and saying 7:3 can not result into reject
  • every "vote" needs a comment, "votes" without rationale will be removed
  • voting will not be closed after approval, but if there are no new comments on the talk-page for about two weeks

approval conditions:

  • at least 8 votes with valid comments
  • no mayor objections
  • objections are only valid if a better way to go is shown
  • minor objections should result into a new proposal which improves the first one

Why?

  1. Because we have many mappers who do not read the talk-mailing-list and the Proposed features regularly. They only get notice of new features after they joined the Map_features. Those users should have a late chance to write down their objections on the proposal-talk-page.
  2. Because a 2/3 majority should not mean a sure approval. Two or three users with mayor objections should be able to stop a proposal.
  3. Votes without comments are often from user who like to vote but do not understand mapping. Their comments would reveal that. Also comments are useful for later improvements.
  4. Many users write valid objections but do not help to improve.

--Phobie 10:24, 1 December 2008 (UTC)

  • Make all votes open end, would be o.k. I think. Major changes in some categories might inflict on other keys too.
  • I would say every objection vote needs a comment. If people have been drafting the proposal what should they post? I like the proposal or See my contribs on the proposal, or this makes sense? --> Those are not really usefull comments.
  • Who defines what a major objection is? For me the name i.e. mtb:scale or severity:mtb would definitely not be a major objection. While this will be hard to implement into Josm and Potlach or Mkgmap definitly is a major objection while at the same time proposing a way to achieve the goal with easy implementation into Josm and Potlach would be. I think the major focus should be on wheter the goal stated can be achieved wit the proposal or not.
  • Minor objections should be considered but no more. If you read through many talk pages on proposals you will see many objections and changes until a way appropriate to the majority is found.
  • I rather think votes without comments are from people who like to tag things as laid out in the proposal, without understanding something about the rendering and mapping techniques behind the scene. I don't think it would be fair to exclude them from voting however. Maybe they are major map material contributors.
  • People who write objections whithout being able to improve should nevertheless be considered. Some things are simply very difficult. I have for example no idea what we can do with areas that serve different purposes at different times of the year. So I approve the ice_rink proposal, because in wintertime I do want to be able to know where an ice_rink is. In summer there might be a swimmingpool instead, which I too would like to see on the map. I know there is a problem with the proposal. I don't know however how we can best solve this. An implementation would have to be similar to access restrictions with time ranges, but those are very difficult to read in and understand. I cannot be expected that someone spends hours just to find a better way. In my opinion the proposal should nevertheless be approved, but once a good concept for seperation of summer/winter usage has been found it should be replaced. Maybe that solution would be independant of the proposal tag itself. I.e. write valid for time duration, and have a responding check on the renderer for that. Such a responding mechanism should however better be proposed by the authors of the renderer (because they should know better how to implement), than by those people who want to draw in their ice_rink and want to see it on the map too. If in the long run features are not implementable in maps at all, they do serve no big service, as noone will print out a map including all unconsidered tags.
--Extremecarver 11:47, 1 December 2008 (UTC)
  • -
  • There are many useful positive comments! "there is no alternative on how to tag usability of a street", "the tag is already widely used, see tagwatch", "This change will definitely improve the parse-ability of the osm database." Your examples are good ones to show bad comments.
  • It it easy to find out major objections, you just did it with our examples. But if we talk about implementing we should always talk about implementation in general and not about JOSM or Mkgmap. If those special software has special shortcomings it should probably be improved instead of doing database-workarounds!
  • The question is: Did those objections on talk-pages came up before vote-start-date or after? If they came up before the proposal can be improved but after it can only be approved or rejected!
  • Minor objections: You have a problem to recommend a user to start a proposal for his minor objection?
  • Major contributors can always tell you why a tag is useful!
  • Ever dealt with trolls? If difficult things can only be implemented in an average way, that is still better than telling users "We have no best praxis for this, don't tag it or tag it arbitrary". Later you show that you are with me: You approved both features while you have major objections but no better way to do it. This is exactly what I want. You votes "yes", ok, but if you had voted "no" without in alternative, the feature should be approved anyways. In the end you reveal that you are tagging for the renderer! If a tag is not useful for printing on a map, that does not mean it is not useful at all. Think about routing-software and POI searches! The usability of tags varies by usage. I would not delete sac_scale because it will never be rendered on Mapnik.
--Phobie 04:27, 2 December 2008 (UTC)
Well sorry I worded it wrong. It's not about wheter the renderers can display a tag, but wheter the renderers CAN (not will or already do) make use of a tag/key. Sac_scale of course will not be printed on Mapnik, but on hiking maps. It's not about wheter the main renderers will use it, but wheter the main renderers could be adapted to use or display/print it. --Extremecarver 09:50, 2 December 2008 (UTC)
There are not only renderers out there. If a tag is not useful for renderers it can still be useful for POI-searches or routing software. I can only imagine three reasons why a tag should be avoided: 1. copyright issues 2. fast changing data (traffic jam, wlan-hot-spots) 3. no one can use that tag for anything useful --Phobie 10:40, 3 December 2008 (UTC)
Any keys can be added to the map, if rederers decide to show a graphic on the map, that should have nothing to do with this voting proccess.. I think the voting proccess should only be a way for users to decide a standard way of tagging. This way when a tag does make it to the map, they dont have to render 15 diferent kinds of tags. therefore, I also think we should start a new voting/proposal page for map additions or graphics to be displayed on the map.--Nickvet419 08:51, 4 December 2008 (UTC)
In principle yes, any key can be rendered. But there could be keys that are very hard to render. Like someone tagging mtb:scale:uphill=3;mtb:scale:downhill=2 in one line, while renderers as they are working now will only read the first halve, or might drop it completely. Same goes for highway=footway;bicycleway etc.... Using keys like this would need a lot more computer power on the renderer side by having additional controlls. Terefore such a tagging system should not be proposed for use. Another case would be someone tagging: acces:no_access_for_200m instead of putting the nodes properly (this would be practically impossible to display - someone adding a junction and it becomes impossible for the renderer to know to which way it applied). So it should have consequences, if the keys are not implementable. Also Complex Arguments in keys should be avoided if possible.--Extremecarver 15:26, 4 December 2008 (UTC)
So what I think you are trying to get accross here is that there should be a discription page that explains what a good tag looks like and why it should not be complicated for redering purposes. --Nickvet419 14:08, 9 December 2008 (UTC)
Making votes open ended has potential, but the problem is that a key could be approved one week, and then disapproved the next. This would not be good. Even properly approved keys have trouble with troublemakers (see the smoothness debate/edit war)
"stop people ... saying 7:3 can not result into reject": You're saying the vote has to be unanimous? Good luck getting any keys approved like that...
Who gets to decide if an objection comment is "valid"?
Who gets to decide if an objection is "major"?
Who decides that a different way to go is "better"?
I agree with what Extremecarver said regarding objections without suggestions for improvement.
--Hawke 17:26, 1 December 2008 (UTC)
"disapproved next week" - What is bad about that? Currently a new approval could also disapprove an old one. Troublemakers are no problem if they are forced to offer an alternative.
"unanimous" - No, I don't! I only wanted to say that it is a show-stopper if there are three different users with major objections.
"valid" - In most cases this is obvious. If not it should be discussed on the talk-page. And if than there is still doubt it should be considered to be valid!
"major" - See above line!
"better" - I used the wrong word. I meant "alternate"! If the users shows an alternate way, others can comment on that and quickly it will be clear if the alternative is better or worse.
"objections without suggestions" - See above!
--Phobie 04:39, 2 December 2008 (UTC)
  • I think;
  • I dont think there is a need to vote after a key has been approved. I think a vote-end-date should be placed to show when a feature met te voting standards.
  • "replace "vote" with "approval", to stop people counting the votes and saying 7:3 can not result into reject" - I'm no sure what is ment by this... because rejected proposals can be put back though the proccess.
  • "every "vote" needs a comment, "votes" without rationale will be removed" - Every No vote should have a valad argument. Why do you disagree with the proposal? what changes can be made?
Approval conditions...
8/15 approved votes withough major objections or sugested changes.
This goes for approved votes and disaproved votes.
If rejected, proposal can be modified and moved back to a new vote.
--Nickvet419 01:05, 2 December 2008 (UTC)
"I think; I dont think" - Why?
"replace" - The approval process should look less like votes users know from their governments.
"every vote needs a comment" - ok
"approval conditions" - You meant at least 15 votes and a simple majority? Ok! What should we do with proposals which do not get the 15 votes after several months? I think we should lower to at least 8 votes two month after vote-start-date.
--Phobie 04:58, 2 December 2008 (UTC)
If we're going to continue to use approval voting, the threshold had better be set a damn sight higher than 50%. Ideally, we can deprecate the voting thing entirely, or at least make it more clear that the vote does not in and of itself give some kind of mandate. The focus needs to be more on the discussion, since that's where the important information changes hands. Chriscf 09:26, 2 December 2008 (UTC)
We should state that the votes only count in a way that it shows that the majority agrees how the feature should be taged. Not that the tag is invalid or cannot be used. I had stated in the page discription that any tag can be used, and the voting proccess is only to create a standard way of tagging a feature. --Nickvet419 08:58, 4 December 2008 (UTC)
The problem is still that voting tells us nothing other than numbers. It tells us how many people are in favour or against, which isn't a useful measure of anything. Otherwise, you end up in a situation where you get people voting for something without understanding the implications (Proposed features/Smoothness, Proposed features/Status), or voting against something for petty procedural reasons (Proposed features/Bench). Voting might have worked when the project was much smaller, but with the phenomenal growth we have seen in the last year or so it's no longer sustainable. Chriscf 10:42, 10 December 2008 (UTC)

Take 2 (2015-03)

  • It is therefore proposed to change to formulation from from "...8 unanimous approval votes or 15 total votes with a majority approval..." to "...8 or more unanimous approval votes or 10 or more total votes with more than 74 % approval...".

--Kotya (talk) 00:00, 18 March 2015 (UTC)

Drifting from reality

This page seems to be increasingly drifting away from the real official approval process, which is:

  1. Example: you have found a new feature and don't otherwise know how to tag it (i.e. you're not making up tags for the sake of it)
  2. Discussion: deciding how best to tag it if not obvious (may be accomplished by yourself if it is obvious)
  3. Use: having decided how to tag it, tag it

The focus needs to move away from the voting and towards the discussion, and any change to the wiki process needs to reflect this a little more closely. The proposal process needs to be more about mapping, and less about process wanking.

Chriscf 09:49, 3 December 2008 (UTC)

Your simplified process steps do not tackle the problem. These steps are all very well, in fact I would agree that they reflect a real process which people follow when they are getting on with mapping. But this doesn't address the issue of what tags are allowed onto Map Features. That is what the voting process described on this page is all about. That is also what lies at the heart of your recent wiki conflict.
Do we need to have a process about documenting tags on the wiki (and in particular Map Features), or is this "process wanking"? Well I would've thought you of all people would be in favor of preventing all those "idiots" adding things to Map Features. That's what the process is for. Certainly it's a shame that we have to focus a lot of effort on defining processes, but... well it's you who is forcing the issue.
The process could be improved or changed completely. For example it doesn't necessarily need to involve voting, or the idea of "proposals" and "approved" tags at all. Currently this page describes it as 'Proposal Status Process' but in more general terms we need a "Tag Documenting Process" of one form or another
-- Harry Wood 13:58, 3 December 2008 (UTC)
What I'm against is idiots arbitrarily adding tags to Map Features, which is what happened with smoothness. Someone held a vote, ignored the many objectors, and decided that this somehow gave them a mandate to add it to MF in its still broken, without a thought about how it might be mapped in practice. This is why the first step is always "example" - a real scenario. Chriscf 14:21, 3 December 2008 (UTC)
Well it does give them a mandate to add it map features. There's nothing arbitrary about it. They followed the process, such as it is. We do need a documented process for what gets added onto Map Features. The process will involve at some stage giving people the go-ahead / the permission / the mandate, to add a tag onto map features. That is unavoidable. Some mystical "real" process is not going to help us control edits to Map Features. The size of community and the importance of map features, means we have no choice but to follow a documented process.
It has become clear recently that this go-ahead/permission/mandate is coming too soon or too easily, or without sufficient community-wide (outside the wiki) input. Bad tagging ideas have progressed too far, and been allowed onto Map Features. In one way or another the process needs to be changed to fix this.
As many people have already pointed out, edit warring and charging around calling people idiots is not helpful (and not behavior the sysops will tolerate forever I might add). But the point I want to make is, it is also unhelpful to grumble about "process wanking" in one breath while complaining about bad tags on map features in another. We need a process. We have a process. People are following it. If this has allowed a bad tag onto the map features page, then let's work together to change the process.
-- Harry Wood 17:28, 3 December 2008 (UTC)
A process devised by a small number of people which is clearly not supported by the wider community does not give a mandate. Chriscf 17:35, 3 December 2008 (UTC)
[personal comments removed] --Hawke 22:15, 3 December 2008 (UTC)
I agree with Harry on this one. The proccess was set up to help people define a standard tag for a feature. If there is a problem with people adding tags to the main feature page without going though the proccess of discussing and deciding as a whole what the best way to tag a feature is, then we should create an admin team to have controle over the main feature page. their sole focus would be to check the approved feature list for proposals that have passed the approval proccess and add them to the main feature page. problem solved.--Nickvet419 09:08, 4 December 2008 (UTC)
The "process" described here deviates from the three-stepper I've outlined above, which you'll find is the only "official" process we have. The smoothness debacle didn't have a specific feature, the discussion was ignored, and there wasn't and still hasn't been any widespread use of it. Therefore, it has not successfully passed through the official approval process. Chriscf 10:38, 4 December 2008 (UTC)
As I've already told you, your three-stepper does not tackle the problem of a how a tag should become "approved" onto the map features wiki page. While it may be useful as a guideline on how mappers could begin using a tag, it is irrelevant to the issue at hand.
Wiki enthusiasts do need to be very conscious that there is a "wider community". We're talking about people on the mailing list, or people who aren't even looking at that, who are just getting on with the real work of OSM mapping/developing. There is a problem that these people are not getting involved decisions about tags, but it is also a valid point that these people haven't scrutinised the process itself.
However with the process itself those arguments carry less weight. Wiki voting on tags is something which has evolved since the very beginning of the OpenStreetMap project. It's been with us for several years (set up by the people who founded the project in fact) Plenty of time for people to scream "this is rubbish" and change it for something better. That hasn't happened because the fact of the matter is, the process isn't glaringly obviously bad. There is a subtle problem, which has only surfaced recently as the community has grown.
So we can't say the process is "clearly not supported by the wider community". Are you suggesting that some consensus is forming on the mailing list, that we should ditch the process entirely and allow anyone to do what they like with Map Features? I don't see that. It would be more accurate to say "the wider community would like to see some improvements to the process".
-- Harry Wood 11:35, 4 December 2008 (UTC)
A tag becomes "approved" onto Map Features when there is empirical evidence that it works, and people are generally using it correctly. I don't in any way see how this is not relevant to the issue at hand. The very first step is having something concrete to discuss. Those proposing the smoothness tag could not even formulate exactly what it is they were proposing to map in the first place. This single fact alone should have killed it in the womb, but yet we had people that had no idea what they were doing voting in support. Consensus on IRC and the mailing list appears to be that the so-called "process" has been drifting away from reality, and that users have been abusing the proposals process to be prescriptive, instead of descriptive. The support on the mailing lists comes overwhelmingly from those that have been bitter, mostly under the misapprehension that the vote alone somehow means the feature is "approved". Chriscf 12:26, 4 December 2008 (UTC)
OK so perhaps that should be step number 4 in your process: "A tag becomes "approved" onto Map Features when there is empirical evidence that it works, and people are generally using it correctly". That sounds reasonable as a outline principle. I also kind of agree with the idea that wiki tag documentation should be descriptive not prescriptive. I can see that some of the troublesome tagging ideas could be shown to be in violation of that principle.
There's issues around these points, but they could form the basis of a new process, along with several other ideas mentioned on the mailing list. We need to bring the ideas together, and then they need some work to turn them into a draft new process (something which nails exactly who gets to change map features and when)
We could work on this collaboratively so that everyone can feel involved. Now how could we do this?... It's kind of an unfortunate irony that the best tool we have for this kind of thing is the wiki. My instinct is to create a new wiki page and start work on it, but given that the new process should be accepted by the wider community... maybe that's the wrong thing to do.
-- Harry Wood 15:38, 4 December 2008 (UTC)
We should never accept a new approval process base on itself. The solution is : use the old system to accept the new system or else "force it" and that's just somehow a revolution or a coup d'état . I'm totally against the last solution Sletuffe 15:49, 4 December 2008 (UTC)
We don't yet have a process for changing processes! We could write one of those too if it makes you feel better, but I think that's a bit over the top! We're not talking about overthrowing a government here. On the other hand this should obviously be handled with care, which is why I am suggesting we create a draft new process. -- Harry Wood 17:27, 4 December 2008 (UTC)
Okay, our process is for features approval. However, many are using it right now, and before changing it, I would prefere writing a clear proposal and cast for a vote on it about changing our way to approve proposals. Yeah, that would make me feel better ;-) and that would clear this unreadable page of wich we don't know what the next process will look like... About the care, I am totaly pro ! This might be a big change, and a draft sound to me more than reasonnable, it sounds needed Sletuffe 18:00, 4 December 2008 (UTC)
Agreeing with Harry on this one. We don't need a process to change process, because nobody cares. It would be yet another level of needless bureaucracy, and that's only going to turn people off. Chriscf 09:34, 5 December 2008 (UTC)
Another way of putting it is... While looking at changing the existing process, we will be careful and will apply common sense (without documenting a process) We could write a process for changing processes, but then maybe we'd need a process for creating processes for the changing of processes! At some level it is necessary to just reach agreement.
Sletuffe, you suggest "cast for a vote" on the new draft process. That's the instinctive thing to suggest for a wiki community, but never forget that this isn't just a wiki community. In this case it is crucial that our new draft process is accepted by the wider OSM community. It will be difficult to judge that acceptance, but the best way of judging that acceptance will definitely not be to cast a wiki vote. In fact I think that would too easily lead to a perception the new process is the product of the same old over-enthusiastic wiki fiddlers!
I have no problem to ask also for comments and votes on the mailing list, the forum, and wherever related to osm. But I am scared that guys shouting stronger will impose their view. And that the new process just lead to an even worst minority of people deciding. When I read that someone wants to restore a "veto" thing (saying that 50% is far too few). I'm scared we are going to blocking minority. I am in favor, as I said before to "kind of" give the power of decision to people that actualy tag things. And since this is hard, then increase the number of votes needed, but dont go to "if their are 2 objections drop it" or else, I'll have to tag for me only, every one will do that, and some data will be simply unusable or tags will stay poor and badly design, just like tracktype=* is against smoothness=* Sletuffe 18:42, 5 December 2008 (UTC)
Anyway we're getting ahead of ourselves. The first step is to draft a new process (or indeed it may turn out that we can think of a few simple changes to make to the existing process) I'm actually fairly hopeful that we might reach a clear consensus at that stage anyway, but... well we'll see.
-- Harry Wood 10:47, 5 December 2008 (UTC)
(indent reset) The steps described on the content page seem to be bureaucratic, and may well have worked when OSM was a lot smaller than it is, however (as we've seen) there seems to be an awful lot of people voting on the wiki with no idea of what they're doing. The three steps are the starting point - (1) no new tag without a real feature to support it (2) a basic sanity check to make to make sure a tag makes sense (3) some sense that the tag will be easy to use and understand. What we need to do is crystallise these into something that isn't too rigid, and doesn't encourage wasting time on petty legalism. Some people have difficulty with the idea of not needing the form signed in triplicate and stamped in all the right places to get things done properly. Chriscf 17:32, 4 December 2008 (UTC)
[personal comment removed] --Hawke 17:52, 4 December 2008 (UTC)
[personal comment removed] Sletuffe 18:06, 4 December 2008 (UTC)
I feel like we've made progress with yesterday's discussion. The next step is clear (although I'm not sure whether to begin work on drafting a new process on the wiki)
BUT I do still feel that the existing documented process needs to be followed in the interim period until we have made improvements.
Chris has ideas and principles about how tagging should work. Something he describes as the real process. But these are not clearly formulated enough to function as a process governing a wiki page like map features (a wiki page which a large community focuses on, feels passionate about, and has opposing views about). By "clearly formulated" I suppose I could have said "legalistic" or "bureaucratic". It is the nature of the way a wiki community self-governs (where the community is large enough or attempts to contend with opposing viewpoints while still allowing open editing) that you need various sets of carefully spelled out rules. These will inevitably appear "legalistic" or "bureaucratic". We might attempt to cut down on this (in our new process) by no longer allowing open editing thereby giving a few individuals the power to make a more airy-fairy judgment on matters such as "empirical evidence that it works, and people are generally using it correctly"
But in the meantime we have a process in place which allows open editing and therefore has some legalistic/bureaucratic rules and steps, including a step which gives the go-ahead / the permission / the mandate to add a tag onto Map Features. This should be followed and respected until such time as the process is changed/replaced (which may be fairly soon if we can make some progress re the above discussions)
-- Harry Wood 10:47, 5 December 2008 (UTC)
The current process in no way "gives the go-ahead / the permission / the mandate" to add because it does not have the power to do so. It is very clearly described as a means of standardizing tags, not inventing new ones. Chriscf 12:34, 5 December 2008 (UTC)
I'm kind of tired of this discussion, but hey it's the weekend! and I have plans which don't involve repeating myself here, so I'll be back on Monday to see if any other conclusions have been reached. I was also just looking on the mailing list thread, and I'll check there again on Monday too. The email discussion seems to keep flipping back over to specifics of the smoothness tag, which I think is not helpful in trying to resolve this. I mean obviously it would be helpful if everyone came to some happy agreement about that tag, but assuming that isn't going to happen...
I would like a clearer view of how the wider community feels about the existing tag documenting process (our approach for controlling edits of Map Features). If we ask the straightforward question... Should we (A) abandon the existing process and leave people to do what they like on the Map Features page, or (B) follow the existing process while we come up with something better?.... I'm assuming option B would be favored, even amongst those who really don't like the existing process as it is documented here. In that sense I think you don't have support of the wider community.
The trouble is people will voice opinions on other aspects of this multifaceted debate. They will voice their support of your view of smoothness and support your view of the process as well as suggesting alternatives. That may make it look like you have strong support, but do people really support your recent behavior on the wiki? or should the existing process be enforced while we come up with something better?
-- Harry Wood 17:51, 5 December 2008 (UTC)
Those options aren't the only ones open. (A) is a recipe for disaster, and (B) results in more damage being done to Map Features. I prefer "(C) suspend the process indefinitely until it's fixed" which limits the damage and provides some incentive for people to actually fix the process. As for my recent behaviour, I see no problem with reverting vandalism to Map Features, and will continue to do so as long as it continues. Chriscf 12:36, 9 December 2008 (UTC)
It was not vandalism but different 'opinions' and your behaviour unilateraly reverting changes done by many others can be considered as vandalism. -- Pieren 12:47, 9 December 2008 (UTC)
Stripping naked can be considered as pornography. You, and others, were trying to add a whole section to Map Features by force. Chriscf 13:08, 9 December 2008 (UTC)
I did not try. [personal comment removed] Pieren 14:46, 9 December 2008 (UTC)
I do agree that much of the voting process has outlived its useful life. OSM is massively larger than it used to be. When I joined OSM, there were less than 4,500 users in total - with only around 200-250 actually contributing data to the map in any one month. A vote involving 15-20 people did represent quite a large proportion of data contributors. Now, OSM is pushing 80,000 users in total, with a peak of around 7,200 users contributing around August this year. A vote involving 15-20 people is only a very small proportion of those currently contributing. Many recent tags proposed, voted on and "approved" also seem to ignore tags already in use and used by various applications. We didn't have Tagwatch in 2006, but we do now - and we shouldn't ignore it. Personally, I am now of the opinion that Map Features should only display a "core" set of tags - perhaps only those which are supported by one of the main renderers. We can use Tagwatch to see if a certain set of tags are becoming more widely used - and make a judgement as to whether they should be incorporated into Mapnik or Osmarender (and hence onto Map Features). Surface or smoothness tags, whilst it's nice to have this sort of data, are not in my opinion in the same level as e.g. highway=* tags - which describe the basic fundamental data about an object. Richard B 13:14, 5 December 2008 (UTC)

About Smoothness. It seems to be a valid tag, passed voting and was discussed. Although, On the main map feature page, it should not have got its own section. This is where it went wrong. It should be listed in the properties section. It should be listed just as surface is listed. this is why I believe we should elect a team of users to check the approved feature list and have access to add and modify the main feature page. --Nickvet419 13:35, 5 December 2008 (UTC)

Again, you seem to be under the misapprehension that "passed voting" means anything. Chriscf 12:36, 9 December 2008 (UTC)
what it means and what you are missing is that a passed vote shows that a standard way of tagging has been agreed upon by a majority of users. Obviously this voting proccess is open to everyone and everyone has the right to vote. The vote does not mean that this is the only way a feature can be tagged. It also does not mean that the proposed tag cannot be used if the vote fails. Wen a standard tag is agreed upon and yes.. passed with a vote, the tag can then be moved onto the main feature page. Thus, the main feature page is then a record of standard tags that a majority of users agree upon. Thus, making it easier for rederers to creat the map without having to render 15 diferent sets of tags. Do you understand this? although, If someone should happen to put something on the main feature page that has not been discussed, it should be removed until it has been agreed upon. If a key was placed in the wrong section, it should be moved to the correct section. If a new section ie. waterway or cycleway should be desired, this should also have to go though a vote. So, anything else?--Nickvet419 14:24, 9 December 2008 (UTC)
It means nothing of the sort. The voting is irrelevant, the discussion is everything. The outcome of the discussion was that important objections (subjectivity, not intuitive, inconsistent, etc.) were not addressed. The outcome of the vote differed from that of the arguments weighed in the discussion - if in doubt, the vote is secondary. We don't pass bad tags just because people voted for it. No amount of whining can change this. Chriscf 10:30, 10 December 2008 (UTC)
So how do you propose we change the approval proccess? how do we agree on a standard way of tagging a feature? Right now we have it as such. Create a proposal, discuss the proposal, edit the proposal to meet everyones input, Vote to see if see if the majority aggrees on the standard tag, If rejected, continue working on the proposal, if passed, archive proposal, create feature page, and add to main feature page. This proccess should take about 3-4 weeks to complete. Only things I suggest we add is that a passed vote does not have a major argument. We could create a list of major arguments that could cause a vote to not pass until review. Also, I suggest we elect a team to have control over the main feature page that can properly add new standard tags that have passed the proposal proccess. --Nickvet419 12:23, 10 December 2008 (UTC)
Heres an example of a major argument... in the case of Proposed features/Bench there is a major agument that bench=permanent be changed to permanent=yes. This would halt the approved status of this proposal. bench=permanent could simply be removed from the proposal and the proposal could then be set to an approved status. bench=permanent or permanent=yes could then be made into a new proposal, where it could be discussed further.--Nickvet419 12:38, 10 December 2008 (UTC)
"How do we agree on a standard way of tagging a feature?" First we find the feature (in this case, "here is a bench"). Then we look at how to tag it (in this case, someone suggests amenity=bench, with little disagreement). Then we see whether it's working in practice (in this case, there are lots of uses already, none of which are causing any problems). That's it. This is how people have been tagging most new features in this time, and - what do you know - it seems to work. There's nothing wrong with a straw poll, but it's not the be-all-and-end-all. If a proposal is rejected, it should probably be on the basis that the community feels it's not a good idea. Something that is merely a poor implementation of a good idea may well evolve. Rejection should be fatal, so there should be some care in deciding whether something has actually been rejected. Electing a team is yet another unnecessary step of bureaucracy which might well turn us into an online Ordnance Survey, which isn't what we want. Chriscf 15:50, 10 December 2008 (UTC)
in essence, the voting proccess is a straw poll... Just to see if we agree on the finished proposal for a standard tag. Yes, the discussion should be the main focus of the proposal, and tags in use should be brought to the table to check if they work well. The main porpose here is to get everyone one the same page for tagging a feature. This way we don't have 15 different tags for the same feature. A rejected vote says we do not agree and we should continue working on it until we agree. A agreed vote says we agree that this should be the standard way to tag this feature. So we are arguing the same point here, but we need a way to show that we agree that this is a good standard way of tagging. This is why there is a vote. --Nickvet419 14:17, 11 December 2008 (UTC)
Now here is a problem we need to work out in the proccess of proposals. the bench proposal. wee seem to agree on amenity=bench but we do not agree on bench=permanent. If one passes the other passes??? this does not work. I do think for ever tag there should be a poll or vote. that way amenity=bench can be agreed upon sepratly from bench=permanent. The committy would only check to see if the tags are properly being voted on and add them to the main feature page, this way there is no vandalism problems. I am not saying they get overall say if a feature is accepted or rejected. --Nickvet419 14:17, 11 December 2008 (UTC)
"If one passes the other passes???" No, obviously. This proposals process should not be a rubber-stamping exercise. If some bits work and some don't, then we keep only the bits that work. Drop the committee idea - it's not going to fly. Chriscf 10:31, 12 December 2008 (UTC)

Proposal process debate ongoing

There was another big mailing list discussion about this, kicking off with this post by Frederick Ramm. Mostly not terribly constructive, but reinforcing the point that this is a divisive issue.

Ideas of a separate off-wiki web-app to replace wiki approaches, resulted in a wiki page Featurama to discuss them. All very well, but it might just end up being a less flexible platform for the same old debates. Richard put forward some new ideas on how a new technical solution might look, codenamed Tags I Use.

User:Pieren made a very practical suggestion [3] of applying some rewording across the wiki:

  • replace "vote" by "opinion poll"
  • replace "I approve"/"I oppose" by "I like it"/"I don't like it"
  • replace "approved" feature status by "valuable" "recommended"

As I said, it will take quite a few hours of wiki fiddling to swap all mention of "approved" for "recommended" though. Is it worth doing?

I don't think it will solve the problem completely, because people will still see it for what it is, a vote on whether a tagging idea gets to be put on "Map Features", but the rewording might help make people see it as more of a process of gaining community acceptance rather than just winning a vote.

-- Harry Wood 14:41, 2 February 2009 (UTC)

I was trying to figure out how to propose shop=pet and tourism=aquarium and blundered tragically into this morass of a talk page. So, since i'm here, anyway: I find the present categories of rejected/accepted/proposed/draft/whoknowswhatelso features very confusing. That is compounded by e.g. features in the obsolete/rejected category that seem reasonable and have no obvious objections on the page, and by features listed on what i had expected initially was the canonical (as much as such a thing is possible in a wiki) reference (Map_Features) that show up in the obsolete/rejected list (i just removed it: shop=chemist). I'm all in favor of a separate way to manage the proposal process if it simplifies and streamlines the process. I suspect most of the problems with people not updating proposal status is due to the complexity and confusion about how to do so.--Pouletic 15:02, 26 March 2009 (UTC)

It's not that complicated, Your proposal goes through draft->proposed->voting->accepted/rejected. If the problem your proposal tried to solve is solved by something else, it is obsoleted. If there is no interest in your proposal for too long, it's abandoned.
The existing chaos, imo, mainly results from the need to update several pages manually, which clearly should be replaced by automatically generating the tables from the template on the proposal page itself. --Tordanik 15:42, 26 March 2009 (UTC)
    • There are ways of generating tables, but this wiki does not have the addons installed. This is one reason I created the proposal template which automaticly links to a catagory. This way you only need to change the status. I had asked the Wiki admins to install the addon a few times but nothing was ever done so for now we are stuck with at least catagories and the self edit lists as the proposal preview. I also wanted to create a form to fill out that would auto generate a proposal page, But yet another addon that needed to be installed. --Nickvet419 Flag of United States 05:31, 22 October 2010 (BST)

Post-vote clean up process needs extending?

For "changed" tags, should it not mention raising trac tickets for all editors that are using any old variations of a tag (I'm thinking for example of amenity=dentist which had an approved healthcare=dentist as of last month), all renderers who render the old tag, and also getting in touch with one of the many bot authors to go through and replace all of the existing usage of the old one with the new. Oh, and when there's only been just over 15 votes, perhaps contact all the existing mappers who will carry on using what they know? --EdLoach 16:41, 22 September 2009 (UTC)

Yes and no. It is something that would help but it is not exactly part of the proposal process. The proposal process is to simply help mappers come to consensus on how to tag a particular feature for rendering convenience. Propose/discuss/vote/document. Rendering is a totally different process and has its own forums/webpage to do so. bot editing is something that can be suggested, but should not be a standard practice. Here is how I would handle your question... On the accepted feature list page, create a link to a help pages on how to get your feature rendered or what to do if a tag is obsolete, there might be pages already created.--Nickvet419 Flag of United States 05:47, 22 October 2010 (BST)

Time and date based tags

It would be extremely valuable if OpenStreetMap offered a way to attach time and date information to locations. This would mean that OpenStreetMap could replace commercial publications such as Time Out and other listings magazines.

I'm not familiar with OpenStreetMap tagging, but ideally you could put something like this:

amenity=cinema
name=phoenix
film=The Men Who Stare At Goats(length=2.00, times=2009:12:12:19:30, 2009:12:12:21:30, 2009:12:12:23:30)
film=Fantastic Mr. Fox(length=2.00, times=2009:12:13:19:30, 2009:12:13:21:30, 2009:12:13:23:30)

..which would show that 'The Men Who Stare At Goats' is showing on the 12th December 2009 at 7.30pm, 9.30pm and 11.30pm. And 'The Fantastic Mr. Fox' is playing at the same times on the next day.

There is already the 'opening_hours' tag, but it is not suitable. Also, in the above example, I'm not sure you could insert two 'film' tags, since the second would remove the first.

Is anything like this possible?

--Cali 15:15, 7 December 2009 (UTC)

This would be possible, but should not go into the map. Instead this kind of information can be stored in a special cinema database, and be displayed on a layer in addition to the base map. See OpenLayers for examples how to do it. Lulu-Ann
This is WAY too volatile information for OSM. Many services using OSM work with data that is up to a month old and saving the history of such objects would be a nightmare. I think it's okay to store a unique key to a large movie-datase in OSM but NOT the current time-table. --MarcusWolschon 12:24, 8 December 2009 (UTC)
I agree. Sounds like a fun idea, but not a good thing to put into the OpenStreetMap tags. Instead you should run a separate database and simply correlate ids of the amenity=cinema OSM elements. -- Harry Wood 13:11, 8 December 2009 (UTC)


This wouldn't be just for Cinemas, but for:

  • Museums
  • Music venues
  • Art galleries
  • Theatres
  • Nightclubs
  • Sport venues etc.

In other words, anything that would be in a Listings publication.

What people are suggesting is a separate database to OSM, where each OSM location with time/date information has its own records. RealTimeOpenListings maybe? Has anyone else ever tried this? Listings appear to be one of the last things which have not been powered by collaborative 'crowd-sourcing'.

I guess the tag on OSM could be: 

rtol=boolean (yes/no)

..which would let the OSM map-view know that the location has time/date information on RTOL.

--Cali 14:58, 8 December 2009 (UTC)

Different fuel sorts / kinds

We have amenity=fuel. But I think the KIND of fuel that is offered is also important. Things like "Biogas", "Electricity" and others need to be tagged aswell. This sets us apart from Google Maps that doesen't offer that feature at all!

--pr0wl 02:25, 11 January 2010 (UTC)

Take a look at the Tag:amenity=fuel page, which gives a proposed tagging scheme for fuel types (Key:fuel) -- Harry Wood 12:04, 11 January 2010 (UTC)
Thank you :) --pr0wl 02:27, 12 January 2010 (UTC)

Proposed features process: Rejection at draft and proposed

I'm suggesting that an improvement to the process is needed. If a redundant map feature is proposed (in state draft or proposed), then in some cases it should go directly to 'Rejected' state if consensus is achieved. For example if five (5) people fully agree (without objections) that the map feature is redundant, then the map feature goes into 'rejected' state.

This way we are able to clean away "trash" faster. As the map features evolve it will become more and more likely that someone propose something that already exist. --Kslotte 12:19, 11 February 2010 (UTC)

Do this idea get any support? --Kslotte 13:35, 18 February 2010 (UTC)
No, this would work most of the time, but there are features that already have a tag, but there is a better way of tagging. Possibly not the tag itself but also some discriptive tags used in combination. Although it is possible to cancle a proposal if it is reduntant where there are no changes/additions to a tag.--Nickvet419 Flag of United States 05:59, 22 October 2010 (BST)

RFC: Link to mailing list archive in Proposal

Hi,

I would like to see the link to the talk mailing list archive in the proposal. This will help to bring wiki users and mailing list users together in better dialog.

I would like to add: 

Put the link to the RFC-Email in the talk mailing list archive on the proposal page

Maybe we can add it to the proposal template ?

Lulu-Ann

I agree that it would be a good idea to add links to other communication channels to proposal pages.
However, this isn't usually limited to talk ML - while that's the one channel mentioned on Proposed features, it also makes sense to publish a proposal on the forum and maybe international mailing lists, and links to these would be useful, too. Is a template-based solution flexible enough to handle this? I'd expect it would be easier to add a list of links to the usual "Comments"/"Discussion" section of the proposal. --Tordanik 14:04, 16 February 2010 (UTC)
I disagree to have a list of 5-7 places where a proposal is discussed. The discussion must be on the discussion page. I want to add the link to the talk mailing list, because many mailing list users are to stubborn and don't accept that. (Or to stupid to put wiki pages to their watchlist and activate the email notification? I don't know!) I do not want to have even more places where pieces of discussion must be searched for. Note that each place (Wiki, mailing list, forum) usually needs a new login registration. This does not make it easy for new users to find the needed information. Lulu-Ann
I agreed that a link from the wiki to the mailing list archive makes sense. I see that mainly being valuable as a proof that this has been done (and clearly forcing proposers to go through that step). The intention would not be to direct discussion traffic at other channels, but to prove that other channels have been directed at the wiki proposal.
According to the steps outlined at: Proposed features#Proposed, it's the 'tagging' mailing list you're supposed to post to. Are people using that?
Don't really see the harm in linking to a forum post too. Could be good forum enthusiasts picked up on new proposals and made forum posts about them, but the wording of the forum post should be to send people to the wiki to make their comments.
-- Harry Wood 13:24, 17 February 2010 (UTC)

Question about abandoned status

"Any proposals that have a 3 month inactive history should be set to "Abandoned"" - Does this rule apply to all proposals (even the drafts) or only to the ones that are in a "voting" status? --Gwilbor 09:57, 10 March 2010 (UTC)


This applies to all proposals still in the process. This rule was made only to clear up the list so we can focus on active proposals being worked on. If there was a vote done, the status should be changed appropriately, if the vote was inconclusive, a new RFV should be sent out to the mailing list. --Nickvet419 Flag of United States 06:08, 22 October 2010 (BST)

Cleanup Request

Hi, this page has a lot of waste proposals that are no longer maintained. To help the users we should reconsider the layout and parts (e.g. where to add a proposal introducing a new namespace?). To reach this aim we have to discuss the proposal process with the whole community --!i! 15:41, 11 August 2010 (BST):

  • should it be tolerated that non proposed features get added to Map features?
  • should there be a timeout for the single steps within the proposal process, when the proposal gets inactive and archived?
  • should there be a min count of users to make a vote 'valid'?
  • should a proposal allways be rejected for small issues(e.g. amenity key instead of a specialised another one) or can it be corrected immeadidly?
  • what better sollution to prevent conflicts between 2 proposals?
  • should there be a team watching at the whole proposal process?
  • How can we making migration from old to new tagging schemes more easier?
  • can we create templates that simplify the voting? (thumbup/down and a template that counts the ratio and summarizes)
  • can we provide better templates to help the users contributing/thinking on enough details?


I don't think the current voting process can be improved/fixed, it might have once worked when there were less mappers, but both the number of user accounts and active mappers has increased considerably yet fewer people are voting. As for preventing duplicate proposals, why not setup a working group to evaluate proposals, they don't necessarily get final say but they could be used to filter things a little. -- JohnSmith 11:04, 12 August 2010 (BST)


My opinion: Everyone may use their own tags, the wiki is only to find some guidelines. So if a person 'creates' a new tag, he should place it immediatly on the wiki to explain what is meand. I believe it would be best to have no voting when a tag is added. Discussion about the tag should happen at the talk page and there should be a central page to ask the deletion of a tag (e.g. when it's a duplicate or it makes no sense). I think my opinion supports the "wiki is only a guideline" note many give and may lead to a better wiki. Some remarks:
  • if a tag is new, you can add a {{new feature}} template, so all the new tags can be found and improved by wiki workers while mappers can find them and use them (with a little warning).
  • if a tag is still incomplete, add a {{incomplete feature}} template which warns users but says they can use it if they want to.
  • there should be a wiki beginners guide on how to add your own tags.
That's only my opinion, I have this opinion cause if I want to tag something, I always look in the wiki and I sometimes have to use proposed features so to mappers it should not make that big difference if a feature is proposed or accepted (it's a thin line for many tags). Hope you understand it, Sanderd17 11:50, 12 August 2010 (BST)
I lightly agree with you.. All tags used on the map should have a wiki page, if accepted or not. It would be nice if that process could be auto generated and somehow linked within the map editor. The only reason for the proposal process is to come to a consensus on how a feature should be tagged so that renderers don't have to create 100 rendering rules for one feature. It is also nice to have a proposal page to discuss new ideas, and work out all the issues before making a feature/key/tag page. That is also why I made the rule in the post-vote to link back to the proposal page so you can view the debate on why users agreed to tag a feature in that particular way. --Nickvet419 Flag of United States 06:34, 22 October 2010 (BST)
My comments:
  • on Map Features, I expect
    • tags that are widely used by applications and mappers alike, even if they haven't been part of an "accepted" proposal
    • tags that are moderately widely used, but also considered a good idea by many contributors (as demonstrated by, for example, a wiki vote)
  • a proposal shouldn't ever get archived if there is no alternative for tagging that object and there is actual interest in mapping the object (as demonstrated by tagwatch/tagstats). If it has been superseded by an alternative proposal or no one really wants to map that kind of object in the first place, it can be archived after some time.
  • actually, it's more important that there should be a min number of users before a proposal can truly be considered accepted. As for votes, I don't see a reason to change the 8/15 minimum guideline.
  • corrections to a proposal or similar shortcuts to avoid unnecessary bureaucratic efforts are fine if people agree that they are. Use common sense, no need to write this down.
  • talk with each other. In most situations, there shouldn't be any irresolvable conflicts. If you really cannot find consensus, wait some time and see which method of tagging becomes more popular.
  • Don't see a reason for setting up that kind of team, unless you want to . Which leads to ...
  • making migration easy would require some authority to define that tagging A is now "wrong" tagging B is "right". So, unless you can convince people to accept someone's authority in this matter, migration will always be a slow process.
    if there would be a tool to change tags from one word to another (for complete duplicate tags), migration should go faster. Off cource that tool would only be availiable for senior members (1+ years or so and active in the past weeks). This would help with semi-duplicate tags (like highway=minor).--Sanderd17 17:08, 23 August 2010 (BST)
  • Voting is easy enough, imo.
  • Don't see a problem with current templates. Some may be a bit too restrictive (because they don't hide fields that have not been used and those fields are not appropriate for all proposals).
--Tordanik 20:08, 12 August 2010 (BST)


On Mailinglists there was the idea for a Feature garage to act as some kind of incubator for feature ideas/documentation that doesn't want a vote. Might this assist the process? --!i! 19:33, 19 August 2010 (BST)
IMO we need to distinguish between tags that have been formally approved in some way, whether here on the wiki, in a mailing list discussion, from tags that have been documented from personal use or from wide use. The {{No proposal}} is one step in that direction, though maybe we should allow links to discussions be more visible also. IMO it is irrelevant how a tag have been created, as long as it is documented properly. It might be enough to make a note such as Not formally proposed, but is a logical tag similar to xxx=yyy. A well documented tag is more likely to be of wide use than a poorly documented tag, even if it is approved by wiki vote. --Skippern 16:41, 28 August 2010 (BST)
More visible Links would be a briliant idea, can we extend the proposal/feature templates for that? --!i! 20:16, 28 August 2010 (BST)

I don't know how many of these there are on the page, but if I click, for example, on the proposed feature shop=beauty, it redirects to a feature page for this tag. I am guessing it has been approved. Should I then take it upon myself to remove it from the Proposed features, or will someone else do that, or are proposals meant to stay forever on the page for reference? --ponzu 11:41, 15 February 2011 (PST)

As written at paragraphe below, the most of us decided not to work on any tagging related pages for now, cause there is a poisoned feeling in the community. We will proceed on the things at Wikiproject Cleanup and if we succeed with this one, I guess than there is a better ground to work on the tagging topic again --!i! This user is member of the wiki team of OSM 21:20, 15 February 2011 (UTC)

Features that hasn't gone through the proposal process

It exist several map features that hasn't gone through the proposal process and their usage is minor. Here are a few: Tag:shop=copyshop, Tag:shop=erotic, Tag:shop=dive, Tag:shop=furnace, Tag:shop=deli, Tag:shop=mobile phone, Tag:shop=bed, Tag:shop=variety store, Tag:emergency=fire extinguisher, Key:office, Tag:shop=musical instrument, Tag:shop=frame, Tag:shop=funeral directors, Tag:shop=hearing aids, Tag:highway=give_way.

What should we do with these? A "no proposal" template has been placed on these, but has been reverted (several times) without reasons by user JohnSmith. --Kslotte 15:19, 28 August 2010 (BST)

Personaly I think some are ok and "simple" enough to not to provoke conflicts e.g. shop=erotic. Others are to specific in my opinion and need a review for a more abstract design e.g. shop=frame. But it's not on me to decide this but on the community.

Therefore I'd like to initiate the improvement of the proposal process (see topic above). --!i! 15:59, 28 August 2010 (BST)

JohnSmith is just a troublemaker. He does what he want without any respect to others, undoing/moving pages without general consensus etc. Don't rely on his edits. --Scai 16:21, 28 August 2010 (BST)
Might be or not, I think a wiki is living if everybody can go on to improve it. Neverthelless I wouldn't call this behavior gentle...and in the end all is basing on the respect of others work. --!i! 20:12, 28 August 2010 (BST)
I tried to relabeled the items but it got reverted from John and he point's out that he will revert it again cause it's some kind of defacing to him. If we doesn't like his approaches we can make better ideas cause this documented tags were already discussed on tagging mailing list --!i! 07:02, 29 August 2010 (BST)
In case you guys missed it, proposals are supposed to be made and then go through the tagging list, you guys can't just pick and choose rules to honour just to suit yourselves, and then whine about others doing the same... --JohnSmith 07:20, 29 August 2010 (BST)
It's not on us John. We try to get a better concept for the Map features list. We try to understand your point...but actually you don't say why it is wrong to label your pages :(
OSM is no kind of battlefield or a place to propagate just one single point of view (wether our neither yours) but this becomes offtopic... --!i! 09:02, 29 August 2010 (BST)
There should be nothing wrong with having any new tag described at Tag:key=value (or Key:key). Even if it's an obvious mistake - in other words, it's used only few times at most, or by a single contributor, and there is a more widely used alternative - it ought to be linked to the "better" tag and the reason documented. When there isn't a better/recognized tag and no proposal exists, wouldn't a category suffice? Category:Unproposed features and Category:Features accepted by use (a better word?)
Personally, I find the template box too prominent; it's not a problem with the tag description page, but rather a problem with the Map features template for that key if it includes values that aren't yet popular. Only the tags that have gone through the proposal process might be added without (yet) being used that much. - Alv 15:08, 29 August 2010 (BST)
Ok if "to prominent" is what John means with "defacing" then we could use an own Category of course instead of using this template. --!i! 15:43, 29 August 2010 (BST)
Hey everyone... I saw this new template pop up. A no proposal template on a page gives false pretenses that every tag has to go though a proposal process which is not correct. Standard practices suggest you make a proposal before creating a feature page, but a proposal is not needed. Every tag being used on the map should have a wiki page to describe how it is being used. It just helps to get a consensus on how a feature should be tagged, not how it is being already tagged. The process also gives users a forum to discuss and argue the best way to tag a feature without cluttering the feature page itself. I would recommend using a category instead of a template to document features that did not go though a proposal process. Any tag that did go though the process should have a link back to the proposal so users can see why it is the best tagging practice.--Nickvet419 Flag of United States 07:01, 22 October 2010 (BST)
I got kind of burned out with these process discussions about a year ago. Back then there was particularly a lot of backlash against the idea of voting on tags, and that seems to have led to people giving up on following processes altogether. The thing to remember is that there will always be a lot of people who don't like rules and processes. And then there's also a lot of people who are forthrightly opinionated but in a very unhelpful self-contradictory way. On the one hand they complain that the tags documentation is sucky and people are adding stupid tags all the time, and then almost in the same breath they complain that they don't want stupid tag proposal processes. They seem to fail to take a step back and realise the self-contradiction. Essentially it's just lots of people of who find it easy to complain about things, but hard work to actually help improve the tag documentation
So these days the suggestion seems to be that people are welcome to add new tag documentation (a new page with 'Tag:' prefix) without creating a proposal. Alv and Nickvet419 have said that here, but I know that this is also reflecting the current thinking of a lot of the community.
I don't understand it though. How does that help us raise the standard of tag documentation?
-- Harry Wood 01:34, 24 October 2010 (BST)
Hey Harry Wood, I also got burned out for similar reasons. I spent a lot of time trying to streamline the proposal process to help make it simple, more fun, and actually constructive. To answer your question... The proposal process as you know is to, yes, raise the standards of tag documentation, and to get a consensus among users on the best practices to tag a specific feature. There are still some technical faults with the "process". Not everyone knows Wiki, so it can be difficult to create a proposal and get it listed. Although clearly listed, there are still multiple steps you need to do to create a proposal, discuss it, get it voted on, and even then you may have to start over from scratch. The length it take to create a proposal to the time it gets accepted, you could probably tag 1000 features or more. So therefore if a tag seems appropriate to some one and they don't know how, or want to spend the extra time, they will simply skip the proposal process altogether.
On the other hand we want every tag to be documented in some way, preferably in a standard format, and in a way the majority can agree on. If a tag is used, we want to know why and how it was used and if wee should use it in the same way. Therefor the proposal process is not a mandatory step in creating a new tag, but recommended to be able to get community input and approval. The Proposal process is a great way to get that done, because it gives that forum to discuss that feature and work out the errors before it goes into the mainstream.
So here is what I recommend we do. For now, Leave the Proposal process as is. It is doing what it is intended for "Helping create higher standard of feature pages, quality tags, and a forum to fully discuss the best practice to tag a specific feature." We need a new page to clarify what to do when creating a new tag/key/relation. What is needed when documenting a new tag? What are other steps you can take to improve the quality of the tag? Ex. Put the tag though the proposal process.
In addition, instead of "marking" what tags have not gone though the proposal process, Let create a template that shows a tag did go though the process and that the community has agreed on a standard tag for that particular feature. We can call it "Blue Ribbon features". This way, when someone is searching the wiki for a tag, and sees the "blue ribbon" They know that the community agrees that it is a standard practice though the proposal process. Unless not already on the approved feature list, or part of the drop-down in the map editor, all new features/tags need to go though the process to receive the blue ribbon. --Nickvet419 Flag of United States 04:21, 24 October 2010 (BST)

Blue Ribbon Features

Started in the last topic, I have proposed a new way of marking features that have gone though and accepted in the proposal process. It is called, Blue Ribbon features. This is intended to be a template to be placed on accepted feature pages. The main focus of the blue ribbon is to show that the community has discussed and agreed how to tag a spicific feature on OSM. Since all tags should be documented on how and why they are beaing used, this wil be a way to promote the proposal process. This will not only help get users to document their new tags, but also put them though the proposal process so that the communnity can best decide the standard and best way to tag a spacific feature. Features to be included:

  • All accepted proposal features.
  • All features listed on the Map Features page.
  • All features currently on the drop-down list in the map editor.

--Nickvet419 Flag of United States 05:06, 24 October 2010 (BST)

I like the idea. But we should set a few requirements to get this flag? I had the opposite approach with Template:No proposal that failed. I guess it's a better way to say that people doing a good job (like with Awards) instead of telling they are doing something wrong....
So what does you say, is it focused on widespread features that are well known in any kind and supported by the editors presets? Or is the focus that they had been proposed? A lot of old stuff didn't run through the formal process :/ --!i! This user is member of the wiki team of OSM 17:51, 6 November 2010 (UTC)
The main focus would be a way to mark the well documented and widely used features/tags. We also want to promote the proposal process as a way to get that quality assurance by the user community. So, I would say to start out with the widely used tags that are on the map features page and the tages used in the main editor. Then move onto the successful proposals. A big problem between the map editor and the Wiki, is that not all tags have a wiki page to document them. When I see a tag dog=maybe on the editor, I'd like to know why it is there, what does it mean. The "Blue Ribbon" tells me this tag is widely used and accepted by the community. That the tag was not just randomly created, but also deemed the best way to tag this feature. --Nickvet419 Flag of United StatesThis user is member of the wiki team of OSM 19:24, 6 November 2010 (UTC)
I agree with you. But you have to keep in mind that the current proposal process is dammed. A lot of people abandon it, because they say a vote of 10 people is nothing. I agree at this problem but there has to be a improvement but I have no idea how. Did you already got feedback on the talk and/or tagging mailing list? --!i! This user is member of the wiki team of OSM 20:35, 6 November 2010 (UTC)
no real feedback besides people saying they like the idea. I think everyone agrees that the voting part of the proposal process is flawed, but the process itself is beneficial to creating good documentation, creating tags that work well with others, and getting support from the community to use the tag as mainstream. The vote part says (yes/no) that the tag meets these criteria and that the tag is a good/safe tag to use, the best way to tag a feature. If we could simply change the terminology to reflect that, it would be much better than to dismiss the proposal process. Because the proposal process is such a useful tool to help meet "Blue Ribbon" standards, I think it should be part of marking features with the blue ribbon. Features already on the main feature list mostly already meet the standards of good documentation and acceptance by the user community, so they do not need to go though the proposal process.--Nickvet419 Flag of United StatesThis user is member of the wiki team of OSM 21:03, 6 November 2010 (UTC)

Change Voting terminology

I think everyone somewhat agrees there are issues with the "Voting" section of the proposal process. Because of this I think there is a need to change the terminology "Voting" "Yes" "No" "majority" to something else. The purpose of voting is simply this... To agree that the tag/feature is well defined, there are no conflicts with other tags, the proposal process is complete, and the feature/tag can be pushed into the mainstream with complete documentation. If we can find better terminology to support this instead of the ones currently used and argued about that would be great. Any suggestions?--Nickvet419 Flag of United StatesThis user is member of the wiki team of OSM 21:14, 6 November 2010 (UTC)

I do not agree to your view. Your requirements are not sufficient. You are missing "The proposed tag is the best solution for all current and future usecases, it is sustainable." and "It is correct spelling" and "It is easy to remember also for non native speakers" and "It will not cause any inconsistencies." and "It is the easiest way to install all aquired advantages from this proposal" and "It is not foreseen that the proposed tagging will have to be changed manually when more OSM detail data is stored in the future.". And, give me some time, I will find more requirements for a optimal proposal. Often I vote no because only one of these requirements is not met. We don't want any working data model, we want the optimal one. --Lulu-Ann 13:29, 16 November 2010 (UTC)
Well I guess we all agree that we can*t get an optimal solution just within one single step. But we can get one on a evolution. But this evolution should be managed or assisted in a good way, right? --!i! This user is member of the wiki team of OSM 13:57, 16 November 2010 (UTC)
Sorry, I disagree again. I am a database developer. My customers would not give me work again if I would not be able to find the optimal solution in one step (including long discussions). Taking several steps always means doing many manual changes to data, which is a hazard. What's wrong with doing it right? --Lulu-Ann 14:26, 16 November 2010 (UTC)

Tagging of fruit trees and edible plants

Hi there, I have a great vision of a new category or key in OpenStreetMaps: A key for edible and wild growing plants and fruits that are available for free. This would be an equivalent to an existing project based on- but not yet integrated into osm. This is the project i'm inspired by and whose functionality i would love to fully integrate into osm:

http://mundraub.org/map

With this project, you can tag and find fruit trees, mushroom places, nut trees and herbs which are growing at a certain place and which can be taken for free. I suggest this, because I find it extremely useful especially for backpackers and hikers travelling in a foreign country. With the key "edible" (or anything this way) people would be able to find points where they can access food for free. In my homecountry Germany and for sure everywhere in the world, trees are growing and produce tons and tons of fruits that end up unused and rotten. Maybe this project- this vision- this feature- will might make the world a slightly better place. =) What do you think? In my opinion, this should be a new key "edible" despite the existence of "natural". Justification: the value "tree" in key=natural is insufficiant. Also, it would be great to filter the "edible" POIs in apps like Osmand immediately. Last but not least, something important like food and other (free!) edibles deserve an important place in the osm project. --Ghostrider111 21 November 2014

Hi and welcome to OSM! I think you are at the wrong place here. Please see Proposal process and create a proposal page where discussion about it can take place. However, it seems you are in an very early stage, I guess a post to our forum (if you like, there is also "Germany") may be the best to discuss and develop your idea. --Aseerel4c26 (talk) 02:41, 21 November 2014 (UTC)
Thanks for your reply. I continued an ongoing discussion in the forum. If the community agrees, I will initiate a new proposal page. I'm excited what's going to happen with this vision. --Ghostrider111 21 November 2014
Okay, I would suggest to continue the discussion there before you continue here. --Aseerel4c26 (talk) 13:33, 21 November 2014 (UTC)

Proposal page should encourage proper namespace usage

When someone is going to propose not a single tag, but the whole tagging scheme, as in case of ongoing Pipeline tagging proposal, it's really important to encourage people to use namespaces. It's also very important to use namespaces properly, instead of using it just as prefix for some of keys. I can try to compose short text about it and place it on this page, because, as I know, there is no place on Wiki, where it is explained somehow. --BushmanK (talk) 08:10, 13 December 2014 (UTC)

Please promote wiki pages instead of Taginfo for popular values

We should discourage not-English speaking world from Taginfo (and from using dictionaries and especially google translate as result of our recommendation), we should promote OSM wiki over "just watch taginfo"

Irrelevant to proposal process, but relevant for pages at wiki in languages other than English.

There is a lot of problems outside En community when it comes to OSM guideline "just watch taginfo for popular values". This works more or less for EN community, but users outside English-speaking world, do not get meaning correctly. I do Russian translation at wiki\ID\communicate with ru communite and many ru users do no realize that reading by letters in taginfo doesn't work without meaning of the word. Absurd, but it not written anywhere, instead we (English speaking world) promote "just watch taginfo". This is serious issue outside GB, USA, Canada, Australia. We have way more countries. Even more if we want to grow.

  1. Promote OSM wiki over taginfo across all non-english languages. Possibly it should be written as notice at main page or every single guide/content should be rewritten.
  2. Not Taginfo fault. Just add feature to Taginfo to directly show wiki-translated page based on "Accept-Language" header. Force this behavior by default for not-English languages. Yes, force displaying wiki pages parallel to tags, but let users switch language (and disable this feature).
  3. Everything for English-speaking world stays the same, since this is main language/tagging convention. Xxzme (talk) 00:53, 11 November 2014 (UTC)

Deprecated label

I created a draft of a deprecation label. It should support the display of deprecated features in parallel from the infobox. Please comment and help here: Talk:WikiProject_Cleanup#.22Deprecated.22_label

Above was me... The label is ready for use! Template:Deprecated feature--Jojo4u (talk) 20:43, 2 August 2015 (UTC)

Resurrecting abandoned proposals?

If a proposal is abandoned, is there any way it might be brought back to attention or taken over by someone else? Or should a new, similar proposal be made by a new person? In particular I have the expressway indication proposal in mind, which I think would be a valuable addition to OSM for U.S. mapping to make it unambiguous whether a trunk road is a true expressway or simply a highly important road. While the person who proposed it is still an active editor of OSM, the proposal has not been touched in over six years, aside from being marked abandoned four years ago. Is there really anything that can be done about this? (EDIT: Spellign)

--Roadsguy (talk) 16:29, 22 December 2016 (UTC)


there's no hard limit, the same person could in theory propose the almost same proposal as often as the others can bear with it ;-), although the general idea of the proposal process is to improve the definition by discussing it with others. In this particular case this is one of the hundreds of proposals a newbie set to abandoned in 2012. As this tag is already in use I have reverted the edit, so now the status is again "proposed", but you can consider changing this to "de facto" (maybe ask on the tagging mailing list before doing it). --Dieterdreist (talk) 20:07, 22 December 2016 (UTC)

Since the tag is already used fairly frequently, should I also suggest in the mailing list that I flesh out the expressway=* page itself in addition to marking it de facto, or should we only have the proposal page? --Roadsguy (talk) 20:29, 22 December 2016 (UTC)

IMHO you can add as much as you can to the tag-page, as long as the people who have applied the expressway tag agree with it (what might not be easy to find out practically), i.e. it is desirable to have a definition there, but it should likely start with what the proposal says, because that's the basis for the tag. Please also keep a link to the proposal. --Dieterdreist (talk) 21:21, 22 December 2016 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Proposal_process/Archive_1&oldid=2330665"