Hacker News new | ask | show | jobs
by Grimburger 1357 days ago
The last time I submitted a few months worth of my travels at once after doing a hundred or so of these challenges/questions and got a bunch of notifications lambasting me for not updating the moment I did instead of later. Honestly didn't realise you had to manually submit, thought it just happened automatically.

Was a really rude intro to the community and reminded me a lot of SO or Wikipedia with its gatekeeping.

I've never submitted a single thing since then. If that's how you treat newcomers then I want nothing to do with you.

9 comments

It does happen automatically, pretty sure it's always worked that way. Maybe you experienced a bug?

> The user's answer is automatically processed and uploaded directly into the OSM database.

https://github.com/streetcomplete/StreetComplete/

Of course uploading a few months of changes all at once is going to cause issues, naturally some will conflict with other changes that have been made in the meantime.

There is a setting that disables autoupload. Some people may want to minimise the number of edits made from their account, and some people may not want to leave a trace of locations they've visited together with exact timestamp they've been there.
As someone who belongs to the OSM community, I am sorry that you had this experience. Gatekeeping is an unfortunate byproduct of a crowdsourcing project, it seems.

I hope you reconsider and try again. Many of us are actually here to help.

> Honestly didn't realise you had to manually submit, thought it just happened automatically.

It happens automatically in default configuration.

You can enable manual upload in settings if you want, but then, well, you need to upload it manually.

I am contributor to StreetComplete - so maybe I will add feature to start reminding about upload if edits are old.

I've seen some gatekeeping in the OSM community as well. In this specific case, this is also (in my opinion) due to bad tooling. Basically the easiest way to keep an eye on an area is to use a tool that shows changesets whose bounding box includes a certain area. So you could make a single tiny edit in both NY and LA, the bbox would ping a huge swath of the US. This happens all the time, actually. It's annoying, but the way I see it that means we need a better way to see changesets that actually affect a specific area.
yah the change set visualization could indeed use a lot of love. I think it would be worth it, something like beyond compare's image diff could be a good start in the right direction https://beyondcompare.gitbook.io/project/other/how-to-compar...
OSMcha and a few other tools are probably much better suited for that purpose.
> Honestly didn't realise you had to manually submit, thought it just happened automatically.

in my experience, you don't have to manually submit in streetcomplete, and it does happen automatically.

> a few months worth of my travels

Was this travels in your local neighbourhood, going home daily, or one trip to another country or in a very rural area? I'm asking if you had constant data connectivity, intermittent, once daily, or none during that time?

It sucks to have a bad first experience from a Gatekeeping community. Of course, as newbs, we try to move slowly with small changes first to test the waters. That worked for me, sorry that it did not work for you. I also take the point that was raised about not editing based off months-old data.

If that's how you treat newcomers then I want nothing to do with you.

OSM is like Wikipedia for maps. Complete with all of Wikipedia's baggage and wannabe bureaucrats.

Funny, I've had a similar experience, and stopped contributing because of it. My case was even more egregious as autosubmit _was_ enabled on StreetComplete, but unbeknownst to me at the time such submissions are batched, so if you edit local places that you're visiting (vacation) and places far away that you're intimately familiar with (home), it can still end up in one big changeset that spans an enormous geographical area... After that I had a couple of folks breathing down my neck and nitpicking every change -- and one of them tried to support their snark with http://linuxmafia.com/~rick/faq/crybaby.html, which is possibly the stupidest writeup I've ever seen -- no, thank you, I can take my contributions elsewhere.

OpenStreetMap has strict demands on how contributors should structure their changes, but has no way to enforce them. The best it has is having someone review your changesets _after_ they've been already submitted, when it's too late as the "damage" is done. Start implementing a technical solution to problem, instead of disciplining the ones who are volunteering their time trying to curate your dataset for you.

(Also, if StreetComplete is a repeat offender, start a conversation with its devs instead of reprimanding users.)

The devs are unwilling to automatically split changesets spatially. The main reason is that the app is intended to be used on foot, maybe bike, mapping only a small area and doing all that on the ground where you actually are. So mapping from images or memory runs afoul of that intention anyway.

Granted, that still doesn't solve the case that you may have no connectivity and are basically forced to upload a big batch later. It annoys me a bit as well.

On the other hand, despite how angry the changeset comments may read, this isn't a big deal. Globe-spanning changesets happen all the time and yes, they do annoy local users trying to keep a watch on what happens, but the history on the OSM site isn't really well-suited for that either. Also, with enough other changes, those large changesets also fall out of the history range fairly quickly, except in places where no one maps anyway.

> On the other hand, despite how angry the changeset comments may read, this isn't a big deal.

Then why be angry about it at all? It either is worth gatekeeping about our not, decide.

> Globe-spanning changesets happen all the time

I noticed! But this only makes it worse. That's precisely my point: the requirements are there but can't be enforced and then the matter is addressed with... hostility between contributors? Who's benefiting from this behavior, exactly?

I don't really know. There are guidelines and promoting those guidelines to new users can be beneficial. I do sometimes comment on changesets by other users where this happened with the use of normal editing tools (iD, JOSM) where some more care can really be taken (JOSM even warns about large changeset boundaries). But I try to phrase it as a friendly reminder, not so much a broken rule.

Some things like reverting vandalism or fixing large geometries like coastlines or motorways often make large edits necessary anyway. And often it just happens by accident. I have added some cleanup changes to the wrong changeset more than once and then got a changeset for a whole continent. The immediately visible history on the OSM site soon ceases to show that changeset and another will take its place, so personally I don't see much of a problem to get worked up about.

So my stance is basically: It happens, we can't really prevent it anyway (although I'd love a spatial auto-split in StreetComplete and JOSM – Every Door has it, I think), and as long as the norm is that people try to make smaller changesets, I guess we can live with that.

i've been using streetcomplete for a long time now, i just keep the mobile data on and it keeps uploading fixes and stuff as we go.
This is terrible. I have no experience with it myself, but if OSM wants community contributions, they need to make sure that people feel welcome to contribute. Lambasting people for getting something wrong is not helpful. Thanking them and advising them how to do it better next time would be much better.
> Thanking them and advising them how to do it better next time would be much better.

Thanking them and advising is the recommended way to handle this.

Unfortunately, as happens in all large crowdsourced areas, some don't adhere to the recommended ways and "do their own thing", often to the detriment of the project as a whole.