avaa
avaa copied to clipboard
bavc
Open contingency plan document for dependencies?
With rumors circulating over the past few days that Soundcloud is shutting down, it begets the question: What is the contingency plan for the demise of a platform AVAA uses to host example files? I don't think the Soundcloud issue is an immediate threat, but it can be used as an impetus to ensure we are prepared for an event similar to this.
Related, what is the plan for sample file ownership? BAVC, the primary host of this material, has had staff leave and new staff arrive, so what is the best way to document and relay information for a low-priority application like this one? Stanford acts as a secondary host, and what role do all of you play in this? In general, how do we avoid having things "lost in the shuffle"?
I was thinking recently, too, how if I had been a "good archivist" while doing the data migration from MediaWiki to this new site, I would have done a better job (and by 'better' I mean 'anything at all') at documenting what that process was like, for legacy purposes. Both for the migration and also for the collective decision-making we did in terms of reaching a consensus for what constituted a successful project migration, what was minimally determined as requirement for migration, and what became a "nice to have" instead of a requirement (and how that happened).
I would like the AVAA to have an open, written document for how to deal with these situations, as a preventative measure. This is kind of a good idea for any technology-based project, but this happens to be a small one that I care about and other people care about and is widely used as a resource. I think this document could go over what the dependencies are, where backups are located, who has access to them.. other things.
Some questions: Where else do the sample files live? Is there a collected, updated, active list? Who has access to the Soundcloud/IA accounts? Is there an alternative/better way to host and embed files? Can we manage file access and file embedding within git, largely alleviating the first element of this issue completely? Who "holds the keys" to relevant accounts, and how does that knowledge get transferred?
FWIW, I have no answers here. I suppose my role on this project could be summarized as technical-maintainer, but these are largely questions of institutionally-hosted maintainership. I did recently update the README to include all of the technical components I used to build this site, should that ever become relevant and need addressing and I'm not available to address it.
CC: @iamdamosuzuki @kellyhaydon @bturkus @hannahfrost @oceanofsound @michaelangeletti @ncoy
LOCKSS,
Ashley
These are all great questions and let's definitely find ways to answer them. We most certainly can deposit the media samples to the Stanford Digital Repository as primary or back-up source for the streaming samples. When we started this project in 2011, SDR didn't support streaming directly - but now it does! Maintaining copies of the media files in Git makes a lot of sense too. Redundancy and distribution are key.
As a form of documentation of the old WikiMedia site, Stanford did a crawl (https://purl.stanford.edu/jm022yy9693) but only once back in 2013. The Wayback Machine has additional captures (https://web.archive.org/web/*/http://preservation.bavc.org/artifactatlas/index.php/A/V_Artifact_Atlas). So that is something. Are we comfortable with relying on the IA to keep a record of the site over time? Should Stanford do an annual or binannual crawl going forward?
To answer some of your questions Ashley:
Where else do the sample files live? --> aside from Soundcloud for the audio files and IA for the video files, I believe we (SMPL) have local copies on our machines of the samples we created Is there a collected, updated, active list? --> I don't think so (going off of what's on Soundcloud/IA is your best bet at the moment) Who has access to the Soundcloud/IA accounts? --> Soundcloud might just be me (shame!), not sure about IA. At the very least, I'll change the Soundcloud account to [email protected], and send the password to the list. Is there an alternative/better way to host and embed files? --> Maybe IA is the best way to go? Keep everything in one place? Why not? Can we manage file access and file embedding within git, largely alleviating the first element of this issue completely? --> We could do that, although I bet git doesn't give you a visible waveform (correct me if I'm wrong). My preference would be to 1) put all the audio samples up on IA and change the streaming links, 2) deposit copies in the Stanford Digital Repository as a backup.
Shoot, I'm currently unable to add any additional emails to the Soundcloud account associated with my Stanford email. I'll keep trying...
I dropped these large issues and then promptly had zero free time to sit down and continue to think them through. Thanks very much @hannahfrost and @oceanofsound for this investigation! I promise I'll follow up shortly.
Thanks all! The initial plan was to move files to IA and get everything in one place. I can do this assuming I can pull all the Soundcloud files without or without a login (I think I can?)
Anyone at BAVC can access the IA site, though maybe I should also change that login to the avaa-maintainers list?
Strangely I've been unable to add any additional emails to the Soundcloud account associated with [email protected]. While I get this problem resolved, feel free to email me for the password if you want in.