Talk:Proposal process

From OpenStreetMap Wiki
Jump to navigation Jump to search

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)

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

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)

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

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)

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)