Two requests to help us prioritize our work: When I receive e-mail via the OSM e-mail system, I also receive a message from my "real" e-mail account (my ISP) that a message has arrived at my OSM account. When the effort was made to contact all users who had not (as of that time) agreed to the new CT, was any record kept of the attempts that generated "bounced" messages (mail not deliverable, account no longer exists, etc.)? These mappers now are essentially unreachable, unless someone knows who is behind which mapper name. It would be helpful to know who can't be reached before deciding what data to try to re-map, and whom to try to contact, since some work is involved in doing either. If a record was not kept, it should be possible to generate one (only the "undecideds" need to be checked in this way). Of course, there is no guarantee that those whose messages don't "bounce" are in fact reachable, but the bounces would let us know which ones have such a low probability of being contacted that we can reasonably assume their data will disappear in the spring. Just flag them as "not reachable via the OSM mail system" and let active mappers act as they choose on the information.
Also, we mappers need a definitive list/map/tool to identify features that, based on current CT acceptance, will disappear, revert, or remain intact this spring. Comments made yesterday indicate that OSM Inspector is not definitive; that the average mapper cannot determine a record's status without understanding a secret decloaking device; that Potlatch does not highlight everything that even the OSM Inspector designates as being at risk of removal or reversion (giving false positives and false negatives; I have identified one of each in the area I map); and that some other tools that have been shared do not look far enough back in a record's history. It would be very helpful, as soon as possible, to have a definitive tool which shows what stays, what goes when the license changes, and what is uncertain (because the pivotal mappers(s) has/have not yet said "yes" or "no"), and which updates as the undecided mappers are contacted or as objects are remapped and the originals are removed. It is obvious that such a tool has to be developed in order to target and remove the data. If it takes until April 1 to come up with the tool, then the deletions really should be postponed until a few months afterward (yes, on a fixed schedule) so that the rest of us have time to make effective use of the tool. Right now we are remapping and contacting in the dark. Bad customer service is "We are changing things, you deal with it." Good customer service is "We need to make some changes, we understand that this is disruptive, we want to make this as easy as possible for you, here is what we are doing to help you during the change, and although we definitely are going to make the change, we are open to suggestions about how to make the transition less onerous." I am hoping that the work that Mikal Maron mentioned to respond to comments made yesterday will lead to making better information available. Ed Hillsman _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
