[Tagging] Changing proposal process rules - RFC

[Minh Nguyen]

Vào lúc 03:42 2021-01-06, Tomas Straupis đã viết:
> 2021-01-06, tr, 12:55 Minh Nguyen rašė:
>> Is the suggestion to require the input of developers of existing OSM
>> data consumers and editors? Or is it to require some sort of background
>> check or litmus test for voters? The latter would be unworkable on a
>> wiki that supports a pseudonymous database with the ethos of expanding
>> the craft of map data creation to a broader audience.
> 
>    As it is impossible (impractical) to check certificates (requiring
> certificates on the level of GISP would reduce a number of voters
> considerably:-D), my suggestion was to raise a higher margin of
> something which would prove involvement and experience in OSM,
> something which would be quite easy to calculate, therefore it could
> be a number of objects last edited (this could be refined by
> calculating specific operations, tags/domains used, editors used,
> patterns etc.).

This could be a significant burden on the proposer or whoever 
administers the vote.

If the concern is that an approved tag would be unsuitable for data 
consumers, a counterexample is that the editor and data consumer 
developers who effectively vetoed transit:lanes [1] were not 
particularly active in terms of mapping days, but their feedback was 
critical. (I think they made the right call.)

>> What about experience in the real world? A back-office medical assistant
>> would be more likely to point out deficiencies in a proposed healthcare
>> tagging scheme than a certified GISP. A railfan may not carry any formal
>> credentials in the fields you mentioned, but they would know the ins and
>> outs of railway signals and have a strong opinion of what railway data
>> is worth storing in the database. If someone proposes a tag that's
>> subtly eurocentric, it may take a lay contributor from America or Africa
>> to object on the grounds of regional or linguistic differences.
> 
>    This is all true, but railway fan may be carried away and introduce
> too much details in higher level classification. So specific knowledge
> is very good for specific areas, but Carto/GIS/IT is required for all
> of them. Carto/GIS person could point out important things as topology
> rules (mostly missing in current implementation and later emerging as
> problems when creating maps) which would help putting schema being
> discussed in the context as well as tidy it up.

Sure, the substation:* proposal illustrates the risk of specialists 
getting carried away. [2] But any specialist in any field, including the 
ones you prefer, has a blind spot or unusual perspective at times. When 
it comes to proposals about feature tags, there's not only the risk that 
a tag is unsuitable in a technical sense but also the risk that it's 
unsuitable due to a mismatch with on-the-ground reality, as I tried to 
highlight with the healthcare and eurocentric scenarios above.

We all live in our own bubbles and are prone to voting our own 
interests. It frustrates me every time I come across a no vote with a 
comment to the effect of "I don't encounter these where I map", as if 
all the world and all use cases are the same, but I take comfort when it 
turns out to be only a minority of voters who say that.

Rather than eliminating voices, we should be focused on attracting more 
voters and more diverse perspectives, ideally at the RFC stage, before 
the vote. Perhaps if we work on making tagging proposals more organized 
and discoverable, we can lessen the burden on proposers to canvass for 
votes (which can skew any vote because our communication channels are so 
fragmented).

[1] 
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/transit#Fundamental_issues_.28.22I_can.27t_support_transit:lanes.22.29
[2] 
https://wiki.openstreetmap.org/wiki/Proposed_features/Substation_functions

-- 
minh at nguyen.cincinnati.oh.us