Talk:Proposal process

From OpenStreetMap Wiki
Jump to navigation Jump to search

Changes after the installation of Wikibase

Do we need to change the process to include Wikibase? --Tigerfell This user is member of the wiki team of OSM (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 This user is member of the wiki team of OSM (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 This user is member of the wiki team of OSM (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 This user is member of the wiki team of OSM (Let's talk) 14:05, 13 December 2018 (UTC)

Voter qualifications

Are there any rules as to who may vote in a proposal? In one contentious proposal, Proposed features/Substation functions, some votes came from accounts that had no edit history before casting the vote. One of the accounts was created two minutes before voting. Of course, an OSM contributor may feel no need to create an account until they want to vote on a proposal. However, what's to stop someone from sockpuppeteering? Someone could create all the accounts they want to sink or ram through a proposal. Should we require that an account have a contribution history or be traceable to an OSM account with contributions in order to vote? That could force some wiki editors to give up a degree of anonymity by associating with their OSM identities; would that be a problem? – Minh Nguyễn 💬 22:32, 23 March 2019 (UTC)

If that is really a problem, you could try to seek a review from our users with checkuser rights. Requiring people to link their accounts would not really help you, because of the Multi-Account Policy. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 22:54, 23 March 2019 (UTC)
To answer your question: Every wiki account. There were previous discussions about that, but I can not find them right now. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 23:08, 23 March 2019 (UTC)
Thanks, that's exactly what I was looking for. I didn't mean to accuse anyone of being a sockpuppet in this instance, but it got me wondering if there was already any policy against that kind of behavior. It looks like there is. – Minh Nguyễn 💬 03:53, 24 March 2019 (UTC)
From my understanding voting rights are per person, not per account. It may not be easily demonstrable that someone tried to manipulate a voting (I don’t expect it to happen frequently though), but if there are accusations of individuals casting multiple votes, it should be investigated. —-Dieterdreist (talk) 13:37, 24 March 2019 (UTC)
Yes, obviously it is one vote per person, not per account. Not sure is there an explicit policy but it is quite obvious. Mateusz Konieczny (talk) 14:26, 24 March 2019 (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 talk, “ат” The previous change in 2015 was discussed on the mailing list as well. --Tigerfell This user is member of the wiki team of OSM (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)

British English terms are preferred

I've added the sentence "British English terms are preferred" to the short description of how the tag "name" (that is, key=value) should be created, since this appears to be generally accepted practice by the community since the beginning. I used "preferred" since there are cases when there is no British English term and some other dialect of English is used, and rarely a feature tag might use a different language, for example for a feature that is unknown in English. --Jeisenbe (talk) 00:43, 3 August 2019 (UTC)

Not sure if it's worth making this distinction, but while British English spelling is strongly preferred, British English terms only seem weakly preferred. That is, other considerations such as unambiguity or international understandability can easily trump the preference for British terms. For example, the American term was intentionally chosen for sidewalk=* because it's less prone to misunderstandings. --Tordanik 13:47, 3 August 2019 (UTC)

Non proposed features: document tags in User space, Proposal space, Tag: and Key: space?

Currently the section "Non proposed features" mentions that new tags should not be added to Map Features without discussion. Some users also believe that new tags should not be documented under the feature wiki space with "Key:New_feature" or "Tag:key=value" pages, but should instead be documented in a User:username/ namespace or the Proposed_features/ namespace. However, occasionally new wiki pages are created in these standard spaces for tags with only a few uses or no uses in the database.

I would encourage mappers not to create new feature pages for tags which are not yet in use, or have only been used a handful of times by one mapper. Instead, it would be good to clarify that the Proposed_features/ namespace can be used even if the user has no interest in continuing the proposal process. I would recommend that new feature pages only be created for "in use" tags that have been used by more than a handful of different mapeprs in more than a handful of places. --Jeisenbe (talk) 00:54, 15 August 2019 (UTC)

I agree that adding barely used tags to Map Features or Tag:amenity=parking or other pages is a bad idea (and I reverted such edits in past). But it is completely fine to create without proposal process page for barely used tags. It is not very useful to document tag used once or twice but it is OK. But note that page describing tag duplicating other more standard ones may be also turned into page documenting given tag as a horrible idea - see landcover=water that was created without discussion and equally without discussion I added explanation that this tag is a horrible idea. Mateusz Konieczny (talk) 04:20, 15 August 2019 (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)

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! 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)


Abandon any proposals not active during 2 months

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

  • Symbol support vote.svg 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)
  • 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)

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 --Tigerfell This user is member of the wiki team of OSM (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)

Clarify whatever explicit abstaining is the same as no vote

Talk:Proposed features/give box revealed that it is not fully specified how abstain votes work. There is some confusion in multiple places whatever "abstain" counts as vote. I propose to make following changes

In approved/rejected decision ignore explicit abstentions (10 vote yes, 1 vote no, 10 "abstain but have comments" would be approved).
In case of describing number of people use "N people participated in voting" (when including explicit abstentions) or "M people voted" (when including only yes/no votes, without abstain comments)

This is just initial idea - any comments? Mateusz Konieczny (talk) 09:56, 7 February 2020 (UTC)

I would probably need a wider discussion (mailing lists ?), but a clarification is definitely needed. If abstain (displaying as "comments") count as no, why does it even exists ! ;-) H@mlet (talk) 10:17, 7 February 2020 (UTC)
The proposal of @Mateusz Konieczny looks good to me. In fact, "abstain" means "to choose not to vote" (definition of "abstain" by Merriam-Webster). Mappers can abstain and comment a proposal at the same time, but they can't abstain and vote at the same time. --Dcapillae (talk) 23:54, 10 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:39, 11 February 2020 (UTC)
I have send a message to both the talk and tagging mailing list. --Dcapillae (talk) 16:14, 12 February 2020 (UTC)
Symbol support vote.svg Support Ignoring explicit abstentions in the approved/rejected decision. --Dcapillae (talk) 16:14, 12 February 2020 (UTC)
Symbol support vote.svg Support Explicit abstention from vote is still not a vote and should not be considered as mattering for approved/rejected decision. If you oppose proposal in its current form - vote against it. Mateusz Konieczny (talk) 18:36, 12 February 2020 (UTC)
Symbol support vote.svg Support Any abstention is a decision not to vote. --PeterPan99 (talk)
Symbol support vote.svg Support Abstaining is equivalent to not voting . --European water (talk) 07:37, 13 February 2020 (UTC)
Symbol support vote.svg Support To abstain means to not vote. The voting instructions clearly say to pick "abstain" if you want to comment but don't want to vote. So abstensions should be ignored in the vote tally. Jmapb (talk) 17:35, 13 February 2020 (UTC)
Symbol support vote.svg Support Abstaining clearly means not participating in the vote. I don't really understand why there is this discussion. --SelfishSeahorse (talk) 09:13, 14 February 2020 (UTC)
At least someone on the tagging list seems to say that we always have counted abstension as no.
Symbol support vote.svg Support but I don't really where the voting rules come from anyway... H@mlet (talk) 01:25, 17 February 2020 (UTC)
Oppose IMHO if you want to abstain from the vote, do not "vote", i.e. do not add the template "vote". In this way, your contributions (comments, which you can still make of course) will not count for the quorum, and will not have influence on the voting result. IF you want to "vote" abstain, then your vote will count for the quorum, but will neither count as "yes" nor as "no". The title of this section is misleading because abstentions are not "the same as no", but they might have similar effects. --Dieterdreist (talk) 09:10, 17 February 2020 (UTC)
Symbol support vote.svg Support I my opinion the description in the "Instructions for voting" is misleading. I want to do something about that. Changing the description of the "Proposal process" is one way to go which I support. The autor is still free to choose "rejected" or change something if the abstains have critical comments. Or other voters can change their vote. --ToastHawaii (talk) 22:13, 17 February 2020 (UTC)
Symbol support vote.svg Support In my opinion, abstaining by not voting means to me "I couldn't care less about this question", while explicitly abstaining amounts to "right, it's a valid question, but whatever you say I'm fine with it". I'm not sure if we have anything like a quorum which needs to be reached, for a vote to be valid, but explicitly abstaining should count for reaching the quorum, while not voting at all should not. Mariotomo (talk) 00:13, 19 February 2020 (UTC) ; Edited Mariotomo (talk) 20:25, 19 February 2020 (UTC)
@Mariotomo, explicit abstaining count for reaching the quorum. We are voting to ignore explicit abstentions in the approved/rejected decision only. Anyone can participate in a voting process by abstaining and commenting. That counts for the minimum quorum required, but would not count for the calculation of the percentage that decide whether the proposal is approved: "support" versus "oppose". There are three ways to participate: support the proposal, oppose the proposal or abstain. Only the first two decide whether to approve the proposal, but they all count for calculating the minimum quorum required. See Talk:Proposed features/give box for an example of the inconvenience of the current confusion.--Dcapillae (talk) 08:37, 19 February 2020 (UTC)
@Dcapillae, so in my case, I guess I do support the proposal. I'll fix my vote and review the comment. Or I could also abstain, but that would not be helpful, while we've not decided what's the meaning of abstain.
Symbol support vote.svg Support In every voting system ever, abstaining means you're fine with both outcomes. —M!dgard [ talk ] 13:05, 23 February 2020 (UTC)
Oppose an explicit abstention means "I do not support, but not strongly against." If you want something to carry then you must at least get the tiny minority of OSM involved in this process to agree with you. Jnicho02 (talk)
@Jnicho02, if an explicit abstention means "I do not support, but not strongly against", then "I don't support this proposal, but I'm not against it either." In that case, an explicit abstention should be ignored in the approved/rejected decision. The "tiny minority of OSM" involved in the process it is guaranteed by the proposal process itself: "A rule of thumb for 'enough support' is 8 unanimous approval votes or at least 10 votes with more than 74 % approval" ([1]). We're clarifying that an explicit abstaining is not the same as no vote to avoid cases like this. As you say, if I explicitly abstain, my vote should not be counted as a vote against because "I do not support, but not strongly against.". If I did not want the proposal to be approved at all, I would vote "oppose", not "abstain". --Dcapillae (talk) 12:07, 26 February 2020 (UTC)
Symbol support vote.svg Support Sdoerr (talk) 14:04, 26 February 2020 (UTC)
Symbol support vote.svg Support Abstention to me means that I'm following the propoasal page and Tagging-thread and feel like the process has been good (or at least sufficient), but I don't have an opinion about the outcome of the proposal. I'm fine if it fails and I'm fine if it passes, but at a minimum I'm here and watching the process. --Adamfranco (talk) 14:16, 26 February 2020 (UTC)
Symbol support vote.svg Support Fanfouer (talk) 21:56, 26 February 2020 (UTC)
Symbol support vote.svg Support I think that abstaining should count as an informal vote, & in any voting system, informal votes aren't counted. Party A gets 1000 votes, Party B gets 900, there are 200 informal votes - Party A wins 1000 to 900. There's plenty of time & opportunity for any comments to be made during the RFC or voting stages - if your comments have been ignored, vote No; if you think it's a good idea that could still be improved vote Yes, & in both cases add a comment to your vote Fizzie 22:47, 26 February 2020 (UTC)

After almost a month, 14 votes for ignoring explicit abstentions in the approved/rejected decision versus 2 votes against.

I think we can consider the issue resolved. If it is all right, we could include the clarification in the corresponding section of the proposal process.

I also think that the amenity=give_box proposal should be approved/rejected with this clarification in mind. Don't you think, @ToastHawaii? --Dcapillae (talk) 17:51, 10 March 2020 (UTC)

@Dcapillae Yes. Thanks, after the change I will proceed with the process for amenity=give_box proposal --ToastHawaii (talk) 09:13, 11 March 2020 (UTC)

Done! I have included the following clarification in the corresponding section of the proposal proces.

Before it said:

A rule of thumb for "enough support" is 8 unanimous approval votes or at least 10 votes with more than 74 % approval, but other factors may also be considered (such as whether a feature is already in use). All suggestions should be taken into account before a proposal is approved or rejected.

Now it says [2]:

A rule of thumb for "enough support" is 8 unanimous approval votes or at least 10 votes with more than 74 % approval, but other factors may also be considered (such as whether a feature is already in use).
The explicit abstentions doesn't counts as vote (e.g. 10 vote "yes", 1 vote "no", 10 "abstain but have comments" would be approved), but all suggestions should be taken into account before a proposal is approved or rejected in order to resolve any deficiencies in the original proposal (if they exist).

Thank you all of you for your collaboration. --Dcapillae (talk) 11:56, 14 March 2020 (UTC)

Difference in status

What's the difference between a proposal underway and an active proposal or an abandoned proposal and a canceled proposal? How does anyone tell the difference anyway? Going through them, it seems like people just pick between underway and active or abandoned and canceled randomly. So it seems like there is some confusion and having the extra categories doesn't help any. It would be clearer and easier to organize proposals IMO if there were only two statuses instead of four. Like active and abandoned, underway and canceled, or whatever other combination of "currently going on" and "not going on anymore" is best. Or at least change "active proposals" to "approved proposals." Active makes it sound like the proposal process is still going on. The category should fit the status. --Adamant1 (talk) 05:48, 18 April 2020 (UTC)

  • Vast majority of proposals are abandoned silently and there is little interest in retagging abandoned marked as active draft into abandoned. I do it sometimes but there are still many of them incorrectly marked as active. I would recommend marking such inactive proposals as inactive, but I recommend checking page history before an edit. Some authors of abandoned proposals reverted this changes claiming that abandoned inactive proposal is active. In such cases I recommend skipping page as maybe my impression is wrong, there are many other that are not controversial and in rare cases it causes proposal to become active again. Mateusz Konieczny (talk) 20:09, 29 April 2020 (UTC)

Status in proposals versus articles

Currently the status in a proposal for something that been superseded by a better tag is "obsoleted". Whereas, in articles its "depreciated." It's needlessly obtuse to have two different terms for what is essentially the same status. I'm not sure of any other status is different between the proposals and articles. Although, if there is one it should be changed to just a single status also. As it is just needlessly convoluted otherwise. --Adamant1 (talk) 06:37, 18 April 2020 (UTC)

Voting on your own proposal?

Should you be allowed to vote on your own proposal? There's nothing in the page that says you can't, but it just feels like bad form to do so. ZeLonewolf (talk) 23:59, 12 October 2020 (UTC)

Yes, it is permitted. Proposal authors almost always vote to approve their own proposals. --Jeisenbe (talk) 04:54, 13 October 2020 (UTC)
It is perfectly fine and it is also to have a clear sign that vote started. I always voted for my own proposals as I support them Mateusz Konieczny (talk) 09:36, 13 October 2020 (UTC)

Post-vote notification

I note that there appears to be no requirement to announce the result of the vote on the tagging list. It seems that, particularly in the case of approved proposals, that some sort of formal notification ought to go out rather than just a silent edit of the wiki. --ZeLonewolf (talk) 00:57, 25 November 2020 (UTC)

Quoted from Proposal process:

It is not meant as a set of absolute rules, but as a guide.

I think if you add a suggestion to inform tagging mailing list about the outcome of a proposal, it will be an uncontroversial addition. WeeklyOSM often reports about the outcome of proposals, some users keep the proposal page in their watchlist, so they are informed. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 22:14, 27 November 2020 (UTC)