[Slackbuilds-users] Repology a public emailaddress repository; SlackBuilds-users Digest, Vol 147, Issue 3

[sborg63]

On Mon, 2 Jul 2018 23:10:04 +0100
David Spencer wrote:

> You can organise your own layer in between.

Yes, one is forced to do so... Repology is of course just an
example. Still, it is a bit steep to expect for people who contribute a
couple of packages to set up their own middle layer to prevent this
kind of risk.  

> And please can I say, it has sometimes been a significant pain for me
> when people have multiple variants of 'scrambled' email, because it
> makes it difficult to query git to discover whether a maintainer
> silently stopped maintaining eight years ago...

Well, let's turn this around. Is the fact that people somehow try to
obfuscate their email address not a clear sign that they do not want
this address to be recognized other than by people who really want to
contact them because of some problem? 
Encouragingly, Repology no longer aims to bypass this intention.
(https://github.com/repology/repology/issues/651).

When you want to get rid of obfuscated emails one could think of
combining SBo-submission with a mailing list like this one that relies
on unscrambled email addresses.

Why I suggest combining the submission with this mailing list: There is
password protection to get on or off this mailing list;  so, you
already have a somehow protected database with 'real email addresses'.

Such a non-public database with email-addresses
 from submitters (maintainers) will makes them contactable for
 people who might need these (like you). Give submitters the
 possibility to link these 'real email' addresses to some
 maintainer-pietje1-100 at slackbuilds.org alias. Publish the
 email-aliases in the info files and set up automatic email forwarding
 (not much moderation/storage needed). 

Sites like Github uses aliases if people want to opt out of publishing their email
 address. 

As any organisation relying on voluntary input one has to make it safe
for contributors to submit their details. 

In this respect, it is worrying that while this mailing list is
non-public, the archives of the email-exchanges show contact details
AND are publicly available. One is protecting the server and this
list from spam but why not also the contributors? Wouldn't it be
"trivially easy to make a script that removes" the email addresses
(or at least the domains) from the archives before (or after)
publishing? Or one could put the archives behind a login barrier. 

Cheers,

rob