We should get users into the habit that superseded/redundant productions should be removed. That's a workflow and instructions documented where it is easily visible to users.
OK, that's there if the prod name is the same. This being said, nobody will ever take actions, a fortiori of deletion, unless we clearly state somewhere that one is supposed to do it, and how to do it ;-). The fact that it is possible is far from being enough. You have to agree.
Absolutely! The idea would be to summarise this information into a webpage that flags productions as candidates for deletion. Then pester the person who submitted production + the relevant liaisons with emails until they explicitly mark it as kept or deleted.
Any data marked for deletion can then be "hidden" and included in the standard data cleaning routines that are done manually every now and again (as I don't trust my code having the ability to delete data).
For the production name, we can actually use slightly smarter heuristics but that's a technical detail that will be easier to figure out once we have more productions to experiment with.
Take the "issue" here of membership to the egroups. Though it is written that merging rights request membership to the egroups Jingyi assumed that membership was granted auto-magically, whereas it requires action. This was a much simpler / less dangerous thing, yet ... Bottom line: docs, docs, docs. As ever.
Hi, waiting for a standard procedure shared by all WGs to be set up, in the Charm WG we are keeping track of superseded productions on this spreadsheet:
The AProds request lhcb-datapkg/AnalysisProductions!135 (comment 4643454) mentions a very large number of old and related AProds. This is certainly an excellent candidate for a check on what is redundant/superseded and worth being archived.