[Imports] NYC building + address import (was Re: Buildings & Address in Washington, DC, USA.)
Mikel Maron
mikel_maron at yahoo.com
Fri Jun 6 18:40:41 UTC 2014
> 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.
Nor is it a reasonable action of the Chair of the OSM Foundation to suggest "blocking" MapBox. I'm not defending MapBox or the import, but seriously, you are Chair of our Board and think that's ok communication from your position? And that's your main response to the situation?
> "not giving a changeset comment, or not giving enough information in a note "
Simon, read the blocks in question. These were only the reasons given. Perhaps what we ultimately have here is simply poor communication from the DWG. And now the Chair of the OSM Foundation.
-Mikel
* Mikel Maron * +14152835207 @mikel s:mikelmaron
On Friday, June 6, 2014 2:33 PM, Simon Poole <simon at osmfoundation.org> wrote:
>
>
>
>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> wrote:
>>>
>>>On Thu, Jun 5, 2014 at 8:55 PM, Alex Barth <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 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
>>>https://lists.openstreetmap.org/listinfo/imports
>>>
>>>
>>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20140606/1fae38f1/attachment-0001.html>
More information about the Imports
mailing list