[OSM-dev] Various types and means of account blocks

Simon Poole simon at poole.ch
Mon Sep 24 19:00:23 UTC 2018

As way of a clarification: the LWG was not proposing to block children
from answering on changeset comments (given these are public and not so
easily misued), but not allowing access to the blog and the internal
message system.


Am 24.09.2018 um 20:22 schrieb Michael Reichert:
> Hi Frederik,
> Am 24.09.2018 um 17:57 schrieb Frederik Ramm:
>> Is the opposite true as well - would/should someone given a cool-off
>> period for being a dick in a discussion still be allowed to do mapping?
> No. Anyone who is able to edit the map data should be able and has to
> answer sensible questions.
>> Should a normal user block perhaps simply come in two flavours, "block
>> mapping only" and "block all"?
>> It has been suggested that blocking *all* communication functions might
>> be problematic because one thing you might expect from someone you have
>> blocked is that they apologise, or set something right, which they might
>> not be able to do without the ability to write messages.
> If we implement the new block type proposed by ika-chan!, the DWG can
> place a type 1 block (editing block) on the account and tell him to
> aplogoise. If the user fails to do so, it's a sign of bad intentions and
> a full block can be placed.
>> Do we need a full array of permissions - "can change user name", "can
>> edit own user page", "can write personal messages", etc. - and the
>> ability to short-time suspend any and all of them?
>> Thoughts are welcome.
>> This also ties in somewhat with a separate discussion, on how a
>> prerequisite for allowing children on the platform might be that we can
>> disable the "social" functions of an account. In that case it would not
>> be a short-term block, but a whole class of accounts that can edit, but
>> not participate in discussions (for their own protection). I'm not sure
>> that can work at all (given that the ability to contact a mapper is very
>> important to us). Maybe such accounts would have to be linked to a
>> "responsible" parent account who then gets the messages...
> I think that any mapper should have the possibility to ask another
> mapper any question on their edits. Currently, we often place a 0-hour
> block on accounts who fail to respond and continue editing. What shall I
> myself as a mapper do if the user whose edits look strange cannot answer
> my question why he deleted the restaurant? Shall he/she restore it
> because the child does not respond?
> The concept of hiding minors from communications might work if they are
> asked/told to map just due to their ability to draw geometries, e.g. in
> an enclosed system or for mapping a few villages in an area where no
> data has been before and nobody else is mapping. But once they edit
> existing data, "conflicts" (questions and comments) with the community
> will arise.
> It might be possible to solve these issues but figuring out solutions is
> up to those who need minors below 16 years mapping.
> Best regards
> Michael
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20180924/7ee06279/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20180924/7ee06279/attachment-0001.sig>

More information about the dev mailing list