[gentoo-project] Project membership vs being on a mail alias: pitfalls and problems

["Robin H. Johnson" <robbat2@gentoo.org>]

I've picked the top mail in this thread to response to a single issue,
because I think it's important. Dilfridge was in #gentoo-infra earlier
this week, trying to figure out projects->alias generation, and we had
a productive discussion of some the fundamental issues behind that goal.

This email is a result of that discussion.

On Wed, Sep 30, 2015 at 08:15:37PM +0200, Michał Górny wrote:
> 1c. We may also automatically add members to mail aliases from
> herds.xml if someone really wants that. But again, not a priority.

A lot of this discussion seems to conflate project membership with being
on a mail alias, and this is problematic in various ways.

0. Some projects have MORE than one alias.

1. While project membership MUST be public, it's entirely possible that
   some or all of the alias members are private:
1.1. Infra & Security aliases: Some of the aliases themselves might be
     secret, used to filter some mail. The list of addresses on the alias is
	 also private.
1.1.1. "private alias" => members of the alias are hidden, but the alias name is published
1.1.2. "secret alias" => the alias name is not published
1.2. Some contributors to projects LIKE their privacy and/or have
     specific addresses for the alias. This set includes upstream devs that
     care about Gentoo bugs for their app.

2. Just because a developer is a member of a project, does not always
   they want ALL the mail on a given alias. Some aliases, esp the older
   ones or more central ones are firehoses of both real bug mail and
   spam.

The combination of these points has a few implications:

A. Developers need to be able to opt-out of an alias while retaining
   project membership. 
A.1. Should this fact be visible?

B. Non-developer members of a project need to addable to an alias by a
developer
B.1. While preserving the privacy of that contributor entirely, if they
     don't want to show up on a listing of members)
B.2. While preserving the privacy of the contributor's email address, if
     they don't want their email address published.
B.2.1. Additional implication is that the email addresses CANNOT be in a
       public repository at all!
B.3. This scares some developers, not known that a non-developer is on a
     mail alias.

From this, I have a rough plot of a data model that tries to take it
into account. It doesn't cover where to store it, other than it needs to
be private.

= Projects have members
== members fall into two groups: developers, contributors
== members can be public or private, this controls if they are shown on the wiki etc.
== developers are public members by default
== contributors are private members by default
= Projects have mail aliases
== members opt into project mail aliases.
== Public project members NOT in a mail alias are visibly flagged.
== Private project members IN a mail alias are visibly flagged (how to
   do this without exposing them too much?)

I think part of the solution will lie in separating the identity of a
contributor vs their email address: Allow viewing of who is on an alias
without exposing the actual email address.

"John X. (upstream author)" in a alias listing is MUCH more useful than
a random email address.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85