[Imports] NYC building + address import (was Re: Buildings & Address in Washington, DC, USA.)

[Simon Poole]

While I don't find it acceptable in the first place that we are policing
individual employees of a third party instead of the employer taking the
responsibility and carrying the consequences of misbehaviour, I can see
how we got in the situation.

I would suggest that the DWG produce a short report on what has taken
place so that we get a more complete picture, in particular given that
we do not have any background in the case of sorein.

That said, I do not see an issue with the events wrt the NYC import as
they unfold on github, given that the mappers in question were not
blocked for " not giving a changeset comment, or not giving enough
information in a note ", but for not responding to the DWG, but maybe
the report can shed some more light on that.

As said above, I don't think policing individual employees of a 3rd
party (including sending them individual messages etc) is a reasonable
use of our limited resources, particularly when they are non-responsive
and would suggest simply blocking the whole organisation going forward.

Simon

Am 06.06.2014 18:43, schrieb 'Mikel Maron' via board-with-guests:
> > The only thing that I've found that they do respond to consistently is being blocked by
> the DWG.
>  
> That is disturbing to hear.
>
> User blocks are a tool of last resort, when someone is doing serious
> harm to OSM. Like deleting objects randomly.
>
> That just doesn't compare to situations like not giving a changeset
> comment, or not giving enough information in a note. Minor issues.
> These are not conventions to be enforced by blocking.
>
> http://www.openstreetmap.org/user_blocks/465
> http://www.openstreetmap.org/user_blocks/471
>
> The DWG has a great responsibility to OSM, to be appropriate and
> measured arbitrators of data issues. The great deal of the work done
> by the DWG is beneficial, and I appreciate it. I was among the group
> that originally convened the DWG, and happy that we have this function
> with the OSM community. However, in some recent circumstances, the DWG
> is taking its responsibility much further than our collective and
> official expectation, and is simply abusing its authority in cases of
> clear of conflict of interest. And we lack accountability of when the
> DWG goes too far.
>
> So, I'm calling on the Board to take up the issue of setting clear
> limits on the the activities of the DWG. 
>
> Mikel
>
>
> * Mikel Maron * +14152835207 @mikel s:mikelmaron
>
>
> On Friday, June 6, 2014 12:31 PM, Alex Barth <alex at mapbox.com> wrote:
>
>
>
>
>     On Fri, Jun 6, 2014 at 6:29 AM, Serge Wroclawski
>     <emacsen at gmail.com <mailto:emacsen at gmail.com>> wrote:
>
>         On Thu, Jun 5, 2014 at 8:55 PM, Alex Barth <alex at mapbox.com
>         <mailto:alex at mapbox.com>> wrote:
>         The issue of responsiveness is straightforward. When a community
>         member finds a problem with how something is mapped and we go
>         through
>         the speicifc steps outlined in the import process, and the
>         individual
>         community members creating the problem are notified, I think
>         there's a
>         reasonable expectation that they'll stop. Maybe they'd respond
>         to OSM
>         messages, or respond to notes that they created, or respond to
>         github.
>         My experience is consistently that with your mapper staff that
>         they
>         simply don't respond to any of these. The only thing they've
>         responded
>         to is DWG intervention (ie blocks).
>
>
>     As stated earlier. Working on getting better responsiveness in
>     place. I think we've made good first steps. Let me know any time
>     you run into specific issues.
>      
>
>
>         That's a really huge hammer to have to bring down, but the
>         alternative
>         is that there's bad data in OSM.
>
>         The second issue is cleanup, which ties very much into the
>         first one.
>         There would be no big problem with waiting days and needing to
>         contact
>         three or four people before getting a response, if the data didn't
>         stay bad. But instead, we see data that was put in badly and has
>         stayed bad. It's really a mess, which could have been fixed if the
>         attitude had just been to go a bit slower and when someone
>         brings up
>         an issue, to take it seriously and not ignore it until days later
>         (importing with the problem in the meantime).
>
>
>     The data we're importing in NYC is very very good. Sure, it's not
>     100 % without problems, no data is, but it is absolutely _not_ "a
>     mess". We have stopped and reviewed and fixed the import and
>     imported data time and again - often on your request. We just 100
>     % don't agree on the overall assessment here and I'm not sure how
>     you can get to the perspective you're sharing above. If there are
>     specific problems, please flag them on the tracker
>     github.com/osmlab/nycbuildings
>     <http://github.com/osmlab/nycbuildings> and we'll review.  
>      
>
>         Consider this... I still haven't seen an affirmative statement
>         that
>         you're going to use paid mappers, yet the subtext is that this
>         is what
>         will happen. If you're going to use paid remote mappers, just
>         say so.
>         Just say "This is our plan." 
>
>
>     The DC import plan is not saying anything about the Mapbox team
>     mapping on it because that's right now not the plan. I'd love to
>     see the DC government lift this themselves - this would be an
>     amazing story. I'd be happy to help though if needed.
>
>     In regards to NYC, I've said very clearly at the first community
>     import session in NYC that our team will be mapping too. You've
>     confirmed hearing this to me earlier I hope you still remember but
>     you also said that it wasn't clear to you to what extent we'd
>     engage. It's my regret that I didn't spell out clearer what this
>     meant to me. 
>
>     Look, I want to build over time an excellent data team helping to
>     make OpenStreetMap the best map in the world. I want them to be
>     hands on with improving data in OpenStreetMap in the most
>     responsible way possible. For initiating an import like the one in
>     NYC I would love also the next time not only to work with
>     community closely to make sure it's done right and responsibly,
>     but also have community directly help hands on do the import. At
>     the same time, I also need to be able to say it's done in a
>     certain time (NYC stands to take about 9 months total, that's
>     longer than I thought, but fine) and I need to be able to
>     guarantee that it's being finished at some point. I don't ever
>     want to be associated with a half-imported dataset. So if Mapbox
>     takes the initiative on an import, we will always have to be ready
>     to see it through ourselves rather than let it peter out. Again,
>     talking about the grunt work here. I am open for feedback from A-Z
>     throughout the process and I've also learned that engaging
>     community means doing things at a certain pace - for instance you
>     remember that the initial time schedule for the NYC import was way
>     too ambitious.
>
>     Again, to be very clear, the DC proposal comes from the DC
>     government and I'm right now not thinking that this is an import
>     where Mapbox needs to take the ultimate responsibility to see it
>     through, and again, I'm more than happy to see whether we can help
>     David Jackson and team if needed.
>
>     Alex
>
>
>
>     _______________________________________________
>     Imports mailing list
>     Imports at openstreetmap.org <mailto:Imports at openstreetmap.org>
>     https://lists.openstreetmap.org/listinfo/imports
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20140606/c3c5ef57/attachment-0001.html>