On Sun, 30 Mar 2014, Tobias Mueller wrote:
1. How committee members will be able to access the relevant memberUid from LDAP if they don't have access to LDAP at all? (access is currently restricted to accounts team + sysadmins)I think I haven't understood it yet. Where does Mango write the user information to? There is a "GNOME userid" field when adding a new user. Could we use this? If not, could we add another field to the Mango web interface for the email alias?
The "GNOME userid" is the field you'd want to use for properly adding a @gnome.org alias into the system. The only issue with the above is the need for the "GNOME userid" to match an existing LDAP account, thus the need for at least one or two committee members to find out whether an account has been created already or not. (and if not, create it by following the account naming policies) For istance, Bastian did not have an LDAP account (thus the need to create it on LDAP and then adding the userid in place). Sebastian has an LDAP account already so it was just a matter of adding the GNOME Userid in place on his foundation membership entry. I did add a little note about this on the apply form. [1]
2. What should be our policy in relation of old members still owning a @gnome.org alias? right now members are only added to the 'mailusers' LDAP group and never removed but we can easily turn that on and remove an alias in case the membership expired. A question arises though: most of the times members make use of their alias in many places around the web and breaking it might result in a loss of emails.Right. That wouldn't be a nice move. Do we have statistics on the usage of an alias? I'm not entirely sure whether we want to create such a statistic, but if we happen to have that information already, we may as well use it determine what aliases are old and what we can get rid of. Also interesting would be the number of bounces, I guess.
We currently don't keep any statistic about mail aliases usage and there are plenty of places where someone could have made use of the alias itself. We should probably add some more text on your "Your membership is due to expire in X days" script letting the member know that within 3 (or 6?) months from the expiration the alias will be disabled. How does that sound?
What I'm wondering is how long should we leave the alias around? Also should we remove the alias at all when a membership lapses?Interesting question. I think, yes, we should. An alias is a "benefit" of the membership. If one is not a member anymore, one is not entitled to these benefits. On the other hand, such an alias is pretty much for free for us to provide. And it's not a problem unless a new member want to have that alias. So maybe we can do it like this: Once the membership lapses, we send an email saying that we reserve the right to reclaim the email alias in case a member wants to have it. We can also mention that we try to claim it with a three month notice. In any case, we'd appreciate if the alias can be removed. Is that a too complicated procedure?
As a first step towards this we can modify the following form letters pointing out the benefits we provide are going to expire after a certain amount of time: 1. Welcome email 2. "Your membership is due to expire" mail (the alias will be alive for 3 (or 6?) months) 3. "Your member has expired" mail (the alias will be alive for 3 (or 6?) months from the arrival of this email) If someone then applies for emeritus membership and we grant it we'll just keep the alias handy. We'll probably need a way to parse existing emeritus members from within the python script for the alias to stay up and don't get caught by the two-years-expiration filter the script will follow. [1] https://git.gnome.org/browse/gnome-web-www/commit/?id=1be65a1f0587348f3037c1f1d3ea99d788917cf6 -- Cheers, Andrea Debian Developer, Fedora / EPEL packager, GNOME Sysadmin Team Coordinator, GNOME Foundation Membership & Elections Committee Chairman Homepage: http://www.gnome.org/~av
Attachment:
signature.asc
Description: Digital signature