User:Rtfm

From OpenStreetMap Wiki
Jump to navigation Jump to search
Userboxes
Flag of Europe.svg This user hails from Europe
Ubuntu Touch Rtfm uses an Ubuntu phone or tablet.
uNav Rtfm uses uNav, mobile navigation app for Ubuntu touch
Bike Rtfm is a biker
Mail-closed.svg Rtfm can be contacted by e-mail via this wiki.

Strange individuals participating

Hi there,
sometimes I wonder whether the OSM discussions are undermined by commercial map providers,
see the Simple Sabotage Field Manual: (Page 18)
https://www.cia.gov/news-information/featured-story-archive/2012-featured-story-archive/CleanedUOSSSimpleSabotage_sm.pdf

(11) Production
(a) Organizations and Conferences
(1) Insist on doing everything through "channels." Never permit short-cuts to be taken in order to expedite decisions.
(2) Make "speeches", Talk as frequently as possible and at great length., Illustrate your. "points" by long anecdotes and accounts of personal experiences. Never hesitate to make a few appropriate "patriotic" comments
(3) When possible,refer all matters to committees, for "further study and consideration." Attempt to make the committees as large as possible,never less than five.
(4) Bring up irrelevant issues as frequently as possible.
(5) |Haggle over precise wordings of communications, minutes, resolutions.
(6) Refer back to matters decided upon at the last meeting and attempt to re-open the question of the advisability of that decision
(7) Advocate "caution." Be unreasonable and urge your fellow-conferees to be "reasonable" and avoid haste which might result in embarrassments or difficulties later on.
(8) Be worried about the propriety of any decision - raise the question of whether such action as is contemplated lies within the jurisdiction of the group or whether it might conflict with the policy of some higher echelon.


Also see

Arrogance comes from ignorance (assumed sabotage)

There are so-called "admins" doing mechanical reverts on manually corrected (standardised) entries without even looking at it (or their logic doesn't work at all). This isn't a behavior which encourages people to dedicate many hours of their life voluntarily to make OSM better, especially if it is encouraging trolls to continue their destructive behavior. With every year participating, my first impression (from above) and the one from Serge Wroclawski (below) seem to be right. I meanwhile really think there's a kind of troll factory trying to slow things down (for someone's profit). So we should seek to replace the current "leaders".

In case you think this sounds too much like a conspiracy theory, check  General_Motors_streetcar_conspiracy

Structural problems

Found an interesting article and wanted to share an excerpt :

"Serge Wroclawski worked on the OpenStreetMap project for around eight years, and he helped set up OpenStreetMap US, a nonprofit organization dedicated to OpenStreetMap in the United States. In 2014, he wrote a widely discussed article "Why the world needs OpenStreetMap", which explores many of the points mentioned above in greater detail, and with greater authority. It's well worth reading, as is his latest exploration of OpenStreetMap, ominously called "Why OpenStreetMap is in Serious Trouble". As he writes:

While I still believe in the goals of OpenStreetMap, I feel the OpenStreetMap project is currently unable to fulfill that mission due to poor technical decisions, poor political decisions, and a general malaise in the project."

https://www.linuxjournal.com/content/openstreetmap-should-be-priority-open-source-community

Why OpenStreetMap is in Serious Trouble

"...at the same time, the ultimate choices for the website, the geographic database and the infrastructure are not under the direct control of the Foundation, but instead rest largely on one individual, who (while personally friendly) ranges from skeptical to openly hostile to change.

As a former professional system administrator, I relate strongly to these types of individuals. At the same time, the desires of them need to be balanced by the overall needs of the project to make progress and keep momentum to keep its userbase happy and engaged.

That is not the case here, and it's to the detriment of the project.

The obvious question is why the OpenStreetMap leadership takes the positions that it does, despite the clear need for change. The answers in my view are commercialism in the project, along with a cultural desire to retain the feel of the project's early days.

I've limited my article to the scope of concerns I have that I feel are stopping the entire project from progressing. There will be time to fix the small issues if (and only if) the project as a whole succeeds. If it doesn't, then the small nit-picky problems are going to be irrelevant anyway."

https://blog.emacsen.net/blog/2018/02/16/osm-is-in-trouble/

Democracy

My personal point of view :
OSM can't continue with it's current "eighties" structure as it's undemocratic.
The "rest" of the > 5 Million participants is not as nerdy to participate in unstructured mailing lists and edit "source code" to participate in a voting.
A couple of people think they got the ultimate wiki power and avoid progress. The way they act (without "social control") leads to the idea of "another wiki besides", means documenting outside OSM, probably on a modern platform which may also be handled by people with less IT affinity.

In the IT sector, there's currently a move away from the classic "waterfall" model
"requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams
[...] evolutionary development, early delivery, continual improvement, rapid and flexible response to change"
 Agile_software_development#Agile_vs._waterfall
 Kanban_(development)
If I have a look at the proposals and discussions, that's currently not the case for OSM, see the cited "small nit-picky problems" above.
There could be more space for failure (let's see what the majority chooses)
and more sense for standardization (define a general namespace format instead of discussing every single tag type and the naming).

Namespaces / Tagging (syntax) standardization

To give an idea how namespaces are currently used, I created a Namespace_tag_overview page. Feel free to extend or restructure it (Except those who didn't understand the principle, examples on the discussion page). There's currently a terrible mess with the shop=car "service" values, but it seems that nobody cares as I mentioned it twice on the mailing list and all that happened was the repeated removal of a hint to the tag users about this discrepancy. The namespaces of vehicle shops should (obviously) be harmonised, but the focus of active wiki users seems to be on discussion instead of standardisation, as some keep on nagging aroud instead of investing their time in a proposal how (else) to solve it (also see "Simple Sabotage Field Manual" above).It makes no sense to have prefixes (service:) that have no meaning, even if they have been approved.The same applies to "random" service tags. So what's so difficult in a simple namespace which just mentions the usual things offered by a shop like

  • *:sales=*
  • *:rental=*
  • *:parts=*
  • *:repair=*

Also see User:Rtfm/namespace_overview

Personal focus

At the moment, I concentrate on

According to German statistics [1], the number of registered motorcycles is approximately 10% compared to registered cars. Just for those who seem to think those POIs are irrelevant.
check shop=motorcycle or shop=boat.
The same system should work with a lot of shops, examples : User:Rtfm/namespace_overview
  • Nobody seems to have a clue (as often) what industrial=* stands for and when which object should be tagged with either landuse, office=company or anything else. Chris2map was so kind to create a sandbox page to figure out. Which is IMHO still not "state of the art" to find a solution (especially vote), but at least a start.
  • The problem with the shop=car services is still not solved and creates a lot of mess. Also thanks to the idiot who removed the hint about this problem :
An undiscussed [[2]] change to the ID editor lead to a confusing bunch of tags. The reason for this decision was apparently that service=* leads to conflicts. So better use the namespace mentioned below.
  • The office structure is also a mess and the troll army doesn't make it better (see top of this page).
Why not make a proposal to improve it then? --Jeisenbe (talk) 18:53, 21 November 2020 (UTC)

Glossary

"If a rule prevents you from improving or maintaining, ignore it."
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=User:Rtfm&oldid=2454976"