Talk:Proposal process/Archive 2

Verifiability Section

I've added a new section on Verifiability as a subheading for "Before Creating a Proposal", to go along with "Existing Tags" and "Significance."

This was occasioned by a couple of my proposals being rejected due to verifiability-related issues. This is clearly an important issue for people to know about before making a proposal, but it wasn't mentioned in the proposal process page.

I've linked to the Features page and Verifiability page, and provided quotes and examples taken from each that show what sort of new tags and features are not likely to be accepted, eg: "Tags that are probably not verifiable include:

• "Statistical properties, e.g.: peak vehicles per hour on a road, average discharge rate of a river.
• "Subjective opinions, e.g.: reviews, rankings
• "Features that no longer exist or do not yet exist, e.g: borders of ancient empires, speculative future developments"

--Jeisenbe (talk) 04:48, 9 April 2019 (UTC)

Thanks, but linking and naming relevant ideas from Good practice might be a better idea? --Tigerfell  (Let's talk) 09:12, 9 April 2019 (UTC)

Some other good practices that might be relevant for proposals: Not mapping historic events/features, not mapping temporary events/features, and not mapping "insignificant, perishable and mobile objects". The syntactic conventions for new tags could also be worth linking. --Tordanik 18:22, 16 April 2019 (UTC)

@Tordanik: That is exactly what I am talking about. I would propose to shorten this section and make it more general. --Tigerfell  (Let's talk) 09:13, 17 April 2019 (UTC)

 updated Hope I did not miss anything! --Tigerfell  (Let's talk) 12:48, 31 May 2019 (UTC)

@Tigerfell:, thanks for updating this! One suggestion, though: I would not list the Tagging for the renderer rule here. As that page explains, this principle really means "Don't deliberately enter data incorrectly for the renderer." Maybe there ought to also be a "design tags to be multi-purpose, do not define tags that only a single software can realistically use" rule, but that's not what "tagging for the renderer" means as far as I can tell. --Tordanik 18:09, 10 June 2019 (UTC)

Okay, that was maybe a bit of interpretation there. I guess this point is covered by Any tags you like already anyway. --Tigerfell  (Let's talk) 13:32, 11 June 2019 (UTC)

Opening Voting On Someone Else's Proposal?

Hi, this four-and-a-half year proposal was created by someone who has not made an edit since 2013, and there exists no OpenStreetMap user by their name. Would it be permissible to open voting on their behalf, seeing as over four years is a considerably ample time for discussion to be open? --RathcooleRambler (talk) 20:25, 21 May 2019 (UTC)

it would be better to first write a message on the discussion page asking him if he wants to continue his proposal or if you can resume it (he should receive an email notification of your change to the talk page). if he doesn't respond within a reasonable time, you can resume the proposal on your behalf. it would probably be useful to do again a rfc before the vote Marc marc (talk) 20:41, 21 May 2019 (UTC)

It would be nice to ask, even in case of completely inactive users. Given long time it is a good idea to do RfC again Mateusz Konieczny (talk) 15:09, 22 May 2019 (UTC)

Clarify whatever explicit abstaining is the same as no vote

extracted to Proposed features/Clarify meaning of abstain votes

Changes after the installation of Wikibase

Do we need to change the process to include Wikibase? --Tigerfell  (Let's talk) 09:44, 27 October 2018 (UTC)

Once I finish the rewrite (and publish) my data item bot (yurikbot), the process of creating new data items will be automated. So as long as the proposal contains a {{KeyDescription}}/{{ValueDescription}}, a corresponding data item will be created too. Even if the proposal is rejected, data item should still remain with the appropriate status for documentation and historical purposes. Eventually I do hope we have a simple form to fill out to create new data items - something that will automate data item validation and creation. Should be fairly easy to do, similar to the plethora of Wikidata tools. The form would create a data item and a simple wiki stub page, but there is no point of changing the process until that is done.

Minor technical heads up: There is currently an annoyance that I hope to fix - when wiki page named as "Key:..." or "Tag:..." is renamed, corresponding data item's sitelink is also changed even though it shouldn't. Bot should fix that once ready.

"Wikibase" seems to be a bit confusing to many people, and implies wikidata in some weird way. I propose we call them "data items" or "data pages" to signify that it is a generic page with data describing key/tag/feature/...

--Yurik (talk) 16:22, 9 December 2018 (UTC)

I see multiple issues with placing these templates on a proposal page:

• There are many proposals including multiple tags (sometimes even "systems of tagging"). Adding a template for all of them would create long pages containing these templates only.
• A significant amount of proposal pages would need to be changed, because they do not contain the template as the current practice asks the people to create feature pages (exactly the ones, you propose to remove).
• It makes the page look more like description pages and inexperienced users might think the tagging is approved (huge problem in my eyes).
• This conflicts with archiving of proposals.
• Not all suggestions might be worth adding to a tag database. I am talking of abandoned proposals without any voting, which are obsolete by now.
• It adds a useless language bar (proposals are usually in English, translations are rare).
• It fills up the category Category:Pages with ignored display titles. Of course, the template could be changed, but I guess it was set up this way for a reason.

PS: I think most people do not really get your ideas (hence my suggestion to update the documentation). It might be also helpful if you would relate Wikibase to previous ideas. I do not know a lot about them, but just have a look at pages like Machine-readable Map Feature list. I mean, people must have spent quite some time just thinking about different solutions and discussed them ... --Tigerfell  (Let's talk) 16:51, 9 December 2018 (UTC)

If you really want to use a template (I do not know if that is a good idea). I suggest changing {{Proposal Page}} or writing a new one (maybe not such a good idea). --Tigerfell  (Let's talk) 17:13, 9 December 2018 (UTC)

I agree that {{KeyDescription}} in its current appearance is not good for the proposal pages because of the reasons you mentioned, but I do think there should be an easy path from proposal to documentation -- e.g. copy/pasting significant portion of the proposal page into the Key:* page. Your concerns are mostly about the appearance of the template, not the wiki markup. Just because we use the same wikimarkup, e.g. {{KeyDescription}} in the Key: and in the Proposal: pages does not mean they have to appear the same way. Lua module is by far more flexible than the templates. It would be very easy to disable language bar (languagelinks = no) if template is not in the Key: or Value: pages, or adjust which categories get generated. Lua module could use a very different formatting template underneath for the proposal pages. BTW, {{Proposal Page}} could internally also use the new Lua module, in which case we would not need to change any of the existing proposal pages to make them show up consistently, and connect them with the data items.

I am not sure i understood what feature pages I propose to remove, pls clarify.

I would think all proposals, even without the voting, should be in the data items. They wouldn't get in the way, but they allow us an easier way to document past proposals, easier way to find them if someone proposes a similar new feature. Unlike OSM data, data items are similar to wiki pages - they could be treated as "archived" (e.g. status=archive), and most systems can safely ignore them.

Of course some of the above would be moot if we create a "proposal form" - something users will be able to fill out whenever they try to add a new tag to OSM, possibly directly from iD/JOSM. This should be a separate discussion down the road once data items have solved other, more pressing issues.

P.S. Thx, communication sometimes gets in the way of ideas :) I did update both Key and Value description templates. Hope it makes some of it clearer, but feel free to expand. I appreciate all your help with this project, and all the healthy criticism (without it, it may run amok and cause more damage than good!). --Yurik (talk) 17:53, 9 December 2018 (UTC)

P.P.S. Ping me on Slack - @nyurik (join) to discuss interactively. --Yurik (talk) 18:04, 9 December 2018 (UTC)

I will try to address your points separately.

I do think there should be an easy path from proposal to documentation -- e.g. copy/pasting significant portion of the proposal page into the Key:* page

I think this is what Proposal_process#Approved intends to say: You create a new page like RU:Key:a=b (referred to as "feature page") and copy-paste the content over there.

Your concerns are mostly about the appearance of the template, not the wiki markup.

I do not agree with that. Bullet points 1, 2, and 4 do not refer to the appearance, the rest does it (partially). However, the first points are the most important ones for me, so you can not really weight them equally.

BTW, {{Proposal Page}} could internally also use the new Lua module, in which case we would not need to change any of the existing proposal pages to make them show up consistently, and connect them with the data items.

This was my intention when I wrote "I suggest changing {{Proposal Page}} or writing a new one". All in all, I would conclude that changing the template is the road to take. --Tigerfell  (Let's talk) 14:05, 13 December 2018 (UTC)

So in the end it seems that nothing needs to be changed, right? Mateusz Konieczny (talk) 18:40, 5 January 2021 (UTC)

Resolved: Seems to require no action Mateusz Konieczny (talk) 07:38, 14 January 2021 (UTC)

illogical result with 8 yes and 1 no <> 8 yes and 2 no

8 yes : the propal is approved. add a vote=no -> 8 yes + 1 no : the propal is rejected. add a vote=no -> 8 yes + 2 no = 80% yes: the propal is approved.
this illogical situation had motivated the previous change but did not totally solve the problem :-) fix : change 10 votes and 74% to "9 votes and 74%" note that the previous change rise a lot the % needed to have a propal accepted Marc marc (talk) 23:41, 8 April 2019 (UTC)

Since this impacts the voting outcome, I would like to see this discussion happen on talkopenstreetmap.org. The previous change in 2015 was discussed on the mailing list as well. --Tigerfell  (Let's talk) 09:05, 9 April 2019 (UTC)

The problem is requiring 8 yes votes or 10 votes with at least 74% approval and seems to fail only in case of 8 yes votes and 2 no votes. It seems that changing it to "8 approval votes, with at least 74 % approval" would fix it and change outcome for "8 yes, 1 no" case. Would it be OK (testing before proposing it more widely)? Mateusz Konieczny (talk) 09:48, 7 February 2020 (UTC)

Note: I am not taking ownership of this idea. I may (or may not) start discussion on talk mailing list about this, but feel free to start such discussion on your own! Mateusz Konieczny (talk) 23:40, 11 February 2020 (UTC)

"8 approval votes, with at least 74 % approval" is a good suggestion: It's a small change (it only changes the outcome for one specific distribution of votes, namely "8 yes, 1 no"), and it even seems easier to describe and understand than the current rules. --Tordanik 09:59, 10 May 2020 (UTC)

Better description: "at least 8 approval votes and at least 74 % approval". Maybe make vote counting easier at the same time and make it "at least 8 approval votes and at least 75 % approval" Mateusz Konieczny (talk) 18:38, 5 January 2021 (UTC)

Proposed features/change vote counting rules is up Mateusz Konieczny (talk) 19:04, 5 January 2021 (UTC)

Specifications on the process for adaptons or major edits missing

Dear Community,

I could not find any documentation on how to procede with adaptions of existing tagging-schemes or proposals for major edits on existing sites (e.g. adding/removing keys). I think it would be helpful to include this information here but feel unskilled to add it.

Best --MomoMilkiway (talk) 19:17, 27 August 2019 (UTC)

Can you be more specific (can you give an example of a page)? In general it is often done after a discussion, without going through a full proposal process Mateusz Konieczny (talk) 20:41, 27 August 2019 (UTC)

If you want to deprecate a key (suggest that it should not be used), it's appropriate to make a proposal which explains what keys or tags to use instead of the deprecated tag or key. If you are adapting an existing tag for a similar use, it's probably fine to ask about this at the tag's wiki talk page, or on the Tagging mailing list. But I agree that a specific example would be helpful. --Jeisenbe (talk) 09:24, 28 August 2019 (UTC)

Resolved: No response, may be archived Mateusz Konieczny (talk) 07:42, 11 February 2021 (UTC)

Lets reform the Proposal process!

Hi, I honestly think that this page needs to be rewritten and adapted to a more user friendly style. Wikidata property proposals work much better IMO.

• The template comes up automatically!
• There are categories so every property proposal does not end up on one huge page
• There is a big button "create new property" on the top of the proposal page of each category
• There is a list of ongoing discussions of proposals on the page!
• Voting is instant, no dates need to be entered, lets get rid of that. If your proposal gets shot down by constructive criticism you can easily incorporate the needed changes and propose again referring to the former proposal. No need for versioning as this is done by date anyways.
• Get rid of the tagging-mailing list as a device for proposals. This could bring more contributors to the wiki. It is not reasonable to expect someone to keep a tab on both the wiki and email list for discussion of proposals. If wikipedia and wikidata can survive without a proposal list then so can we.

The backlog is insane, which gives a hint about the non-working proposal process: "Pages in category "Proposed features under way" The following 200 pages are in this category, out of 651 total." Does this mean we currently have 651 proposals that we actively discuss that I as a community member should look at? No? IDK where to start. Do you?

Ok, lets take a random example then! https://wiki.openstreetmap.org/wiki/Proposed_features/Cycle_Hierarchy. What a long page! With a nice incomprehensible warning? Why is this not archived? Nothing has happened since 2013?? Don't we have a bot to remove cruft like this as wikidata has? If not lets fix that too! Active proposals have to be active within the last 2 months or they are archived. --PangoSE (talk) 18:16, 10 January 2020 (UTC)

Regarding to the example, if nothing has happened since 2013, could be the status value changed from draft to abandoned or to an other value of this Approval_status#Status_values list instead of archiving it? (Is there any procedure available for such a change?) Would this potential status update also help? --MalgiK (talk) 02:47, 11 January 2020 (UTC)

Yes, that's a good example of a proposal that should be marked as "abandoned" since it has not been updated since 2013 and the tags mentioned are not being used. --Jeisenbe (talk) 03:48, 11 January 2020 (UTC)

Wikipedia and Wikidata are much larger communities with more volunteers and many more paid staff to improve and maintain the website software. If you are able to make some of the technical improvements suggested, it is likely that many of your ideas would be welcomed.

However, you also suggest getting rid of the need to post about the proposal on the mailing list. Note that this is not required: many draft proposals are never officially mentioned on the mailing list and never voted on. But if someone wants to get more input from other users, it is a good idea to mention the proposal to as many interested people as possible. The Tagging mailing list is the main place where people who want to discuss new tag proposals are going to be found. It's also a good idea to post about a new proposal on a forum or a local mailing list if relevant. As you note, there are many proposals which are drafted but never updated, so we should not expect people to read every new proposal that is created in the wiki, until the creator has finished drafting it and thinks it is ready to discuss.

Also mentioned is the benefit of archiving inactive proposals. However, many inactive proposals are the only documentation for a tag which is already used in the database. Archiving proposals can make them hard to find via search (proposals are already less accesible than main Tag: and Key: pages), so this should not be done if the tag or key is not documented somewhere more accesible. --Jeisenbe (talk) 00:36, 11 January 2020 (UTC)

How small is the community anyway? I don't believe in this as a reason for a lousy system. I created a proposal yesterday and it disappeared in a category with hundreds of others that nobody cares to go through. This is pointless and a very bad way to manage the often considerable effert put into proposals.

I suggested we vote for changing all inactive proposals marked proposed or draft to abandoned if not active during the last 2 months in either of its pages.

I could probably implement a system similar to wikidatas, but I'm not sure were to even vote for such a change where people notice. We should probably contact the OSM weekly team to get more eyes on the voting below.--PangoSE (talk) 09:26, 11 January 2020 (UTC)

Votes

Abandon any proposals not active during 2 months

Vote below using {{Support}} or {{Oppose}}

•  Support --PangoSE (talk) 09:26, 11 January 2020 (UTC)
• Oppose Great idea. To get me to say support, the bot must warn the author a month in advance. This will give them incentive to move to voting. I also find two months a bit too little time, especially for drafts. These things move slower than that. Why not make it a year for draft and 3 months for proposed? —M!dgard [ talk ] 21:21, 12 January 2020 (UTC)

Thanks for considering this. Does it really take that long to prepare proposals? I'm surprised. Well the ones I stumbled on were from 2011 and 2013 so your timeline would be fine for me.--PangoSE (talk) 17:32, 14 January 2020 (UTC)

Preparing proposal takes a long time and is often frustrating, so it is not rare to take long breaks without abandoning it. It is not unusual to have discussion on tagging mailing list lasting for month or two Mateusz Konieczny (talk) 10:48, 15 January 2020 (UTC)

• Template:Comment Note that this vote was not announced in any visible location, or discussed before starting it. I would not consider its outcome as binding. Also, I would prefer discussion - maybe there would be consensus that this idea is clearly good (or clearly bad) and there would not be any need for votes. BTW, I went in past through https://wiki.openstreetmap.org/wiki/Category:Proposals_with_%22Proposed%22_status and updated status of some clearly abandoned proposals to the real state. Mateusz Konieczny (talk) 11:04, 13 January 2020 (UTC)

• Thanks for updating the proposals which were abandoned. :) Other wikis I have participated in voting have a central place for votes and clear guidelines (e.g. en.wiktionary) I do not know of any in this wiki. I have no problem discussing longer. I have no idea how I'm supposed to increase participation. Maybe put a notice in Talk:Wiki?--PangoSE (talk) 17:32, 14 January 2020 (UTC)

The best places to announce this would be the Tagging mailing list and Talk mailing list. I am not confortable voting on this until there is discussion. But I would be favor of marking a proposal as abandoned if the tags proposed have not been added to the database in the past 2 years. --Jeisenbe (talk) 07:11, 15 January 2020 (UTC)

• Oppose Two months is too short, especially for a more complex proposal. I agree with the suggestion above for 1 year for a draft / 3 months for proposed, provided that the metric is "no activity" vice "time since status change". I could see a challenging proposal going through several rounds of RFC. The goal is to cull out proposals that are not actively being worked on. The timeframes can always be shortened later if the community feels there is still too much cruft. ZeLonewolf (talk) 15:35, 2 October 2020 (UTC)
• Oppose and Invalid it's a proposal in the middle of a page of discussion, it is not the procedure and makes the proposal completely hidden for all those which do not have a notification on this page precisely. on the contrary, the pages of proposal well made appear in the headings RFC then voting, which makes them visible, more especially when it is announced on tagging as envisaged the current procedure.

Then on the substance: I'm in favour of changing the inactive proposals, however the word abandoned is a bit pejorative. I had proposed "on pause" and that makes it possible to make a difference between "the author hasn't made any progress on his proposal for some time" and "the author has abandoned, for example because there has been relevant criticism for an abandonment or another proposal on the same subject". Marc marc (talk) 00:09, 22 April 2021 (UTC)

Followup

@PangoSE: - are you planning to get back to that? I would propose splitting it into smaller parts, "Abandon any proposals not active during 2 months" idea was clearly not succesfull Mateusz Konieczny (talk) 07:35, 14 January 2021 (UTC)

I plan on marking it as resolved and archiving it Mateusz Konieczny (talk) 07:42, 11 February 2021 (UTC)

@Mateusz Konieczny and ZeLonewolf: Sorry for the late reaction. I have taken a break from OSM. I made a new follow up vote, I split it up in 2 votes according to ZeLonewolfs proposal above. :) I'll place a notice in Talk:Wiki and to the openstreetmap-talk mailing list.--PangoSE (talk) 08:38, 19 April 2021 (UTC)

Yes, this should definitely be discussed on the mailing list(s). --ZeLonewolf (talk) 03:50, 20 April 2021 (UTC)

Follow up vote

Change status of proposed proposals not active during 3 months to abandoned

Vote below using {{Support}} or {{Oppose}} or comment.

• Note that this vote was done without standard RFC. I would not consider its outcome as binding. Also, I would prefer discussion - maybe there would be consensus that this idea is clearly good (or clearly bad) and there would not be any need for votes. Mateusz Konieczny (talk) 11:30, 19 April 2021 (UTC)

Change status of draft proposals not active during 12 months to abandoned

Vote below using {{Support}} or {{Oppose}} or comment.

• Note that this vote was done without standard RFC. I would not consider its outcome as binding. Also, I would prefer discussion - maybe there would be consensus that this idea is clearly good (or clearly bad) and there would not be any need for votes. Mateusz Konieczny (talk) 11:31, 19 April 2021 (UTC)

Resolved: has not proceeded, no activity, can be archived Mateusz Konieczny (talk) 17:04, 23 October 2021 (UTC)

Wikiwide discussion page

Lets make a wikiwide discussion page also where people actually interested in the development of the wiki can participate and were we can vote on changes and maybe a voting policy if none exist yet --PangoSE (talk) 09:26, 11 January 2020 (UTC)

Not sure, if this is what you intend, but Talk:Wiki is currently used to discuss general wiki issues and announcements. There is also a wiki team forum, but it is rarely used https://forum.openstreetmap.org/viewforum.php?id=52 --Tigerfell  (Let's talk) 11:09, 11 January 2020 (UTC)

Oh. Great! Then it is just missing in the left menu. I will discuss further there.--PangoSE (talk) 12:04, 11 January 2020 (UTC)

Resolved: Mateusz Konieczny (talk) 07:39, 14 January 2021 (UTC)

Mention that asking people not involved in OSM to vote is not OK

There is "Sockpuppeting, or one person voting with multiple accounts is not allowed".

I propose change to "One person voting with multiple accounts is not allowed, asking people outside OpenStreetMap community to vote is not allowed."

It removes potentially confusing term "Sockpuppeting" and covers other obvious case Mateusz Konieczny (talk) 08:13, 10 February 2021 (UTC)

•  Support --Lectrician1 (talk) 18:11, 13 February 2021 (UTC)
• I agree, this would be a beneficial change in wording. --Jeisenbe (talk) 18:21, 15 February 2021 (UTC)

Resolved: changed (clearly supported given cryptocurrency mess on one of recent votes where everyone criticized such practice) Mateusz Konieczny (talk) 20:06, 16 December 2021 (UTC)

Renaming "Abandoned" to "Archived" in proposal template

See https://wiki.openstreetmap.org/wiki/Template_talk:Proposal_Page#Rename_.22Abandoned.22_to_.22Archived.22 for discussion about this. Please comment only there to avoid fragmenting discussion, this is intended only as notification Mateusz Konieczny (talk) 09:45, 12 January 2021 (UTC)

Resolved: Mateusz Konieczny (talk) 10:18, 3 February 2022 (UTC)