<The DWG does not decide policies.> Thanks Paul, good to read that there is a segregation of duties because it's not DWG setting rules. A next step in DWG governance would be to have an open process, of which a nice example can be found here: http://wiki.openstreetmap.org/wiki/Open_Data_License/Community_Guidelines/How_We_Create_Community_Guidelines I'm still confused about the words guidelines and policies as they are being used in OSM. I hope MT/OSMF also decides on guidelines or other rules, not only on policies.
<All of these are addressed in the discussion paper,> I may have missed it, but where can I find that paper? <Having written regulatory guidance professionally, what was sent out was sent is closest to a discussion paper, not a policy proposal, intended to illicit viewpoints, not advocate specific requirements.> Thanks for this extra info. I found it difficult to read your first posting in this thread, not only becaused it missed a clear addressing of the problem and a LWG like process, but also because the word 'policy' was used in the title, and the body contained the words 'guidelines' and 'guideline requirements'. Because of the discussion in this thread I updated the threat section of our SWOT with the following two lines. * Unexperienced contributors cause a decrease of data quality * Biassed contributors cause a decrease of data quality I used two lines to express faulty contributions because of two causes: good intentions and bad intentions. Examples of the latter are contributors changing the Crimean boundaries, certain religious mappers wiping out Israel and sneaky companies deleting POI's of competitors. Feel free to improve the two lines. https://wiki.openstreetmap.org/wiki/Talk:Future#Threats Cheers, Johan 2014-06-20 23:03 GMT+02:00 Paul Norman <penor...@mac.com>: > On 2014-06-20 12:47 PM, Johan C wrote: > > However, I don't think it's a good idear that the DWG can decide on > > policies/guidelines/requirements etcetera because it's the same DWG that > > uses these policies/guidelines/requirements for enforcing. > > The DWG does not decide policies. That is one of the roles of the > Management team[1]. > > > > As broadly as you describe it, you could also be implying a policy onto > > HOT. For example, I have been armchair mapping in the Philippines, trying > > to do my best using sometimes bad satellite imagery (cloudy) to map roads > > in the Tacloban area. Or it could have also been tracks (difficulty to > > see sometimes), whereby I tried to use a tracktype which I'm sure was not > > always correct all the time. HOT is a larger organization, and I was not > > directly working for HOT but by using the tasking manager I was a remote > > mapper. > > You could also mean Maproulette, which seems to be a nice tool (I've > never > > used it) but which also promotes armchair mapping. And what about quality > > assurance tools: even when they are not signalling things right some > > mappers desperately want to solve any warning/error they come up with. > > I'm glad you brought up the examples of armchair mapping through the TM, > MapRoulette, and QA tools. All of these are addressed in the discussion > paper, > which specifically excluded them from the scope. > > > Of course you can reply saying I'm exaggerating. But is the DWG > _proposal_ > > Having written regulatory guidance professionally, what was sent out was > sent is closest to a discussion paper, not a policy proposal, intended to > illicit viewpoints, not advocate specific requirements. Points may be > included because members of the community have brought them up, not because > they came from a member of the DWG. > > [1]: http://wiki.osmfoundation.org/wiki/Management_Team/Statutes# > Policy_Procedure > > > > _______________________________________________ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk >
_______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
