[Talk-us] A Friendly Guide to 'Bots and Imports
emacsen at gmail.com
Fri Aug 6 18:00:41 BST 2010
Good to see your comments getting through Katie (I was one of the
people who didn't get your emails before).
On Fri, Aug 6, 2010 at 11:59 AM, Katie Filbert <filbertk at gmail.com> wrote:
> On Fri, Aug 6, 2010 at 9:11 AM, Serge Wroclawski <emacsen at gmail.com> wrote:
>> 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
> The nature of OSM with few rules (compared to say the many rules on
> Wikipedia) is appealing in some aspects and I don't want to see OSM become
> burdened with so many rules.
> At the same time, we might learn some lessons from how Wikipedia handles
> 1) Anyone that wants to run a bot or new tasks for an existing bot
> (automated or semi-automated tasks) must submit a request to the bot
> approval group (BAG). Others are free to comment on the request, in addition
> to BAG.
> 2) You explain what the bot will be doing. The BAG assesses whether it's a
> good idea, and gives constructive feedback
> 3) Bot operators are encouraged to share the code, at least with BAG, but
> ideally make it open source so others can review it.
> 4) The bot then goes through a trial (e.g. doing 50 edits)
> 5) The bot runs on a separate account from the user's normal account. The
> bot account is flagged, so it's hidden by default from Special:RecentChanges
> and gets higher API rate limits.
> The bot's user page has information on who's running the bot, what it's
> doing, bot shutoff button that anyone can use if the bot is AWOL, info on
> how to contact the bot operator, and the bot operator needs to be
I think these are all very reasonable.
>> 2) When someone points out a widespread problem (such as the Salt Lake
>> City addresses), how do we want to proceed?
> I'm not totally convinced it's effective, but Wikipedia handles disputes and
> issues with "requests for comments" and tries to reach consensus. For
> something like the addresses, there may be not be 100% consensus but say,
> 3/4 agreement would be good, making compromises necessary to get there.
I think if we have a process like this, we'd want it more streamlined,
but I like the approach of having a validations and feedback period.
>> 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?)
> See above (1).
> Furthermore, Wikipedia users have gone as far as to create bot frameworks
> (pywikipedia) that are well-tested and there are tools (e.g.
> autowikibrowser) for semi-automated edits.
I agree with this. I don't think we need officially blessed bots,but
most of us have already made our own bot frameworks (I know I did), so
unless there's a compelling reason, why replicate the work?
Having a tool to display the changes is really important IMHO.
Sometimes those changes will be something where it'll be obvious and
rendering it as tiles would be good. Other times the changes won't be
something that renders, and we'll need to find a way to display the
differences in a meaningful way, but if we made a framework for it,
hopefully we could plug in that functionality as we went along.
> For OSM, something else we ought to do better with is using the dev API
> server (http://api06.dev.openstreetmap.org/). Last I knew, it's not
> populated with data except what individuals put in it. It would be great
> the dev server instead was a full, up-to-date mirror of OSM that people
> could use to test imports and semi/fully automated edits. I think this is
> especially important since, unlike setting up MediaWiki, it's not so simple
> for individuals to setup their own OSM stack
api06 is meant for testing out calls to the API. That's why I suggest
something else altogether.
I also think if we start something, it'll be easier to have it adopted
by the larger OSM community.
More information about the Talk-us