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

Michael Reichert osm-ml at michreichert.de
Mon Sep 24 18:22:35 UTC 2018


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


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschl├╝sselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20180924/5050a5c7/attachment.sig>


More information about the dev mailing list