On Fri, Aug 19, 2022 at 2:46 AM Merlin Cooper
<mxanthropocene@outlook.com> wrote:
>
> I like this policy, but it strikes me as odd that the packagers' email
> addresses are posted publicly on the Pagure tickets... Wouldn't that
> make it easier for spammers to get more email addresses?
The script has a flag I can use in the future which (I believe) will
mask the addresses in the tickets. I didn't use it this time because
email addresses are already displayed all over the place. If a spammer
gets an email address from these tickets that they didn't have before,
then I'll be very surprised.
I really wish people would stop making the argument that just because other places/systems have terrible data hygiene, we can have terrible data hygiene too. Fedora should be trying to set the example of how to interact and behave, and the "follow the herd" mentality here is not acceptable in my opinion.
Email address could be considered PII, and so there is a debate about when the GDPR-type regulations would apply to them (from what I read, it would apply for work email addresses giving full names or personal email addresses). While there is a legal basis for keeping the email address in the system and using it, I fail to see a legal basis that would allow publicly displaying an email address in this way.
Many systems are also trying to reduce the exposure of personal email addresses, with major git hosting providers even creating anonymous commit emails that can be associated with user accounts on those systems and then used for your commits should you choose.
So in short, I strongly argue for masking/removing the email address from all tickets like this, and the fact that they are displayed there was is so concerning to me that I opened a ticket about it last night:
https://pagure.io/find-inactive-packagers/issue/619.
I am going to argue that this isn't bad data hygiene because this data being public serves an important purpose for the ongoing working of this project.
When you become a Fedora maintainer, you are not just helping your fellow maintainers, you are also helping the general public who may be upstream developers, users, and packagers in different projects. When a person makes a change or has had their 'hands' on a package, that is made public in many many places to make sure that any and all interested people can contact them for questions. Upstream may have suggestions to make that change better or worse. Other packagers may need to understand why that package affects them. Packagers in different projects need to contact to see if this will solve their problem with said package or not. This has been and is mostly still done via email first and bugzilla and other methods last.
When that information is not easily available, trust in the change, package, maintainer drops. That lack of trust tends to boil through many areas and lowers trust in the overall operations of the distribution. Because of this, email addresses for packagers have never been very secret. They are in spec files, they are in email posts about changes to packages, they are in various message buses which anyone can subscribe to on the idea that the information being free improves trust.
Then there comes the removal of privileges. This is a big concern and needs to be done in an open and clear fashion. Other developers and packagers need to understand WHO was attempted to be contacted and why that contact may have failed. When other projects have not done this in an open arena, it has caused unrelated packagers to quit because they are not sure they can trust the project to not do the same with them. There is also the fact that email addresses change a lot and sometimes the person who has been listed as `
foobaz@uforgot.me` may have gone to `notme@notmy.email` and need to update their info. It might be even clear that notme@notmy.email has been active in bugzilla or some other area but hasn't done a build because a different maintainer has done so.
We may need to come up with different methods of 'trust'. That is a larger conversation because it would require a complete rethink of what we are as a project and how we 'trust' each other, and allow others to 'trust' us.