[Talk-us] A Friendly Guide to 'Bots and Imports

Serge Wroclawski emacsen at gmail.com
Fri Aug 6 14:11:17 BST 2010


Moving away from discussions of specific imports, I'd like to explore
what people think about a few areas of this discussion:

1) When someone says "I want to import X", what should our first response be?

2) When someone points out a widespread problem (such as the Salt Lake
City addresses), how do we want to proceed?

3) Is it better to discourage bots and imports (as we do currently) or
better to heavily document bots and set up standardized methods? (and
do people think those methods will be used?)

4) In the US, what (if any) role should OSM US play in imports?


And now my .02:

1. I think the first reactions to a request to import should be
something that outlines the danger to OSM of importing. That's the
guide this thread talks about. We want to instill on the user the
potential pitfalls and encourage them to work with the community-
maybe even discovering that the data set was known previously and not
imported for a reason.

2. I think widespread "bot fixes" should be encouraged to wait 10
days. It's just too easy to make a large change and too hard to fix
it. I'd also suggest that we (as a community) develop tools to make it
easier to demonstrate what an import or bot would do on a test server.

Imagine I want to fix all the streets in Cleveland. I could spin up an
instance of Cleveland as of a certain time, apply my changes to that
test site, and show it off to the large community, soliciting
feedback.

This isn't really feasible right now using existing OSM methods.

3. I think imports and bots are inevitable, so the more documented we
make the process, the less we encourage people to go wild and write
their own. At the same time, we want to discourage bots and imports in
general.

4. I think OSM US can play a significant role in two ways. I think the
organization can help by working with governments to make data sets
available. And I think it could possibly help with some equipment and
infrastructure. Those are why I'm involved in OSM US now, and (blatant
plug) why I'm running for office on the next board.

At the same time, I think the process needs to be bottom-up community driven.

- Serge



More information about the Talk-us mailing list