I think the best approach would be the first one, in an interface only accessible to admins. The second approach means a lot more work for developers to work out what's what, and I would anticipate such files to be mediated through a Debra anyway.

My 2c, FWIW. I would suggest doing a combination of 1 and 2: A strict CSV format that is uploaded by admins on the command line.

My reasons:

1. Error handling with data import is really hard. Communicating the errors with processing and uploading spreadsheets takes a lot of forethought and effort. The command-line, on the other hand, is quite easy -- an exception thrown on the command line doesn't need to be reported anywhere else.
2. My experience is that users always want to modify their spreadsheets, either intentionally ("Oh, I thought it would import this new column automatically") or unintentionally ("No, I must have deleted that header by accident."). A validation step, followed by an import, is probably the best approach for all involved.
3. If something goes wrong ("OH, shoot -- I didn't mean to overwrite those!") it's much easier to see that happen on the command line
4. It's easier for devs to test a CSV upload on a staging system and then run it on the production system, than it is to expect users to run it on staging first.

You might approach it in a way that you develop a sort of import module, which is initially called by the management scripts but, then when it matures, can move to a UI system.

If we follow @ahankinson's advice, perhaps the best approach is: set up a management command that expects a CSV file with a specific format. A developer copies the CSV into the container and runs the management command on Staging, and makes any necessary changes to the CSV (reordering/renaming columns, etc.) in case of error messages. If/when the command runs to completion, upload the working CSV to Production and run it there. Unless something unforseen arises, this would take maybe 5-10 minutes of developer time per CSV.

Does this make sense?

I've begun work on this, but for the specific CSV at hand, progress is blocked until we figure out what's going on with #1261.

if it's true that Sources (rather than Chants) should have a fragmentarium_id (see #1261 (comment)), then work on this can proceed - after creating the source and all the chants, we can just add the proper value for the Fragmentarium ID on the source once the field has been created.

curious if there's been any progress on this, since it came up today in passing...