Preserving filk memory
Aug. 23rd, 2021 12:28 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
madfilkentist posting in ![[community profile]](https://www.dreamwidth.org/img/silk/identity/community.png){kind=small}
filkThis isn't a "manifesto" yet. It's an early draft of a statement of how the filk community can preserve its memories. I've thrown some ideas at people in the filk and fanac communities and gotten good feedback, knocking down some of my first thoughts.
Preserving a community's knowledge is a hard task. Things get forgotten or distorted. Questions as basic "What was the first filksong book?" lead to misinformation. People who should be remembered fall into obscurity.
Wikis have been the most widely used answer to this problem. Ones like filk.fandom.com and Fancyclopedia bring together a lot of information in a way that's friendly to casual contributors. Their problem is durability. They live on a website, and its hosting or domain could go away. The hosting company could shut down or radically change its practices. A wiki can be migrated, but only if its maintainers aren't caught flat-footed. If all the maintainers of a project (which often means just one person) walk away from it, its content can be lost forever.
There's a solution to this problem: distributed repositories such as Git. Everyone involved has a copy, and if a public host such as GitHub goes away, it can move to another one. This wouldn't be suitable for maintaining wiki databaes, though. The amount of data needs to be smaller, and it's most useful if it's structured. My Filk Book Index uses XML. JSON and YAML are also suitable.
My first thought was to focus on creating structured data files with software. As a simple example, people could enter information in a spreadsheet, output as CSV, and convert it to JSON or YAML. But people have pointed out that getting steady effort on such projects would be hard. Mark Olson told me he's taking a different approach, mining structured data from Fancyclopedia.
My thought at this point is that the repository is the important thing. It should hold structured data, but it doesn't have to standardize on one kind. I could through the Filk Book Index, in XML, into it. Someone else could create a project with Pegasus nominees and winners in JSON or a convention list in YAML.
Contributors should be vetted, to avoid vandalism, but since old versions are retained, an occasional slip-up won't be fatal. If the administrators of the repository all walk away from it or die of old age, someone else can fork it and start in a new place.
That's where I am right now. Feel free to link to this from anywhere, but please don't post copies yet. When there's something more definite, then it can be spread more widely.
Preserving a community's knowledge is a hard task. Things get forgotten or distorted. Questions as basic "What was the first filksong book?" lead to misinformation. People who should be remembered fall into obscurity.
Wikis have been the most widely used answer to this problem. Ones like filk.fandom.com and Fancyclopedia bring together a lot of information in a way that's friendly to casual contributors. Their problem is durability. They live on a website, and its hosting or domain could go away. The hosting company could shut down or radically change its practices. A wiki can be migrated, but only if its maintainers aren't caught flat-footed. If all the maintainers of a project (which often means just one person) walk away from it, its content can be lost forever.
There's a solution to this problem: distributed repositories such as Git. Everyone involved has a copy, and if a public host such as GitHub goes away, it can move to another one. This wouldn't be suitable for maintaining wiki databaes, though. The amount of data needs to be smaller, and it's most useful if it's structured. My Filk Book Index uses XML. JSON and YAML are also suitable.
My first thought was to focus on creating structured data files with software. As a simple example, people could enter information in a spreadsheet, output as CSV, and convert it to JSON or YAML. But people have pointed out that getting steady effort on such projects would be hard. Mark Olson told me he's taking a different approach, mining structured data from Fancyclopedia.
My thought at this point is that the repository is the important thing. It should hold structured data, but it doesn't have to standardize on one kind. I could through the Filk Book Index, in XML, into it. Someone else could create a project with Pegasus nominees and winners in JSON or a convention list in YAML.
Contributors should be vetted, to avoid vandalism, but since old versions are retained, an occasional slip-up won't be fatal. If the administrators of the repository all walk away from it or die of old age, someone else can fork it and start in a new place.
That's where I am right now. Feel free to link to this from anywhere, but please don't post copies yet. When there's something more definite, then it can be spread more widely.
Some observations
Date: 2021-08-23 05:25 pm (UTC)Git repositories work well for wikis -- that's what GitLab, et.al. use. They go through the page metadata to build indices. ikiwiki is another example. It's possible to edit pages directly on GitLab or GitHub, but the nice thing is that unlike most wikis you aren't limited to that -- anyone can clone a repo and use their own favorite editor on it.
Git repos also work very well for books.
GitLab et. al. also have projects, where only members can commit. Other would-be contributors can submit merge requests for review.
I'm looking into Eleventy as a static website generator -- it takes a wide variety of markup formats and isn't opinionated about directory structures the way Hugo and Jekyll are.