Talk:Automated Edits code of conduct/Archive 1

From OpenStreetMap Wiki
Jump to navigation Jump to search

Overwrite race

The guidance reads: "do not simply use yesterday's planet file as a basis for uploading changed objects as this would break changes made in the mean time". Is this still true with the 0.6 API and optimistic locking? It seems to me that the OSM server woudl reject the edit and answer with "conflict". User:Jrouquie 18:52, 4 August 2009

Optimistic locking certainly helps. Maybe this text should be altered in some way to reflect that. However the problem doesn't go away entirely. For example if you have a database of postboxes, and then you do buffer comparison with existing OSM data, to figure out which ones need adding... better make sure you're working from reasonably up-to-date data from OSM because optimistic locking won't prevent you adding a duplicate. -- Harry Wood (talk) 17:49, 26 March 2015 (UTC)

Proposed merge with other pages

I've removed the merge proposal links, as there's been no updates or discussion on the merge in two years. See also the Talk:Mechanical Edit Policy page. zool 10:32 27 Dec 2014

The Mechanical Edit Policy merge to here was since carried out (March 2015). See Talk:Automated edits policy#Merged to 'Automated Edits code of conduct' -- Harry Wood (talk) 15:24, 19 May 2015 (UTC)

Merged content from 'Talk:Automated edits policy'

This section is a cut and paste merge of the contents of Talk:Automated edits policy. The page itself was merged into this article some time ago, and it seems appropriate to bring the discussion with it. PeterIto (talk) 06:54, 20 May 2015 (UTC)

More work needed?

This policy seems to be unfinished. The example link is to a non-existent article and there is no Mechanical Edits category (to which one is required to add one's pages). Should this article not be completed? When it is complete can we redirect the Automated Edits code of conduct article to this one? PeterIto 09:57, 21 January 2012 (UTC)

Alternatively, should we update the Automated code of conduct with the text in this article? PeterIto 15:53, 21 January 2012 (UTC)
Old discussion. I think the unfinished points described have been long since finished, and the pages merged -- Harry Wood (talk) 01:59, 2 April 2017 (UTC)

Mechanical or Automatic?

Do we need to introduce a distinction between Automated Edits and Mechanical Edits (note that there is no article yet for 'Mechanical Edits' yet)? Personally it seems better to stick with one term. Please join the discussion this point on Talk:Automated Edits in the 'Terminology - Automated edits, bots or Mechanical edits? ' section. PeterIto 15:52, 21 January 2012 (UTC)

Proposed move Mechanical Edit Policy -> Automated edits policy

I propose moving this page to "Automated edits policy". Any thoughts, for or against? PeterIto 11:56, 31 May 2012 (BST)

As discussed Talk:Automated Edits#Terminology - Automated edits, bots or Mechanical edits? ...I agree with the move. I think it makes sense just to align terminology. Which is the more "correct" terminology is much-of-a-muchness. Is User:Frederik Ramm ok with a rename? (he wrote this policy as part of his Data Working Group work) -- Harry Wood 18:52, 31 May 2012 (BST)
There is a difference between Mechanical and Automated edits. All automated edits are also mechanical but not all mechanical edits are automated. We chose the wider-scoped name "mechanical edits" to make it absolutely clear that loading 100 objects through the XAPI and "manually" making a bulk change to them in JOSM is also covered by the policy. I'm happy to defer to native speakers but I fear that "automated edit policy" would be judged by many as not applying to their particular edit. - What about the term "bulk edit"? --Frederik Ramm 19:48, 31 May 2012 (BST)
Well you're the main creator and user of the page (I presume you link people to this a lot with your DWG activities) so I don't think we should move it if you're not happy to do so.
There's a certain elegance (and less terminology introduced) if we just have a trio of pages Automated Edits, Automated Edits code of conduct, and "Automated Edits policy". Obviously that's only a good idea if "Automated Edits" always means the right thing
I think loading 100 objects through the XAPI and "manually" making a bulk change, could still perfectly well be described as an "automated edit" (equally well as describing it as a "mechanical edit" really). In fact the page Automated Edits does already say "the term is also applied to" the XAPI thing. We could make that clearer.
...or just leave as is.
-- Harry Wood 09:40, 1 June 2012 (BST)

The pages are also inconsistent at the moment regarding where to "document" stuff on the wiki. Here on Mechanical Edit Policy#Document it says create a subpage of Mechanical Edits, and we can see a few people are doing that. But then over on Automated Edits code of conduct#Document what you have done, or are doing it directs people to add to Automated Edits/Log. -- Harry Wood (talk) 10:10, 5 June 2013 (UTC)

I'm removing the proposal link from the top of the page; as it has been a year and a half since the inconclusive discussion, it looks like this proposal has failed. -- zool 10:00 27 Dec 2014 (UTC)

Following this, see discussion below. (User:Peterito has since done the rename and then further rationalisation)

Local mailing lists

The policy suggests using "national-language mailing lists" for announcing the edit. I think that a the regional mailing lists that exist e.g. in Germany are much better suited if only that area is affected by the edit. For example, if I was planning a mechanical edit of bus stops in Berlin, then the Berlin mailing list would be a better choice than talk-de. So I suggest adding "The regional mailing list for the region affected by the change" to the list in the "Discuss" section. Tordanik 02:57, 20 May 2012 (BST)

Makes sense to me. PeterIto 11:53, 31 May 2012 (BST)
Old discussion. Seems that was fixed back then "or if your edit affects only a town or small region, the local mailing list, forums..." -- Harry Wood (talk) 01:57, 2 April 2017 (UTC)

Moved to 'Automated edits policy'

I have moved this page from 'Mechanical Edit Policy' to 'Automated edits policy' for the reasons discussed above. This is part of a wide ranging set of edits to clarify the whole subject of bots, automated edits and mechanical edits etc etc. Feel free to discuss this as I will be working actively over the next month or so. PeterIto (talk) 14:59, 10 March 2015 (UTC)

Merged to 'Automated Edits code of conduct'

Am doing a bunch of rationalisation about the area of bots, mechanical edits, automated edits and the associated categories. It does now seem logical to merge the content from this article into Automated Edits code of conduct which covers an almost identical subject with many of the same headings. Happy to discuss what I am doing here. PeterIto (talk) 17:15, 10 March 2015 (UTC)

I have now completed a merge of this article into Automated Edits code of conduct and converted this article into a redirect. Will now complete the integration of the combined content. PeterIto (talk) 10:59, 11 March 2015 (UTC)

Nicely done. Seems like a good rationalisation to me. -- Harry Wood (talk) 18:04, 26 March 2015 (UTC)

Automated edits deleting legitimate content should not be condoned

The following section does not seem to fit with the rest of the page :

"In cases where edits that are in violation of this policy are so closely mixed with "normal" edits that it is difficult to tell them apart, it is possible that reverting the problematic edits will also cause some collateral damage among the "normal" edits."

This legitimize reversal (automated edits) without verifications being done, which is in direct infringement of the AE CoC.

Please note that this section was added after a DWG member reverted 80 changeset as it was believed that they were mecanical, but 14 of them were not (changeset 27888534). --Gileri (talk) 20:20, 13 September 2016 (UTC)

First you start a changeset discussion on http://www.openstreetmap.org/changeset/27888534, then when you're not happy with the outcome you discuss it on the mailing list https://lists.openstreetmap.org/pipermail/talk/2016-July/076291.html and when you don't get the desired support there you try to start a discussion here. I added the section above precisely to warn people to *not* closely intertwine legitimate edits with policy-ignoring mechanical edits after you complained that some legitimate edits were lost in this revert. This is unavoidable and it will happen in the future if people don't adhere to the rules. I told you time and time again that, if the editor in question had made the smallest effort to properly document his mechanical edits as the policy requests, the revert could have been done better. You seem to think that if the DWG reverts a mechanical edit that the revert is in itself a mechanical edit that has to follow the policy. If this settles the matter, I am happy to add the sentence "A revert of a mechanical edit by the OSMF DWG is not a mechanical edit and not subject to this policy". Otherwise I'd be happy if you could take your squabbling elsewhere because I am getting tired of it. There would not have been *any* problem if the user had not added the 64 changesets that you admit were mechanical edits, but you haven't *once* seen a fault in the user's action - all you can talk about are the 14 changesets that have been lost in attrition. This is not a sincere argument, this is just petty tit-for-tat. --Woodpeck (talk) 21:48, 4 September 2016 (UTC)
Okay I will not answer to the "personnal spikes". You seem to take discutions about reverts and AE very seriously. It is good to have a passionate debate, but no need to attack people for constructive criticism. I agree to the points in the AE CoC asking to make AE distinguishable from other more "handcrafted" changesets. However, there need to be verifications being made before reverting changesets (even more when multiple changesets are reversed). You can't ask contributors to jump so many hoops and invest so much time in order to be allowed a AE, but allow blind reversal of a lot of data at the same time. Before making the change you suggest to the CoC, don't you think it would be best to document the edit you are suggesting and secure a consensus before modifying a text which is so important for OSM ? --Gileri (talk) 19:15, 5 September 2016 (UTC)
I read again the thread on the mailing list, and tried to compile some kind of "vote" : in the 10 persons who have expressed a direct opinion on the current state of the AE CoC, 4 were in agreement with some or all of my suggestions, and 6 were fine with the current state. I found this discussion useful as it has shown a lot of different opinions and suggestions on AE-related things. So I don't think of this thread as negatively as you seem to do. --Gileri (talk) 20:20, 13 September 2016 (UTC)
I saw the addition of the sentence about edits "so closely mixed with "normal" edits that it is difficult to tell them apart". It seemed sensible addition to me. If you jumble together good edits with bad in a way which is difficult to unpick, and your bad edits (in this case "automated edits", but really any kind of bad edits) need to be reverted, then I'm afraid you are at risk of losing your good edits. Not that anyone will take any pleasure in doing it. We like good edits, and we want to keep them. But if you've mixed it all together, then that's the action we're left with. This is really just reminder about doing the sensible thing. It ties in well with advice already present in the Automated Edits code of conduct#Execute with caution section. -- Harry Wood (talk) 22:20, 6 September 2016 (UTC)
I think we all understand what is meant by this section. It is understandable to explain that in some cases it can be really hard to distinguish what the AE CoC consider "manual edits" and "automated edits". But this sentence is too permissive imo, as for example it has been used to legitimate the revert of this changeset for example. The main criteria to distinguish "automated edits" and "manual edits" is often the number of changes made, I think it's easy enough to just open the changeset and see the number of edits before reverting them. I (and other contributors I believe) can volunteer to check such changesets if DWG's members doesn't have the time to do so. --Gileri (talk) 20:24, 7 September 2016 (UTC)
The wiki page may have some explanation related to what DWG does, and Frederik's here representing DWG in this discussion so you might ask him to whether this is accurately reflecting the approach they take. You might have a discussion (here or on a different channel) about whether DWG is taking the right approach. But... "too permissive" ... we can't expect to adjust the contents of this wiki page to dictate to DWG what they can and can't do. That's not how this works. If anything this page is written by DWG to help them in their work.
So you're in the wrong place really. Discussing a bit more directly with them about this particular case seems like correct way forwards for you here, but it sounds like you've already tried and failed at this. Take a deep breath and try not to be too combative about it (you'll need to be the exact opposite in fact, in order to turn this discussion around) I know it fees like combat when someone reverts some edits, but seriously, take a deep breath. Understand the big picture situation regarding automated edits and building a map and a mapping community.
Good that you're volunteering to take the time to check such changesets. Without looking into the details, I think I'm right in saying that DWG will welcome folks doing this sort of thing, preferably on a local level, and preferably negating the need for their involvement at all.
The ideal thing would be when User:Test30 comes along and does automated editing in your area, you, as a local person, spot what they are doing and proactively point them at these guidelines, make sure they split out their edits (Plus maybe ask them to add a user description and describe what they're up to with automated tools, and ask them why their username is "test" when they're not editing the test OSM database etc etc. It doesn't need to be solely DWG's responsibility to have these discussions). I take it that didn't happen. DWG did a big revert. Now I imagine your input after-the-event can still be very useful. If you feel some good edits were lost, and you're volunteering to unpick that. The good edits could be re-applied. Work with DWG on it. Do it properly. It seems like a good way to help.
-- Harry Wood (talk) 12:05, 8 September 2016 (UTC)
That is one of the problem with this page : any member of the DWG can add any directive, and it becomes a "law" that no one can discuss : both of you (Harry and Frederik) totally dismiss the original argument, and tell me to "take my squabbling elsewhere".
I don't think that discussing privately with the DWG is the right approach, because as you can see, any argument become immediately met with harsh comments and dismissed, even in the open.
You imply that I don't understand OSM and what's it about, whereas you understand perfectly. I will not pretend I've been as much involved as you both in OSM, but I think I understand enough to be allowed constructive criticism on such matters.
As I said previously, if I spotted any edits like these linked in OP, I would have opened the changesets and read what they were about before taking actions like reverting. I feel like that's what is expected of contributors but the DWG seems above that.
Based on your whole answer, I can assume that you did not read about the changesets I linked, and that's too bad because it shows exactly what my OP was about. Instead you suggest that I pick up the broken pieces months after because the reverter won't admit that their revert was too broad and reinstantiate the wrongfully removed data. I think that's a tad condescending, but don't worry, I'm not combative about legitimate arguments, even if you seem to assume so.
A question to wrap it up : if the reverter wasn't from DWG, do you think this revert would have been kept ? --Gileri (talk) 18:47, 8 September 2016 (UTC)
As people who all sincerely think they’re doing the right thing for OSM and the community clearly aren’t seeing eye to eye, maybe we could organise a conversation about this at State of the Map.--Andrew (talk) 11:35, 7 September 2016 (UTC)
That's a good idea, some people may prefer discussing IRL over issues like this. --Gileri (talk) 20:20, 13 September 2016 (UTC)
@Woodpeck «If this settles the matter, I am happy to add the sentence "A revert of a mechanical edit by the OSMF DWG is not a mechanical edit and not subject to this policy".»
How legitimate would that be? For the first time, the DWG would have a special status when dealing with AE despite it's mission being dealing with copyright violations and serious dispute/vandalism. Theses missions require the power to block accounts but not AE issues. (most don't end up in beeing serious desputes/vandalism)
About reverts being AEs: I agree that a revert of a problematic AE is not an AE. Of course one shouldn't revert a changeset without checking if it's a problematic AE but considering a revert an AE will add more complexity and won't help resolving disputes. --Tuxayo (talk) 11:12, 25 September 2016 (UTC)
I don't think this section can justify changeset 27888534 as they are independent changesets with a limited number of objects and a limited area. Of course I do feel that it's here to justify changesets 27888534 as it was added after the discussion on this changeset. But I don't think it actually justifies it as changeset 27888534 is out of this scope IMO. But anyway, changeset 27888534 has it's own discussion.
To get back to this section I don't think adding it was a good idea. It's obvious that a changeset where there is a mix of automated and manual edits will lead to collateral damage if revert is needed. Adding a paragraph each time there is an AE revert controversy won't avoid them in the future. --Tuxayo (talk) 11:12, 25 September 2016 (UTC)
It's obvious, but you don't think stating it is a good idea? Like I said before, it's really just a reminder about doing the sensible thing. It's an improvement to the advice on this page for people doing automated edits. But yes it's also a thing which sadly people will only read in detail after doing an automated edit and seeing get reverted. In that situation it serves as information about the thing they did wrong which has caused all of their tangled edits to be reverted (although... y'know... it was obvious anyway right?) -- Harry Wood (talk) 01:44, 2 April 2017 (UTC)

Real name

  • Who is making the change (real name and how to contact, ideally e-mail address)

I don't see why publishing your real name should be required - that's uncommon in the OSM community outside the mailing lists. A possibility to contact the responsible mapper is necessary, of course, but otherwise an OSM username is sufficient. --Tordanik 02:57, 20 May 2012 (BST)

Agreed. OSM name should be sufficient, as long and the editor commits to response to messages through it. PeterIto 11:48, 31 May 2012 (BST)
Even though it's a sensitive topic, I also agree that the real name should not be necessary for automated edits. Gppes 18:31, 1 April 2017 (CET)
I suppose having a real name might avoid some sockpuppet problems (possibly... maybe... not really). It can also make it easier to cross-reference to other contact channels. But yeah, as a hard rule, it's problematic for those folks who like to keep their real name secret. As it hasn't been fixed since Tordanik raised it in 2012, it seems nobody has objected very strongly to this rule over the years. But I agree it could maybe be changed to just say "preferably" give your real name. -- Harry Wood (talk) 02:10, 2 April 2017 (UTC)
The reason why there was a comment after five years of silence is because of a discussion about improving privacy for OSM contributors which started at the FOSSGIS 2017 conference and was then continued in the German OSM forum. In any case, making this a recommendation rather than a strict rule would be an improvement. --Tordanik 23:35, 11 April 2017 (UTC)
It appears everyone agrees on that. Shall we change it? -- SwiftFast (talk)
Agreed too, I did the change, any objections?: https://wiki.openstreetmap.org/w/index.php?title=Automated_Edits_code_of_conduct&diff=prev&oldid=1476712 Tuxayo (talk) 17:02, 21 May 2017 (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)

Edit done in https://wiki.openstreetmap.org/w/index.php?title=Automated_Edits_code_of_conduct&diff=1855653&oldid=1855605 Mateusz Konieczny (talk) 15:38, 28 May 2019 (UTC)

oil rigs mailing list

"if your edit affects a specialist subject, such as oil rigs or public transport then use the appropriate topic mailing list"

Can someone point me where oil rig mailing list is? This was added in https://wiki.openstreetmap.org/w/index.php?title=Automated_Edits_code_of_conduct&diff=prev&oldid=1186355 edit Mateusz Konieczny (talk) 15:35, 28 May 2019 (UTC)

Adding a single node

A user might turn to a batch edit method, because e.g., iD has no way to place a node at a given X,Y. So he must first upload the node, then can proceed to edit it in iD. E.g., a boundary monument in a forest where air imagery is thus useless. Jidanni (talk) 13:24, 21 February 2023 (UTC)

"Generally, this policy covers all edits where changes are made to objects in the database without review individually by the person controlling the edits" Mateusz Konieczny (talk) 19:51, 21 February 2023 (UTC)
Resolved: Mateusz Konieczny (talk) 06:28, 1 October 2023 (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 (talk • contribs)

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)
Resolved: no response in 5 years Mateusz Konieczny (talk) 08:29, 6 February 2024 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Automated_Edits_code_of_conduct/Archive_1&oldid=2688102"