-
Notifications
You must be signed in to change notification settings - Fork 22
Contributor policies #4
Comments
Man, that's a fascinating question. Let me run that one up the food chain and see how people feel about it. |
Just keeping you in the loop—we're working through solving this problem internally, and should hopefully have a solution by the end of the week. One of our questions is how best to credit people? Any thoughts on this? It's reasonably easy to add a name to a CONTRIBUTORS.md file—is that sufficient, or do we think that will cause more issues than it's worth? |
What about adding them in a NEWS file, whenever you integrate changes upstream and reflect them to the repo? That way the nature of the change is documented and announced alongside the name of the contributor. |
Interesting, but tricky due to workflows...Once we've gotten a correction and handed it off to the subject matter expert, it will be difficult to know when those changes would actually be included in our data release, since the goal is to have the actual releases by automated. Right now, I think we're going to just go with a CONTRIBUTORS file, and maintain it manually, see how it works. |
Fair enough. I'm interested to see how you'll automate it all! |
Thanks for the input—feel free to review the changes to the README and the CONTRIBUTORS file in this release and critique again! This is really helpful for us. |
This question may be part of a bigger discussion, but what would a
CONTRIBUTOR
file look like for this repo, given that (like all the museum datasets out there, I'd wager) it is a generated extract of an upstream CMS?This would be relevant particularly for PRs/issues that address data content. Over at the @tategallery they have accepted PRs that have addressed typos in the original data, presumably following some internal process for integrating those changes upstream into their CMS. @MuseumofModernArt doesn't have any PRs quite like that, but there are a few issues where users have pointed out typos, and maintainers note that the fixes will be made to the source CMS and reflected downstream in the next repo update. Depending on the internal workflow that you settle on, it might be useful to let contributors know that issues, rather than PRs, will be welcomed; or that PRs are welcome but will not be accepted into the repo, instead being addressed in the next content update, etc.
The text was updated successfully, but these errors were encountered: