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 <[email protected]> wrote: > > > > > On Fri, Jun 6, 2014 at 6:29 AM, Serge Wroclawski > <[email protected] <mailto:[email protected]>> wrote: > > On Thu, Jun 5, 2014 at 8:55 PM, Alex Barth <[email protected] > <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > https://lists.openstreetmap.org/listinfo/imports > >
_______________________________________________ Imports mailing list [email protected] https://lists.openstreetmap.org/listinfo/imports
