-
Notifications
You must be signed in to change notification settings - Fork 0
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
Write a policy about Cabal package metadata #12
Comments
Problems:
|
I think we should actually put individual's who maintain it, this makes it easier for others to find whom they should speak to when opening a PR etc. Why not include both, e.g. the generic and individual? I would use the generic one when the maintainer is not responding. This can be useful for packages published on Hackage, so before a package is taken over by a 3rd party IOG has a chance to respond.
I would leave this up to the package authors / maintainers to decide. There's a related question how to acknowledge contributors? Some projects maintain
That should be left as a decision to the developer, but with a twist: if one wants his own email to be there as a maintainer, it means one is willing to maintain the library regardless of ones involvement with IOG. We also need a policy to substitute inactive maintainers. |
I think CODEOWNERS is much more suitable for that. The cabal metadata fields are things that people see when they're consuming a package via a package repository... arguably they're somewhat redundant these days because most people just go straight to the source repository link, and then use the tools that github provides to communicate with the maintainers. My main concern with including lots of individuals is that it would be quite annoying to keep up to date, for little benefit.
I do like the idea of having an organizational email so that IOG can respond to a takeover request! We need a good email to use, though.
Personally, I don't care that much about these things (do people really see a significant difference between "contributors" and "authors" and care about it?) and it seems like annoying work maintaining them, but preferences differ. This is part of why I don't know what we could recommend generally...
I think this is something we're going to have to grapple with more generally. Some of the things we open-source are going to be "just like other OSS Haskell packages", i.e. maintained by some random individuals. Some of them maybe the MBO is going to commit to maintaining. Probably the latter should include their email and so on, and the former should not? |
Interestingly, |
i.e. what do you put in your
.cabal
file.The text was updated successfully, but these errors were encountered: