-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a linter check for an email address in the "maintainer" field. #152
Comments
For packages submitted to the opam-repository, it would help to have the email addresses of the maintainers. See ocaml/infrastructure#152. This commit subtly encourages package authors/maintainers to do so. Signed-off-by: Puneeth Chaganti <[email protected]>
For packages submitted to the opam-repository, it would help to have the email addresses of the maintainers. See ocaml/infrastructure#152. This commit subtly encourages package authors/maintainers to do so. Signed-off-by: Puneeth Chaganti <[email protected]>
For packages submitted to the opam-repository, it would help to have the email addresses of the maintainers. See ocaml/infrastructure#152. This commit subtly encourages package authors/maintainers to do so. Signed-off-by: Puneeth Chaganti <[email protected]>
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
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? |
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? |
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 😄
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.
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).) |
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!
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! |
Creating a better way to contact maintainers is an entirely laudable goal, but pushing a check into opam-repository without some design consultation seems a poor way to achieve this goal.
Overall though, I'd like us to not just push checks into the live opam-repo-ci without at least some consultation about what the checks are first... |
Thank you for the considerations and directions for improvement, @avsm. Regarding opam repo policy and CI change managmentI'd like to start by addressing the point you raise around process:
It looks like we may need to formalize an explicit process around developing the opam CI and packaging policies. We clearly moved forward without having achieved enough consensus or understanding from various stakeholders in this case, and having a clear, documented process should help us reduce the chance of that recurring. In this case, it may be a growing pain from my recent addition to the maintenance team? That said, reviewing the (implicit, informal) process, there was certainly some consultation and there were some opportunities for interested parties to weigh in. I think we can improve this a lot tho. I have started some notes and it is on our agenda for the next opam repo maintainer meeting. Thank you for noting the problem! Regarding the concrete design considerations
AFAIK, we already have a precedent for lint checks that are added without retroactively backporting to existing packages (e.g., to exclude This is not to say that it would not be worth while to consider backports. I just don't see why that would be a prerequisite here.
This is a good question, and would apply to any form of contact I think. It can probably be bucketed along with a more general question of how we ensure home pages, issue trackers, or source archive URLs stay live? Adding something like this into the health check would be great.
Indeed, we could consider any number of mechanisms. IMO, the main benefits of email are:
I'm not opposed to using discuss (or any other platform), but I cannot think of a more accessible or light weight option than letting people use an email address. I can imagine people or organizations being willing to maintain packages but not interested in registering for our forum or whatever. We could also support any number of different contact methods, but that seems like needless complexity and overhead for maintainers. Looking forward to hearing any further thoughts on this! We plan to discuss this at the next opam repo maintenance meeting. I think one key topic to decide there is whether we want to remove this check for now. |
Email addresses are generally already available in the commit data of PRs into the repo, so at least for all cases where the maintainers are involved in package publication, we are only asking for the inclusion of data that is already being shared in the PR. |
It would be nice to add a linter check for an email address in the "maintainer" field.
See ocaml/opam-repository#26297 (comment)
The text was updated successfully, but these errors were encountered: