Write a policy about Cabal package metadata

[michaelpj]

i.e. what do you put in your .cabal file.

[michaelpj]

Problems:

• Who should be the maintainer? Should it be the individual(s) who currently maintain the package? Or some generic organizational name?
• Who should be the author? Should it be the original individuals who wrote the package? Or some generic organizational name?
• What contact emails should be used? The organization emails of the individuals maintaining the package? A generic email associated with the team? A generic email associated with the organization?
• What other fields should or should not be included? There are many.

[coot]

Who should be the maintainer? Should it be the individual(s) who currently maintain the package? Or some generic organizational name?

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.

Who should be the author? Should it be the original individuals who wrote the package? Or some generic organizational name?

I would leave this up to the package authors / maintainers to decide. There's a related question how to acknowledge contributors? Some projects maintain CONTRIBUTORS.md file, some other AUTHORS.md one. I prefer the first one. I'd grant somebody an author if one did a major re factoring or added a major functionality.

What contact emails should be used? The organization emails of the individuals maintaining the package? A generic email associated with the team? A generic email associated with the organization?

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.

[michaelpj]

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.

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.

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 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.

I would leave this up to the package authors / maintainers to decide. There's a related question how to acknowledge contributors? Some projects maintain CONTRIBUTORS.md file, some other AUTHORS.md one. I prefer the first one. I'd grant somebody an author if one did a major re factoring or added a major functionality.

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...

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.

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?

[michaelpj]

Interestingly, maintainer and author are not required fields. cabal check complains about it but it doesn't even say "Hackage would reject this package", which it sometimes does. So maybe we should just omit them and say people should link to the source repository, which arguably conveys much more information.