2016-07-12 19:35 GMT+02:00 Andy Townsend <ajt1...@gmail.com>:
> On 12/07/2016 17:29, Éric Gillet wrote:
>
> I've read through your posts in this thread, and while it's clear that you
> have an issue with the way that things work now, I can't see what that
> problem actually is. Can you provide some specific examples of DWG actions
> that you think were inappropriate? What do you think should have happened
> instead?
>
I will summarise what course of action I think would be appropriate to
follow :
- It's not clear whether AE CoC terms are rules or simply guidelines
- As Frederik said, rules should be written well in order to have the
legitimacy to be used strictly (ODbL, Contributor's Terms etc.)
- Guidelines should contain, well, guidelines that should not be used
as a direct basis for reversal. They could be used as part as an
argument,
but just using one item should not be grounds for reversal by DWG.
- In consequence, a choice have to be made :
- Either overhaul the current AE CoC, submit it to RFC/voting and use
it as a ruleset for contribution after a consensus is reached
- Use the current AE CoC as guidelines, not strict rules.
> However do bear in mind that just like the vast majority of people in OSM
> everyone in the DWG's a volunteer. Some volunteered; others were asked to
> join but everyone's unpaid. Also bear in mind that everyone in OSM's a
> human being and deserves a basic level of respect - even new users creating
> invalid POIs simply because they don't realise they're editing a worldwide
> map.
>
DWG members are volunteers, I am too, you surely are too. Contributor's
time is a premium ressources in projects such as OSM. So let's not waste
any of it :)
> Andy (aka http://www.openstreetmap.org/user/SomeoneElse , member of the
> DWG but writing in a personal capacity).
>
Thank you for disclosing that and differentiating between DWG
actions/opinions and yours.
-----
2016-07-13 5:36 GMT+02:00 Nicolás Alvarez <nicolas.alva...@gmail.com>:
> 2016-07-12 23:08 GMT-03:00 tuxayo <vic...@tuxayo.net>:
> > Automated edits should also have a place. For thing like pure tagging
> > errors:
> > - URLs lacking "https://"; prefix
> > - leading and trailing spaces in names
> > - common, obvious and non ambiguous typos
> > The error probability is almost null (error in script or typo?)
>
> When I searched for typos and leading and trailing spaces in my area,
> I found lots of unrelated wrong things. For example, many objects with
> trailing spaces in the names were "my house is here" nodes. Or roads
> including the name of the political administration that was around
> when the road was built (typical political bullshit that appears in
> signs sometimes, but it's *not* the name of the road).
>
> Checking them one by one was a great idea.
I agree that often an error is not alone and it would be best to correct
all them while explaining to each individual contributor why it's and
error, but as I said before, time is a premium. Here are other problems :
- It slows down the actual error correction
- As I said before : if you lace "completely manual" modifications with
"slightly automated" (search/replace) and face objections for the
"automated" part of your changesets, there are every chance that the whole
changeset would be reverted, or even all the changesets in a time interval
(just ask Test360 about it)
So what do you suggest :
- Do one changeset by feature you're editing, where you both correct the
original subject of the error and othoner problems ? (Very slow, but higher
quality at the end)
- Do both the search and replace and correct other errors on multiple
other errors "completely manually" in the same changeset ? (Time efficient
but slow, good quality of data, but at risk of reversal of the whole
changeset)
- Correct "automatically" what can be automatically corrected, and rely
on QA tools to spot the other errors ? (Time efficient, quick, but leave
other errors untouched)
These three approaches seems valid to me, but it doesn't seem to be the
case for everyone.
_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
