Talk:Proposal process

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

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)

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  (Let's talk) 22:14, 27 November 2020 (UTC)

I would add at least recommendation to do this Mateusz Konieczny (talk) 07:45, 14 January 2021 (UTC)

Inputbox preload proposal function?

There is a new magic box to create a proposal. I would test it, but I don't want to create a new wiki page. @Lectrician1: can you explain how this works? --Jeisenbe (talk) 06:15, 11 January 2021 (UTC)

Ok, I tried it, but I still don't know where the content is coming from. --Jeisenbe (talk) 06:35, 11 January 2021 (UTC)

From Template:Proposal? Note preload parameter Mateusz Konieczny (talk) 08:54, 11 January 2021 (UTC)

Mateusz is correct that the Template is coming from Template:Proposal. I don't think we need Proposal_process#Proposal_Page_Template anymore since the Create function already creates all of the sections and reminds the user to fill in the parameters of the Template:Proposal_Page. If you want to add those little text reminders under the headings to the Template:Proposal, please do so. --Lectrician1 (talk) 17:10, 11 January 2021 (UTC)

Re: "If you want to add those little text reminders under the headings to the Template:Proposal, please do so." - it would be more polite to add them yourself rather than just deleting my work from this page without comment. --Jeisenbe (talk) 05:35, 12 January 2021 (UTC)

Maybe have subpage documenting it as a fallback in case that magic box fails for some reason? And link that docs? Mateusz Konieczny (talk) 20:02, 11 January 2021 (UTC)

The reason I didn't make a subpage is because if Template:Proposal or Template:Proposal_Page changes again, it would have to be updated. I updated the includeonly to only exclude the Template:Proposal_Page on the Template:Proposal so that the rest of the headings are visually present. I also added a warning that is not transcluded. Sorry for all of the disruptive edits.

Also, comments under each of the headings in Template:Proposal now replace the documentation that was previously present on this article. Please look over them and edit accordingly if something is missing/you don't like. I got rid of the Applies to heading and changed their order.

--Lectrician1 (talk) 22:51, 11 January 2021 (UTC)

I kind of dislike changing it all to templates and Inputbox, because now it is harder to find and edit. And I'm a pretty experienced (OpenStreetMap) wiki editor. How can I see what happens when putting text into the box, without actually making a fake proposal? How can I edit the text output? I don't see much at Template:Proposal or Template:Proposal_Page - is there some other documentation page linked? Also, I usually just make a Proposed_features/<name_of_proposal> page directly, so now how do I find the blank page template to copy and paste? --Jeisenbe (talk) 05:32, 12 January 2021 (UTC)

@Lectrician1: can you link place where you documented how this new contraption works? Mateusz Konieczny (talk) 09:42, 12 January 2021 (UTC)

Updated documentation --Lectrician1 (talk) 15:32, 12 January 2021 (UTC)

@Lectrician1: Now it appears that in this edit you have deleted the whole section under the heading Page details - was that intentional? Have you moved this content somewhere else? That section has been on this page a long time, and it's necessary to explain what should go in each part of the proposal page, since the headings on not self-explanatory --Jeisenbe (talk) 05:38, 12 January 2021 (UTC)

+1 Mateusz Konieczny (talk) 09:43, 12 January 2021 (UTC)

Intentional. See Template:Proposal/doc#Description. I made them Comments in the template so that the proposer doesn't have to navigate between Proposal_process and their proposal when they want to see what to put under each heading. The goal is to make the proposal creation as straightforward as possible. --Lectrician1 (talk) 15:32, 12 January 2021 (UTC)

switches to visual editor

• @Lectrician1: I noticed that new magic box forces switch to visual editor if I edit in wikicode editor. This should be fixed Mateusz Konieczny (talk) 07:44, 14 January 2021 (UTC)

This was intentional. This is happens because the InfoBox has the parameter useve (use visual editor) set to true. It makes following the tutorial direct and easy. Not everyone might know what to do if they initially enter the Wikicode editor since it is quite user-unfriendly. --Lectrician1 (talk) 06:35, 15 January 2021 (UTC)

Future of proposal creation

I haven't done all of the research yet, but in the future I hope to create a form that automatically creates a proposal based on inputs. It will use this WikiMedia Extension called Page Forms to generate them. The extension will have to be added to the wiki.

Forms could also be used to automatically configure the proposal to the Proposed, Voting, Post-Vote stages and eventual transfer all of the proposal information over to actual Tag pages.

--Lectrician1 (talk) 22:57, 11 January 2021 (UTC)

"transfer all of the proposal information over to actual Tag pages." - this is possible to do automatically solely in simplest cases Mateusz Konieczny (talk) 09:44, 12 January 2021 (UTC)

It would be able to instantly create the pages for each of the proposed tags and add the Tag infoboxes with their image, description, element usage, etc. to each of the pages. If a key was proposed with values, the value table could be automatically created and formatted to one of the Map Features Templates as well. --Lectrician1 (talk) 15:39, 12 January 2021 (UTC)

In many cases pages already exist, not all tag that are approved should be added to Map Features Template Mateusz Konieczny (talk) 15:57, 12 January 2021 (UTC)

One vote at a time

What do people think about making a recommendation that proposal authors only have one proposal at a time in a voting status? --ZeLonewolf (talk) 14:47, 20 January 2021 (UTC)

Not sure is codifying it is necessary, this level of activity seems rare. It may be better to not add too many things at this page... Mateusz Konieczny (talk) 15:22, 20 January 2021 (UTC)

 Support Lectrician1 (talk) 05:59, 21 January 2021 (UTC)

Why so? Lectrician1 (talk) 05:59, 21 January 2021 (UTC)

Since this page is for beginners mostly, there is little risk for having too many proposals at once: it's quite a lot of work. I don't think this needs to be a rule. --Jeisenbe (talk) 06:07, 21 January 2021 (UTC)

New proposal status

See my idea for creating a new "Proposing" proposal status here. --Lectrician1 (talk) 12:47, 24 March 2021 (UTC)

If you want to propose it - post a new section here or on Talk:Wiki Mateusz Konieczny (talk) 10:19, 3 February 2022 (UTC)

Resolved: seems abandoned Mateusz Konieczny (talk) 10:12, 9 October 2022 (UTC)

Change proposal suggested formatting

See Template_talk:Proposal#Remove_Proposal_heading. --Lectrician1 (talk) 12:49, 24 March 2021 (UTC)

Time allowed to vote on proposals

Originally discussed at Talk:Proposal

---

I noticed recently that a few proposals could only be voted on for two weeks. Which doesn't seem like enough time. Is there usually a standard amount of time that a proposal should be open for voting? If not, I'd like to suggest 30 days. I'm pretty sure that's how long RfCs on Wikipedia are open for. It would also be good if there was a policy that voting on proposals can't be prematurely canceled. People can't just cancel RfCs on Wikipedia if they aren't going their way. --Adamant1 (talk) 05:10, 1 June 2021 (UTC)

See [[1]]. Two weeks is a standard voting time Mateusz Konieczny (talk) 05:48, 1 June 2021 (UTC)

"if there was a policy that voting on proposals can't be prematurely canceled" - why? Cancelled vote ends in rejected state. I cancelled some votes where I bungled proposal, and submitted fixed version. There would be no benefit from extended voting on something rejected Mateusz Konieczny (talk) 05:48, 1 June 2021 (UTC)

"People can't just cancel RfCs on Wikipedia" - proposal process is not intended to be an exact clone of Wikipedia RfC, differences by itself are not a valid reason for change Mateusz Konieczny (talk) 05:48, 1 June 2021 (UTC)

Ah ha. I don't know if it's my monitor, but I couldn't tell "Proposal process" was a link. There should really only be one article about proposals. Two weeks really doesn't seem like long enough to vote. I suppose the way to have it changed to a month would be asking the mailing list, doing a proposal, Etc. Etc. though and I don't really feel like dealing with all that just so people have a fair amount of time to vote and discuss things. I'll just so though, most people aren't career or chronic OSM editors.

On the prematurely canceled thing, sure, if a proposal is bungled from the start then I see nothing wrong with canceling it. There should be a presumption that everyone that wants to will have time to vote and have their objections addressed if there are any though. No one should be able to arbitrarily end a vote once it reaches a certain thresholds of votes either. Which I've seen happen a few times. Just because there's a certain ratio of voters for or against a proposal half way through it doesn't ultimately mean anything. Let alone that it is rejected. Plus, if people can just write half-hearted proposals and then cancel them as soon as a few people complain, what's the incentive to put effort into doing them well? At the end of a day a proposal shouldn't be a halfcocked start, stop, start, stop process.

RE "proposal process is not intended to be an exact clone of Wikipedia RfC." I'm aware, but Wiki's do tend to share policies, procedures, and norms. I see no reason re-invent the wheel on everything just because it's a different wiki either. Not that's how things are done here anyway. For instance, everyone is fine following the "three revert" rule. I don't see claims that it should be 1 or 8 reverts to qualify as edit warring because this wiki isn't a clone. Anyway, I just provided a few reasons why the time should be extended. Think about this, a proposal vote starts on a Sunday, it takes until Friday of that week for it to posted about in WeeklyOSM. Which is where I and I assume other people find out about proposals. That only gives a week to vote on it and discuss things. Sure, people can find out sooner by wading through various mailing discussions, but that's really practical for most people is it? --Adamant1 (talk) 06:58, 1 June 2021 (UTC)

Feel free to propose a longer voting period using the standard proposal process. It can't be decided in this talk page. With regard to prematurely canceling votes, it's completely appropriate to cancel a vote in order to fix obvious problems with a proposal. There's no good reason to force an obviously failing vote through to a conclusion. --ZeLonewolf (talk) 22:37, 6 June 2021 (UTC)

OK. Re "it's completely appropriate to cancel a vote in order to fix obvious problems." I've been pretty clear that my issue isn't with votes being canceled to fix obvious problems. There's zero point in doing a proposal if the people that are likely to be involved are just going to take what I say out of context or make irrelevant counter points. That said, I don't see why people can't give their opinions about extending the voting time in the meantime. Not every suggestion has to instantly go to a vote after it's made. If perfectly fine if people just say what they think of an idea without a formal vote being involved. --Adamant1 (talk) 02:37, 7 June 2021 (UTC)

I'm not sure what exactly it is you're proposing then, but I look forward to your writeup. --ZeLonewolf (talk) 07:40, 7 June 2021 (UTC)

Extending the voting time to three or four weeks so there is enough time address feedback from voters. Since 99% of the people who use this don't participate in the mailing and shouldn't have to just to have their issues with a tagging proposal addressed. Also, that would give enough time for people to find out about a proposal. It would probably be helpful if there was a notification on the main page of the Wiki about proposals that need voting on. So people actually know about them. But that's another issue. --Adamant1 (talk) 08:10, 7 June 2021 (UTC)

@Mateusz Konieczny: Sort of related to this, the voting period for Proposed features/highway=scramble was suppose to end today but the person who created it extended the vote period for another week. I noticed Proposal_process#Voting says voting should last for at least two weeks, but it doesn't say if the time period can be extended when the proposal is suppose to end. So is extending the voting period at the end allowed for? (IMO it shouldn't be allowed since it comes off like a bad faithed move to run around the current consensus. Especially in a case like this where the proposal was clearly rejected). --Adamant1 (talk) 15:47, 22 November 2022 (UTC)

Centralized comments

Hi, I have created a proposal which has received 23 emails on the tagging mailing list, but only 3 comments on the wiki talk page. Do I need to copy the comments from the mailing list to the wiki talk page so that they are all in one place? --Kylenz (talk) 21:42, 6 June 2021 (UTC)

I'd say no. Unfortunately that's the issue with trying to do stuff related to the Wiki on the mailing list. It leads to low participation here and high participation there. Usually by people that could have just as easily commented on Wiki instead. Except everything said on the mailing list is automatically seen as more valid and authoritative. So they don't really bother participating in Wiki discussions. Anyway, linking to the mailing list discussion should be good enough. That's what people usually do. --Adamant1 (talk) 02:49, 7 June 2021 (UTC)

Linking to mailing list thread if fine. People commenting on tagging mailing list are to be expected as wiki pages manage to be even more confusing to use than mailing lists Mateusz Konieczny (talk) 16:19, 7 June 2021 (UTC)

Remove proposal page template text

Could we remove the Proposal_process#Proposal_page_template text that's meant to be copied?

The current tool to make a proposal page I and other have realized has been extremely easy and useful and I'm not sure of anyone who wouldn't want to use it, as it does exactly the same thing as if you were to create the page yourself and copy the text.

The text takes up a lot of space and also might confuse new editors who want to create a proposal.

We could still keep the link to the the proposal page template ({{Proposal Page}}) and say that's where the generated page originates.

Thoughts? --Lectrician1 (talk) 16:46, 3 July 2021 (UTC)

At least I am using it Mateusz Konieczny (talk) 20:04, 16 December 2021 (UTC)

proposal status for defacto accepted proposals without voting?

There is now this sentence Note that it describes status of of proposal, not status of tag. There are rejected, abandoned and inactive proposals for many tags in a wide use., which status should be put on a proposal that has become established based on a proposal but not by voting? —Dieterdreist (talk) 12:10, 26 June 2022 (UTC)

"inactive" as proposal is inactive, unless proposal was rejected then "rejected". See say Proposed features/Mall Mateusz Konieczny (talk) 12:59, 26 June 2022 (UTC)

I disagree that inactive is a proper description of the status, it means “Not active or tending to be active. Not functioning or operating; out of use.”, while this is about a proposal that became active through adoption not voting. —Dieterdreist (talk) 13:23, 26 June 2022 (UTC)

The tag become active, while proposal was abandoned. Typically it is hard to judge whether proposal was relevant - sometimes it was inspiration, sometimes it was completely ignored. And yes, proposal that never went through a vote is "not functioning or operating; out of use" Mateusz Konieczny (talk) 13:39, 26 June 2022 (UTC)

Tag status: obsolete or obsoleted

In this page I see the status spelling like "obsoleted", but at https://wiki.openstreetmap.org/wiki/Tag_status#Status_values I see it like "obsolete".

What should be the right status? AngocA (talk) 01:52, 4 September 2022 (UTC)

Community forum and the mailing list

The Community forum has been up and running for a while as a replacement to the help and old forum website. Now I think it's a great time to start using it for creating RFCs and voting proposals as currently the mailing list is a very archaic way of doing things in 2022, and it's a massive barrier of entry to new users who may not even want to push or create a proposal after seeing how daunting or confusing the mailing list is. With the community forum being added I don't see any reason now to gate keep new users to only using the old mailing list. The veteran users who use the mailing list should take this into consideration to check the proposals tag on the community forum (which has mailing list features if needed).

I updated the proposal process page to include using the community forum and the ways to use it. This still may need to be tweaked if new categories are made or if different tags should be used. Proposal creators now have the choice of using both the mailing list or community forum at the same time or just the one they want. However, the end goal should be to eventually remove the requirement for using the mailing list all together, although that would require a proposal for changing proposals, and I have a feeling that would take a while.

Thoughts? --Mxdanger (talk) 18:43, 22 September 2022 (UTC)

The wording you used in your edit (special:diff/2397280) wrongly implies that you don't need to announce new proposals to the mailing list ("Users who may not want to use the mailing or are uncomfortable using the mailing list are recommended to use the new Community forum.") ... so I think you should certainly clarify that.

Personally I find the linear nature of Discourse threads to be quite unsuited for the discussion of proposals which are bound to branch into several subthreads. I think proposals are best discussed on their wiki talk page. While announcing proposals on the community forum might help in getting new people involved, I think that there is also some harm in splitting the discussions across yet another platform. --Push-f (talk) 19:34, 22 September 2022 (UTC)

I've updated the wording, something I should have done earlier. As it stands it only suggests that dual posting to the mailing list and forums is valid, but you're still required to post to the mailing list.

> "I think that there is also some harm in splitting the discussions across yet another platform."

That is a good point, that is certainly an issue that will come about in this transition phase, but it's something we will have to deal with to the goal of phasing out the mailing list in favor of the new forum. At least just for proposals. --Mxdanger (talk) 19:53, 22 September 2022 (UTC)

While discussion about tags can take place in many venues, for announcements a single channel seems most appropriate (maybe could become a dedicated one, like “tagging-announcements”? —Dieterdreist (talk) 20:51, 23 September 2022 (UTC)

The wording is still confusing. "Users who can't use ... are still required to use the mailing list". --Tigerfell  (Let's talk) 10:19, 27 September 2022 (UTC)

I attempted clarification Mateusz Konieczny (talk) 10:20, 9 October 2022 (UTC)

See Proposed features/Require proposal announcements to be made on the new forum instead of the mailing list - as expected, opinions are divided Mateusz Konieczny (talk) 10:57, 10 October 2022 (UTC)

Spelling of cancelled

Is there a reason, the canceled [sic] status is currently spelt in American English? (British English would be cancelled to my knowledge). --Martianfreeloader (talk) 11:55, 29 September 2022 (UTC)

Remove "Please discuss this proposal on its Wiki Talk page"

Sadly, Wiki talk pages are problematic for discussion.

I propose to replace "Please discuss this proposal on its Wiki Talk page" with "You can also discuss this proposal on its Wiki Talk page" to not suggest that place where announcement is posted is inferior to wiki talk page

It is fine to comment on tagging mailing list if announcement was posted there, and in fact vast majority of people do this.

We should not create false expectation that significant part of discussion will take part at talk page.

Mateusz Konieczny (talk) 10:08, 9 October 2022 (UTC)

I think we should encourage a central place for discussion and the wiki is IMO despite its flaws the best platform for that (because Discourse discussions cannot be structured like wiki talk pages). So I'd be against changing it. --push-f (talk) 10:54, 9 October 2022 (UTC)

Same as push-f. --Martianfreeloader (talk) 19:34, 9 October 2022 (UTC)

I agree Mateusz Konieczny, I believe the text "Please discuss this proposal on its Wiki Talk page" was added a long time ago, because originally discussion was done on the proposal page itself, at the bottom, below the text of the proposal, the "comments" section. Moving the discussion to a separate "Talk" page was a clear improvement at that time (>12 years ago). But now this text is confusing because it suggests that is the correct place for discussion. While it is a reasonable place for discuss, it is okay to use the forum or the mailing list etc. --Jeisenbe (talk)

This was the original text on this page in 2013, under "Page details" : https://wiki.openstreetmap.org/w/index.php?title=Proposal_process&oldid=963907 - "Comments - there must be a time set aside for other people to comment on the proposal, do not go straight to a vote. Usually the wiki talk page is used for comments, but you might want to explicitly link it from the proposal page for those unfamiliar with wikis. - Let people know of your new proposal by sending a mail to the tagging mailing list, not the talk list." --Jeisenbe (talk) 20:23, 9 October 2022 (UTC)

Looks like the text and link "Please comment on the discussion page" was added in 2015: https://wiki.openstreetmap.org/w/index.php?title=Proposal_process&type=revision&diff=1214682&oldid=1207909 - comment is "add link to discussion page in page template." - but the text "Please discuss each proposed feature on its own discussion page" was already here in 2013. I'm not sure if there was an earlier page that existed before then. --Jeisenbe (talk) 20:36, 9 October 2022 (UTC)

Same as Jeisenbe. Something B (talk) 10:50, 10 October 2022 (UTC)

Just running a proposal in RfC: I did invite people to "discuss in the medium of their choice". Turns out, all of mailing list, community forum and wiki talk page provided valuable input. I am very happy, this took not only place on the wiki alone :) What I like about the wiki, is the free form - I could e.g. mention important talking points from other mediums; I could split threads/sections. It shines for when structuring debate and procedure. Much as it says here Proposal_process --Hungerburg (talk) 18:28, 10 October 2022 (UTC)

Optional additional announcements: Key/Tag Talk pages

I think it would be appropriate to add into the section Proposal_process#Optional_additional_announcements the invite to write about the new proposal in the Talk page for each affected tag/key (especially if the proposal proposes to deprecate the tag/key). This way, anyone with the page for that tag/key in their watchlist would be notified.

For example, if a proposal affects directly historic=* then it should be notified in Talk:Key:historic with a new topic (or simply with a new comment, if a topic for that change already exists). As an other example, if a proposal affects directly historic=aircraft then it should be notified in Talk:Tag:historic=aircraft.

Would anyone be against this change? Any ideas to improve it? --Danysan (talk) 17:51, 13 November 2022 (UTC)

Makes sense to me! --mnalis (talk) 06:28, 18 November 2022 (UTC)

Recent proposal status changes fixed

The “Recent proposal status changes” section of this page broke a couple months ago when proposals were moved from subpages of Proposed features to the Proposal: namespace. I fixed the “abuse” filter that powers this section so that it also considers changes in the Proposal: namespace. As always, you can also follow these changes in Special:RecentChanges by selecting the “proposal-status-changed” tag or directly in AbuseFilter logs. – Minh Nguyễn ^💬 15:47, 25 June 2023 (UTC)