Talk:Automated Edits code of conduct

From OpenStreetMap Wiki
Jump to: navigation, search

/Archive

Discuss Automated Edits/Code of Conduct here:


Uncontroversial edits

A more general objection to this policy is that it imposes an excessive amount of bueraucracy even for uncontroversial edits. Creating a wiki page before fixing, say, straightforward typos like "traktype=grade4" is totally unnecessary in my opinion - that much can be adequately documented in the changeset comment. I think it is fine to use your judgement whether or not an edit is potentially controversial, and skip the paperwork when it is not. --Tordanik 02:57, 20 May 2012 (BST)

Makes sense to me. It gets more political when one decides that 'yes' should be 'true' of course. Typo fixes, like converting 'tru' to 'true' or 'ys' to 'yes' for a boolean tag sounds good. Wikipedia uses them all the time. PeterIto 11:51, 31 May 2012 (BST)
But what's an "Uncontroversial edit". Talking to people after they've done a bad thing with a wide-scale bot edit, they almost always believed they were making an uncontroversial change at the time. Creating a wiki page is easy, but if it's too much hassle for somebody... It begs the question, are they going to the hassle of thinking about what they're doing at all??
In fact I think we should start back-dating the rule about a wiki page per import/edit to all previous automated edits. With a page naming convention we could seek to catalogue a lot of them. We can create stubs with some information even if we have zero input from the user concerned. Then in these cases we start to build a list (wiki category) of users who didn't bother documenting their activity (name and shame)
I can accept that there are shades-of-grey cases where it's only sort of very semi-automated (searching over a small area in JOSM) These cases go under the radar anyway, and if for some reason they're not under the radar, then the policy applies. Wiki page please.
- Harry Wood 18:44, 31 May 2012 (BST)
If you think that "uncontroversial edits" is too broad, let's look specifically at a common class of truly uncontroversial edits: "typo fixes". You will usually not mistake your mass edits for typo fixes if they aren't. These are practically never being discussed in advance, happen frequently and often cover a wide area. Nevertheless, they don't cause trouble, and they are useful, not the least because due to the way some editors work (e.g. using nearby tags, including possible typos, for auto-completion). --Tordanik 19:14, 6 June 2012 (BST)
I agree with this 100%. Otherwise it is sad to see typo-ed data sitting in OSM without any way to fix them (this policy is too complicated and even unacceptable to some users) and knowing users even took the effort to put data into OSM but it will be ignored by software due to accidental mistakes. - aceman444 23 Aug 2013
Just one problematic issue which came to my mind: Hmm, and what if you did not think of the "traktype=grade4" which describes the type of "trak"? A trak is a special type of meadow in South Korea for child play and sports... (no, not really, just an example). Others may spot such problems if you discuss it before. --Aseerel4c26 (talk) 18:53, 11 February 2014 (UTC)
In the very unlikely case of undocumented and unmentioned tags which look like commonplace typos, we can still correct the mistaken edit after the fact. It's not as if discussions are a panacea: Even with a discussion, mistakes will slip though, and if people would really discuss every trivial correction, then soon nobody would even read such threads anymore. Ultimately, the goal of any rules should not be zero risk - there has never been a zero-risk edit in OSM -, but the best ratio of risk, effort, and reward. And after proper research, typo corrections in general have a very low risk of going wrong. Most of them just silently make the database a little bit better. --Tordanik 05:59, 12 February 2014 (UTC)
The problem is that it is not possible to know what is controversial and what is not without a discussion Mateusz Konieczny (talk) 11:19, 29 May 2018 (UTC)

Veto

The clause "Provide a means for mappers to "opt out" of your changes, i.e. if someone contacts you and asks you to stop making automated edits to things that they have edited, you must comply with that wish, and you must modify your software or procedure to leave those objects untouched in the future" is impractical and over-restrictive. Where - if ever - was consensus for it reached, and does that still hold? Users should not have a veto over others' edits. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:52, 6 June 2015 (UTC)

Good point. To be clear, although I have done a lot of editing on the wiki over the past months, I have tried not to change the meaning. However, I do think it will be useful to discuss and challenge this statement. The guidance from WP, Ownership of articles may be worth reading. PeterIto (talk) 15:57, 7 June 2015 (UTC)
Users don't have a veto about other users' manual edits, but about other users' mechanical edits because a manual edit represents a bigger commitment than an automated edit. The latter is considered generally less valuable. --Frederik Ramm (talk) 16:55, 9 May 2016 (UTC)
I understood that the context was mechanical edits when I asked my questions; this is after all the talk page of the "Automated Edits code of conduct", and it is that page which I quoted. Would you care to justify your claim that "Users... have a veto... about other users' mechanical edits", by answering my questions? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:31, 30 May 2017 (UTC)

Rules for Robot/A.I. Mappers

background: Robot Mappers , machine-learning and artificial intelligence (“robot”) techniques ; http://mike.teczno.com/notes/openstreetmap-at-a-crossroads.html

Maybe, in the future we need some ethical suggestions, like

  • "Robot mappers must be designed to assist humanity" meaning human autonomy needs to be respected.
  • "Robot mappers must be transparent" meaning that humans should know and be able to understand how they work.
  • "Robot mappers must maximize efficiencies without destroying the dignity of people".
  • "Robot mappers must be designed for intelligent privacy" meaning that it earns trust through guarding their information.
  • "Robot mappers must have algorithmic accountability so that humans can undo unintended harm".
  • "Robot mappers must guard against bias" so that they must not discriminate people.

based on Satya Nadella's A.I. laws —Preceding unsigned comment added by ImreSamu (talkcontribs)

Note we have page called Bots. That's mostly listing robot mappers, but referring back to Automated Edits code of conduct here for policies.
That's some interesting Laws of robotics. More concretely in the short term we want bots to be documented and discussed, same as any automated edit, as a way of helping to ensure they will not mess up the map data (and the principles within those Laws of robotics would come up in discussions e.g. if a proposed bot looks like it's going to destroy the dignity of people!)
But yes. Maybe we should give more consideration to bots on this page. I suppose the key difference with bots versus other automated edits is that bots are editing on a regular/ongoing basis. If we look at wikipedia's policy on Bots, they require them to go through an approval step. Approved bots receive a special flag on the user account. We could develop a similar flag as a feature in our core rails app if we wanted such an approval process.
-- Harry Wood (talk) 01:21, 2 April 2017 (UTC)
Note that on Wikipedia bot flag has effects that would not have any effect in OSM. 1) hides edits from recent changes (OSM history tab is utterly dysfunctional anyways), 2) allows higher edit rate - I never run into edit rate limitations - with manual or bot editing Mateusz Konieczny (talk) 11:21, 29 May 2018 (UTC)
"meaning that humans should know and be able to understand how they work." is already covered by "detailed description of the algorithm you will use to decide which objects are changed how" requirement Mateusz Konieczny (talk) 11:23, 29 May 2018 (UTC)
"meaning human autonomy needs to be respected" it is not clear for me what is the meaning of this rule Mateusz Konieczny (talk) 11:23, 29 May 2018 (UTC)

when wiki page is mandatory

I reread the guidelines and encountered "You should normally document your proposed edit at an English-language wiki page". Can somebody clarify that? I am making some Poland-specific changes approved by Polish community - is it still necessary to create Wiki pages? Mateusz Konieczny (talk) 11:12, 27 May 2018 (UTC)

clarify that country specific dead communication channel should not be used

"if your edit affects only one country or territory then the national-language mailing lists, forums, or other standard communication methods for the territory affected by the change" - I would rephrase it as "if your edit affects only one country or territory then the standard communication methods for the territory affected by the change - typically national-language mailing lists or forums" to make it 100% clear that for example posting on dead Polish language mailing list does not count Mateusz Konieczny (talk) 11:15, 27 May 2018 (UTC)
https://wiki.openstreetmap.org/wiki/Talk:Automated_Edits_code_of_conduct
wiki.openstreetmap.org
crawl=CC-MAIN-2018-51
30697
application/http; msgtype=response
sha1:S34R4SESWEL6QEQJUHUHPC5PFCXEGY2N
<urn:uuid:15d0e121-2158-4ceb-9bac-6e070d4db6aa>
2018-12-16T12:57:27Z
130.117.76.4
text/html
sha1:X7GCH6NYY32ZSKU6QMIIYXQMZ6U45UIL
<urn:uuid:b6161ea6-ffb2-4ecf-948c-044338150668>
https://wiki.openstreetmap.org/wiki/Talk:Automated_Edits_code_of_conduct
response
<urn:uuid:09ea782c-f416-4551-8273-99d409937a18>
isPartOf: CC-MAIN-2018-51
publisher: Common Crawl
description: Wide crawl of the web for December 2018
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-145-10-101.ec2.internal
software: Apache Nutch 1.15 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 0.11-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: http://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/