Add a linter check for an email address in the "maintainer" field.

[raphael-proust]

It would be nice to add a linter check for an email address in the "maintainer" field.

See ocaml/opam-repository#26297 (comment)

[shonfeder]

We have implemented and deployed this check, but, as per ocaml/opam-repository#26581 (comment), Marcello has some alternate concerns/requests about the linting logic. The propose to

relax the linter to avoid failing if at least one email is present (or even if a public repository is listed imo)

I don't think taking into account the visibility of git forges is viable. The repo must not only be only public, but also have issues (or discussions, or some other feature?) enabled, and IMO this kind of analysis of contributors development processes should be out of scope for a linting check. WDYT?

Regarding the suggestion that we "avoid failing if at least one email is present", this is any easy change to make, but I am not sure why it is worth relaxing the requirement here or introducing/allowing such variation in the opam data. The key question to my mind is:

What does it mean to be a maintainer of a package, if it does not mean committing to being contactable and responsive to users of the package? If we allow names in that list without any way of contacting them, what is the utility from a user's (or an opam-repo maintainers) perspective?

[mbarbin]

I am discovering this new check in a submission this morning, and just wanted to voice some general push-back against such check. If the project is on GitHub and has an issue tracker, for some projects I think it is reasonable for that to be the default way of interacting with the project maintainer. Don't you agree? I am not sure of the meaning of providing an email address for maintenance. As an individual, I surely wouldn't want to hint that I will read and/or respond to emails sent directly to me (rather than normal interaction via GitHub). Would you be OK to relax it somewhat?

[shonfeder]

I don't have very strong feelings on this, but I can see the logic of requiring a uniform, distributed, time-tested, and platform agnostic way of contacting maintainers. As such, I can offer some push back to your push back 😄

If the project is on GitHub and has an issue tracker, for some projects I think it is reasonable for that to be the default way of interacting with the project maintainer. Don't you agree?

This is a reasonable way of submitting issues, but it's not necessarily the most reasonable way of contacting maintainers. Consider ocaml/opam-repository#23789. The plans developed there currently entail setting up a process for archiving defunct and unmaintained packages. If we require that all maintained projects have an associated email address, then it is easy for us to automate (or semi-automate) outreach to maintainers when a package breaks. If, instead, we need to account for every possible bug-tracking system in use, we will have a maintenance nightmare and a technical quagmire.

I am not sure of the meaning of providing an email address for maintenance.

To deffer to wikipedia, "Email is a ubiquitous and very widely used communication medium; in current use, an email address is often treated as a basic and necessary part of many processes in business, commerce, government, education, entertainment, and other spheres of daily life in most countries." 😉 The meaning of providing an email address for maintenance is that the address may be sent messages relating to its maintenance, and it is expected that active maintainers would read and respond to these.

IMO, there quite a few good reasons that we should want to require maintainers to register a way of contacting them that is based on a uniform, time-tested, distributed, open standard. And I've only hinted at some of them above. Email seems like the best available alternative with these qualities.

All this said, I'm happy to work with all interested parties on figuring out a solution here that will satisfy all our needs and support a healthy, well maintained software ecosystem, without imposing unnecessary requirements.

(IMO, it is too bad that github does not appear to support creating issues based on messages sent to an email address (https://webapps.stackexchange.com/questions/76055/can-i-create-an-issue-in-a-github-repository-by-sending-an-email).)

[mbarbin]

As such, I can offer some push back to your push back

And it is very welcome, thank you!

I can't believe you linked me to the Email_address wiki page, you villain 😄 ! I'll try making it up to you in one of our next convos - of which I hope there'll be many in the future!

the address may be sent messages relating to its maintenance, and it is expected that active maintainers would read and respond to these.

That's what I feared, I guess. It sounds like accepting a service level, without a specific service level agreement. From experience, at least on GitHub, it feels to me like there's some kind of social expectation that people get to things when they get to things. Life happens, it's all in the open, sometimes other folks involved with projects jump in, etc. Some issues can stay unattended for weeks or more, and it can be OK. With private emails, there's a lot of this that you lose. And a chunk of context you won't necessarily have if join an existing project as maintainer.

Another concern I have is spam settings. I wouldn't be surprised if, with the current settings I have, there was a good chance for such maintenance emails coming from unknown senders to never make it to me.

That being said, thank you for sharing the perspective of the opam-repository maintainers, which I simply did not consider. Outreach to maintainers at scale doesn't sound like an easy problem. Thank you for your hard work!

Thinking a bit more about this, and in light of your use case, I think my reluctance may be due to the fact that I've been kind of procrastinating about setting up an email dedicated to my open source activity, and was kind of OK with the status quo that I had been able to get away so far without resolving this question. This new lint put this subject at the top of my stack. I think it's reasonable for me to solve this anyways. I'll think about it and let you guys work in peace. Perhaps using the plus addressing feature of a gmail free plan is a simple way to get started, as in "First Last <[email protected]>". I'll think about it. Thanks a lot, and good luck with this infra project!