Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

[Jez Nicholson]

Re: deprecating amenity=lifeboat

Is amenity=lifeboat actually wrong? The ones in the UK at least are actual
lifeboats, showing where they are moored, probably with a lifeboat station
nearby.

On Wed, Nov 23, 2022 at 1:00 AM Graeme Fitzpatrick 
wrote:

> Following our previous discussions, I've now raised a proposal to proceed
> with these changes:
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/emergency%3Dlifeboat_station
>
> Please comment in whichever of the 3 places that you prefer, & I'll
> attempt to keep on top of all of them! :-)
>
> Thanks
>
> Graeme
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

[Matija Nalis]

On Sun, 20 Nov 2022 19:10:07 +0100 (CET), Mateusz Konieczny via Tagging 
 wrote:
>> the first and foremost reason for the tagging mailing list to exist was the 
>> desire to offload tagging discussions on a central place, off the other 
>> channels, because people there felt overwhelmed with the discussions needed 
>> to agree on tags to describe the whole world, and it seemed helpful to 
>> reduce the volume on the talk list to a size that can be followed with 
>> significantly less dedication of time. Moving back to discussing tagging 
>> everywhere will make these other channels less useful for some people, I 
>> guess. Maybe this is unfounded because it came out, tagging is relevant all 
>> over OpenStreetMap (i.e. tagging discussions already happen on all channels, 
>> lately even on osmf-talk) and you can hardly ignore it, and because the 
>> structure of the contributors has changed, or something like 
> The new forum may be also more capable of handling large volume of posts - 
> you can
> easily mute threads and entire categories.

"muting categories" is "unsubscribing from that specific mailing list", right 
(e.g. I can decide to unsubscribe from
"Tagging" or from "Talk-hr" or whichever other list)?

I don't particularly like Discourse "you are subscribed to everything by 
default" philosophy either, as I much prefer
"opt-in" methods like in mailing lists. While you can mute a category (and 
repeat that as new categories get created),
it is annoying (and not easy to find about and actually use -so much about it 
being "newbie friendly"). 

While I find some Discourse features useful (liking posts, multi-post-quoting, 
@mention), others are quite bad:

- horribly confusing replying UI (I guess vast majority of users incorrectly 
replies to whole thread istead of the
  message, and never find an option to create subthread / reply in new linked 
topic)
- horrible thread / subthread following (with no multi-layer threading support)
- no *visual* "threading tree" indication (who replied to what), without doing 
manual tree reconstruction by clicking
  on all posts arrows manually. Even (argumably very rudimentary) Tagging 
mailing list archives do it much better
- practically nonexistent scoring (you can bookmark a specific post, and even 
that in almost unusable way) 
  (mail or news clients can do so much much more to make it usable, especially 
if thread continues for *weeks*)
- no message filter (and lacking search)
- only one discussion (with horrible "drafts" implementation which fails in 
painful ways if one has more than one tab
  open. Even old forum was much much better here!)
- inability to treat different categories differently (yes I can track/watch 
the topic, but I can't make watched topics
  in Talk-hr behaving differently than watched topics in Tagging; and I'd very 
much want to -- alternative is falling
  back to lowest common denominator, which doesn't work well)
- javascript requirement (and accessibility issues)
- GUI requirement
- inability to change UI to access same data (as oposed to mailing list, where 
if I don't like one mail user agent, I
  (or anyone else) can easily switch to another one. Discourse is forcing 
"one-size-fits-all", even if it doesn't fit
  you in particular).

to name but a few.

In short, I find Discourse work well for short discussions (up to max. 10-15 
messages), but becomes totally unusable on
bigger threads esp. with subthreads (e.g. highway=scramble discussion with 100+ 
messages). As tagging topics are more 
likely to produce bigger discussions, I find Discourse poor match for that 
specific purpose. It might be quite better
match for very-low-traffic regional mailing lists (like my country own 
Talk-hr). 

> As result massive posting in one thread is easier to ignore in its entirety.
>
> This is in theory achievable with filtering and so on, but much harder to 
> apply in
> practice, with mailing lists.

I guess it might depend on mail user agent being used. It should be very easy, 
e.g.:
https://support.mozilla.org/en-US/kb/ignore-threads

With advantages that one can also ignore certain sub-threads only if one so 
chooses.

(note that I'm using more advanced client than that, but for example choose 
Mozilla Thunderbird as common, free, and
easily available newbie-friendly MUA, which still has that feature implemented 
much better than Discourse)

-- 
Opinions above are GNU-copylefted.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

[Matija Nalis]

On Sun, 20 Nov 2022 10:01:23 +0100 (CET), Cartographer10 via Tagging 
 wrote:
>> Question is: did you then collect all the points those extra communities 
>> made (both those you agreed with, and those
>> that you didn't agree with), and summarized them on wiki /talk page, for 
>> extra period of RFC? Because if you didn't
>> (especially if you didn't include things you _disagreed_ with) then you 
>> abused that input to promote your personal view,
>> and disregarded the best parts that such other views could provide.

> The proposal has a section "external discussion". There the largest external 
> discussions are listed. These are all
> publicly accessible sources so people can read what has been discussed there. 
> I have also send updates when I changed
> major things in the proposal. I can image if you announce it on a closed 
> platform like Discord, that a summary on the
> talk page can be useful. 

It has. I'm not implying that you're trying to hide evidence by omitting those 
sources. :-)

I'm pointing out that:

- the proponent will have to scan those external threads anyway

- it is huge waste of everyones time if *each and every other contributor* has 
to scan those 100+ posts threads again
  for themselves to extract 2-3 possibly useful suggestions in order to suggest 
improvements. (for recent examples, see
  "highway=scramble" and related threads). As such requirement of general OSM 
population would hugely reduce number of
  people putting an effort, and thus result in much lower quality of proposal 
changes (people wasting time on asking
  for already explained things, good suggestions being ignored), and finally in 
voting not being based on available
  input (as it was too hard to process in fullness for average wiki voter), or 
even giving up totally on proposal
  process.
  
- thus, it would be much better if proponent (who have already invested time in 
processing those external sources)
  would summarize that 2-3 suggestions on proposal talk page, and invite people 
for extra RFC commenting on those
  suggestions too. 
  Even in cases when they are publically accessible to everyone (and of course 
always when they are not!)

That is my suggestion on proposal process improvement; and it would allow for 
"legalizing" adding extra external
discussions as regular people would not be burdened by being required to follow 
them, as the onus would be put
on proponent to summarize those on proposal wiki talk page.

>> I can imagine quite bad things, but to be fair, here is a most realistic one 
>> instead: On each changing of status quo,
>> some people will leave the process for good, as that will be the straw that 
>> broke the camel's back. If you need to
>> learn from history, see the debate when OSM changed license from CC-BY-SA to 
>> ODbL. And then, if another proposal
>> changes situation back to what it was before, that will NOT cause (majority 
>> of) people that left to come back.
>> It will instead cause some MORE people to leave for good (in revolt).

> There are always people who don't agree with a change. EVERY proposal or 
> changes has that. If more then 75% of the
> people agree you can assume that enough people support it. And of course, 
> taking the status quo into account is

Sure. I'm just explaining why "well we can change it, and then change it back 
if it doesn't work" has a serious
consequences, as the initial suggestion did not seem to consider them (i.e. 
"What is the worst thing that can happen?")

> important. However, if you can't change the status quo, you never move 
> forward.

Agreed. That is why I am (still) offering suggestions how to move forward, 
instead of being silent until voting period
and casting "no" vote without wasting time on participating in discussions.

At the end, related quote by G.B. Shaw for some smiles:

"Reasonable people adapt themselves to the world. Unreasonable people attempt 
to adapt the world to themselves. All
progress, therefore, depends on unreasonable people."

-- 
Opinions above are GNU-copylefted.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

[Matija Nalis]

On Sat, 19 Nov 2022 17:54:42 -0800, Minh Nguyen  
wrote:
> Vào lúc 17:24 2022-11-19, Matija Nalis đã viết:
>> Because, someone has to do that summarizing work for extra channels to make 
>> sense, and it is IMHO only fair that would
>> be proposal author (expecting that EVERYBODY will do that SAME task is both 
>> extremely wasteful, hugely unrealistic,
>> and likely to lead to few participating members willing to do that becoming 
>> burned out prematurely).
>
> Practically speaking, no one can fully understand the discussion in 
> every community. That's a much higher bar than just announcing something.

That is true. But if not even the proponent is equipped/willing to do that,
what are the chances that majority of wiki commenters/voters will be
able/willing to do that? Surely even lower.

> For example, I think it would be perfectly reasonable to alert OSM Japan 
> Slack about my next proposal, but my nonexistent Japanese skills would 
> be catastrophically inadequate to capture the sentiment there. It would 
> be better to candidly state upfront that I'm unable to respond to 
> individual comments there and direct interested mappers to the wiki talk 
> page, where hopefully others can engage as necessary.

That is OK, when it is just read-only announcement, and interested people
are pointed to go to wiki talk page and comment there.

Problem arises when there is discussion on that extra channel and not on wiki
talk page, and nobody forwards it to the proposal wiki talk page, so majority
of people never know that there even was such a discussion, much less what was
suggested.

> All too often, a proposal announcement on this list ends with an 
> exhortation to comment on the wiki talk page, inevitably leading to a 
> long thread here instead. Where is the requirement to summarize the 
> tagging list thread, for the benefit of ordinary mappers who will be 
> voting but can't easily follow Mailman's deeply nested threads split 
> across monthly archives? 

I would recommend that proponent summarize mailing list discussion too, yes.

(although it is arguably somewhat less important when it is only official 
 communication channel, but it would become much more important if other
 official channel were added, as then there would be 50-50 [or whichever]
 chance that the voter did not follow "the other" channel)

Related: I actually find rudimentary mailman web interface more usable 
than Discord for reading tagging proposals. It has nice and easy visual 
threading, and web browser automatically indicate read vs. unread articles 
(even if you did read them in logical, instead of chronological way!), and I 
can much easily open interesting messages in extra tab for later perusing
(without them being mixed up). 
Also, I personally did not find the fact that every month I have to click few
extra times to continue following thread that big an issue (especially
considering all the work that *actual reading* of those dozens of messages 
each month pose by itself!)
(of course, I still prefer news.gmane.io NNTP interface to mailman archive, 
but as mentioned previously, that is likely too arcane suggestion for new
users born into wait-whatdoyoumean-internet-is-more-than-just-www generation :-)

> After all, the proposal guidelines have never required _voters_ to subscribe
> to the tagging list.

And those who didn't follow ML suggestions (and when it wasn't summarized in
wiki), invariably produced less useful input. 

Note that I find voting part of proposal actually unimportant in itself; that
is, important only as it:

- forces proponent to actually pay atention to the suggestions made earlier in 
the RFC
- provides a final date for closure (i.e. discussion not dragging on endlessly)
- weeds out proposals for things that nobody actually care enough even to come 
to vote yes

> Maybe a better model would be for each community to take some of the 
> burden off the proposal and have one or more self-appointed liaisons 
> handle announcements and communicate the most salient ideas back to a 
> single source of truth (the wiki, or wherever we decide to hold votes in 
> the future). This would apply to the tagging list as well as the 
> community forum.

That is a good idea! I've tried to suggest something similar with my
co-proponent comments. The main issue there IMHO is that of "Bystander effect"
https://en.wikipedia.org/wiki/Bystander_effect

I.e. unless someone is explicitely mentioned by name in the proposal as
liason for some group (and of course accepts such responsibility!), 
it is quite likely that nobody would actually do it.

And if they accept that obligation, they should be hold to their word; so my
suggestion was to name them as co-proponents, even if their work would be
mostly communication and not technical writing about the topic (even it is
different kind of work, it is still very valuable and worthy of recognition 
there).


-- 
Opinions above are GNU-copylefted.


___

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

[Zeke Farwell]

On Wed, Nov 23, 2022 at 10:57 AM Matija Nalis <
mnalis-openstreetmapl...@voyager.hr> wrote:

> I find Discourse work well for short discussions (up to max. 10-15
> messages), but becomes totally unusable on
> bigger threads esp. with subthreads (e.g. highway=scramble discussion with
> 100+ messages).
>

A 100+ message thread on the mailing list is no better than on Discourse.
The problem is people spending too much time writing many long messages,
and not enough time reading and thinking.  Much as I would love if everyone
could learn to write concisely, this will probably always happen on any
platform.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

[Minh Nguyen]

Vào lúc 10:44 2022-11-23, Zeke Farwell đã viết:
A 100+ message thread on the mailing list is no better than on 
Discourse.  The problem is people spending too much time writing many 
long messages, and not enough time reading and thinking.  Much as I 
would love if everyone could learn to write concisely, this will 
probably always happen on any platform.


If only I could +1 this post without spamming everyone.

--
m...@nguyen.cincinnati.oh.us



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

[Graeme Fitzpatrick]

On Wed, 23 Nov 2022 at 19:12, Jez Nicholson  wrote:

>
> Is amenity=lifeboat actually wrong?
>

No, not really, but why have amenity=lifeboat & emergency=lifeboat (&
sometimes emergency=marine_rescue) both tagged on the same feature?


> The ones in the UK at least are actual lifeboats, showing where they are
> moored, probably with a lifeboat station nearby.
>

But we're supposed to be tagging the base / buildings, not the boat itself.

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

[Andy Townsend]

On 23/11/2022 22:23, Graeme Fitzpatrick wrote:
But we're supposed to be tagging the base / buildings, not the boat 
itself.




Why not both?

Taking an example:

https://www.openstreetmap.org/node/8321217532

 * amenity = lifeboat
 * emergency = marine_rescue
 * lifeboat = offshore
 * lifeboat:class = RNLI Trent
 * name = George and Mary Webb
 * operator = Royal National Lifeboat Institution
 * operator:short = RNLI
 * ref = 14-14
 * seamark:name = George and Mary Webb
 * seamark:radio_station:category = ais
 * seamark:radio_station:mmsi = 232002370
 * seamark:rescue_station:category = lifeboat_on_mooring
 * seamark:source = Bing; https://rnli.org/find-my-nearest
 * seamark:type = rescue_station
 * website =
   
https://rnli.org/find-my-nearest/lifeboat-stations/whitby-lifeboat-station/whitby-lifeboats

The matching lifeboat station for that is:

https://www.openstreetmap.org/way/167044613

building 
 	yes 

description 
 
Search and Rescue
emergency 
 
lifeboat_station 

name  
Whitby Lifeboat Station
operator 
 	Royal 
National Lifeboat Institution
operator:short 
 
RNLI
operator:wikidata 
 
	Q2166873 
seamark:name 
 
Whitby Lifeboat Station
seamark:rescue_station:category 	lifeboat 

seamark:type 
 
rescue_station 

website  
https://rnli.org/find-my-nearest/lifeboat-stations/whitby-lifeboat-station
wikidata 
 
Q64584542 


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

[Graeme Fitzpatrick]

On Thu, 24 Nov 2022 at 09:29, Andy Townsend  wrote:

>
> Why not both?
>
Because a boat is a mobile feature, that we don't / can't map?

e.g
https://www.openstreetmap.org/edit?way=349559642#map=19/-27.42815/153.08582
- we don't try to map the last bus in the middle row as #632

> Taking an example:
>
> https://www.openstreetmap.org/node/8321217532
>
>- amenity = lifeboat
>- emergency = marine_rescue
>- lifeboat = offshore
>- lifeboat:class = RNLI Trent
>
> I've included those in the proposal as they are details that apply to the
station, but

>
>- name = George and Mary Webb
>
> is the name of the lifeboat itself. This could possibly be included as
lifeboat:name= ?


>
>
>
>
> name  Whitby
> Lifeboat Station
>

This is the actual name of the station.

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging