User:Tuxayo/Mailing list discussion summary: Automated edits code of conduct and DWG
- 1 Introduction
- 2 Objectives
- 3 Strictness of the rules
- 4 Issues
- 5 TODO
- 6 Concrete ideas
This page is an attempt to summarize the points that can help build concrete proposals to some of the issues discussed.
It's also mixed with my vision of the issues so not everything comes from the discussion.
This is a work in progress. Expect errors, biases and inconsistencies.
The discussion started here: https://lists.openstreetmap.org/pipermail/talk/2016-July/076291.html
List of messages in chronological order: https://lists.openstreetmap.org/pipermail/talk/2016-July/subject.html
In the end, everyone want long term data quality. The disagreement come in how to set some cursors regarding automated edits.
Strictness of the rules
They are guidelines and should be enforced strictly, that would create more issues than it solves.
The DWG doesn't have time to
- Examine enough individual changetsets among a big (+70) series of problematic AEs to prevent collateral damage when mass reverting the changesets.
- Here enough means that if the AE changetsets don't explicitly state that they are AEs one must at least check the number and natures of objects and the nature of changes to see if it's an AE.
So the problem is more when enforcing the guidelines rather than the guidelines themselves.
- They are often the last stage of the AE issues handling process so the only two choices are:
- Drop and leave errors/data loss
- Handle even when there is no time to do it perfectly
Depending on the moment or the person, not enough time to systematically:
- Do an adequate study of the changeset or series of changesets to avoid too
- Dialogue with the contributor to fully understand their motivations and mistakes
- Dialogue with the contributor to explain why e.g. not discussing in advance is important
- Controversial reverts
- Legitimacy issues (no incidents wouldn't lead to these questions)
- Time loss
- For the contributor which has put hours of work to execute it's problematic AE (sometime it's not even problematic in case of collateral damage) and will often give up where it could have fixed the AE to still be able to help cleaning the base.
- For the DWG member handling the case
- Motivation loss
- For the contributor
- For the DWG members spending a lot of time doing the police and arguments/disputes.
- Few people are in the DWG so time extremely limited
- Due to the blocking power that comes with being in the DWG. Which is not necessary to handle AE issues. Someone else could do it and report to the DWG it blocking is needed.
- One can't see all the cases handled by the DWG
- We only see the cases that are controversial enough so someone "publicizes" it so the rest of the community can't judge their overall work.
- Being able to see all the cases would allow to see how much work is done and who is doing it, which would allow to confirm if the volunteers doing it are overworked and must rush the cases.
- Being able to see all the cases would allow understanding better the AECoC as it's the result of years of handling these issues.
- The same reasons could be valid for all the automated edits.
1. Have a Wiki page that lists all the automated edits
2. Have a Wiki page that lists all the automated edits issues
Including all the DWG's interventions but not only.
3. Have a public mailing list dedicated to AE issues
The reporting of AE issues could be done here so anyone could contribute handling these issues.
Hopefully this will lower the workload of DWG member and allow more time to be spent on each case.
That would also have the benefits of the idea 2.
4. Ask a contributor who didn't discussed an automated edit to do it before any other contribution
So the DWG member/contributor handling the issue won't have to time arguing with the contributor who did the AE.
- It will save time for the contributors handling AE issues
- Contributors handling AE issues don't always have the knowledge in the domain covered by the AE
- A refusal to discuss the AE with the community even post edit would give a greater legitimacy to revert
- Not reaching consensus after discussing with the community will give more legitimacy to revert
In other terms, it will disconnect the contributor handling the AE issue in terms of time and responsibility: less time spent, less arguing about the AE, less controversies about reverts