Ok folks. Now that I'm off a train and can more properly respond to this thread:
We're going to stop discussion about DWG on this list. These are important questions to ask, but this topic should be moved over to legal-talk@ or talk@ or something. Unless you have something to say about the DC building import proposal itself, please don't respond. -Ian, your friendly imports@ moderator. On Fri, Jun 6, 2014 at 1:54 PM, Simon Poole <si...@osmfoundation.org> wrote: > > Am 06.06.2014 20:40, schrieb Mikel Maron: > > > 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? > > Yes, and I don't actually believe we have " a situation" outside of > you desperately wanting to turn this in to one. > > > "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. > > > Given that we are not privy to the communication prior to the blocks, > until I hear or see something different, I have to assume that the DWG has > not suddenly gone rogue and is telling us what really happened. You seem to > be assuming without any obvious reason that the opposite is the case. > > Simon > > > -Mikel > > * Mikel Maron * +14152835207 @mikel s:mikelmaron > > > On Friday, June 6, 2014 2:33 PM, Simon Poole <si...@osmfoundation.org> > <si...@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 <a...@mapbox.com> > <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 > >
_______________________________________________ Imports mailing list Imports@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports
