> 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 <a...@mapbox.com> wrote:
>
>
>
>
>On Fri, Jun 6, 2014 at 6:29 AM, Serge Wroclawski <emac...@gmail.com> wrote:
>
>On Thu, Jun 5, 2014 at 8:55 PM, Alex Barth <a...@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@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/imports
>
>
>
_______________________________________________
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports
