Audit Spotlight wiki

[camillevilla]

In preparation for Spotlight 2.0, let's re-organize our wiki and analyze which areas are out of date.

[anarchivist]

• Split docs up between team, assign specific pages to team members
• Flag things that are out of date
• Triage/prioritize work for correction
• Correct those things (or mark as deprecated?)
• If time, consider reorganizing if it makes sense / helps with clarity

[mejackreed]

• [x] Home - @mejackreed
• [x] Installation - @mejackreed
• [x] Blacklight - @mejackreed
• [ ] Page widgets - @camillevilla
• [x] Resource scenarios - @aeschylus
• [x] Image ~~versions~~ sizes - @jkeck
• [x] Queueing backends - @camillevilla (recently updated in March)

[ggeisler]

I propose that we remove entirely the section "Building an exhibit" (everything in the red rectangle below):

At the time we put these placeholder pages in, there was no other clear place for documentation on building an exhibit. However, we'll soon have a detailed documentation site for curators in the form of a Stanford exhibit. Even though that exhibit is primary aimed at Stanford curators, 90% of the content is applicable to any Spotlight installation and the exhibit will be public. So I think we can keep this wiki focused on developer-oriented documentation, and rely (at least until an equivalent community-based resource is available) on the Stanford documentation exhibit for curator-oriented documentation. We can link to the documentation exhibit in this wiki documentation after that exhibit is made public.

[camillevilla]

@ggeisler I agree that the stub pages aren't likely to get filled out soon. I'm excited about the new documentation exhibit, but I'm worried about folks getting confused about what comes in Spotlight out-of-the-box vs. Stanford customizations.

Perhaps we could export the Stanford documentation exhibit and import it into the Spotlight test app? I'm ok with waiting until the documentation exhibit is published for us to make a decision though.

In the mean time I would be interested in:

1. Removing the stub sections under "Building an exhibit"
2. Retaining Configuration settings and adding a brief section about Languages that links to Translations

[ggeisler]

@camillevilla I'd guess roughly 90-95% of the documentation exhibit is non-Stanford specific, but I understand your point. It also does seem a bit odd to use a Stanford-branded site as a definitive documentation source for Spotlight generally.

On the other hand, I worry about duplicating content and having to make the same updates in multiple places, etc. But let's revisit our options when the documentation exhibit is publicly accessible and see if we can figure out the best approach.

In the mean time I would be interested in:

Removing the stub sections under "Building an exhibit" Retaining Configuration settings and adding a brief section about Languages that links to Translations

In the short-term, your suggestions for the existing content sound fine to me, although I'd suggest a slight modification: how about we rename the "Configuration settings" section to "Exhibit settings" and move it to be under the "Configuration" heading? Then we can remove the entire "Building an exhibit" section.

We could link the new "Translations" page (maybe retitled "Multilingual exhibits?") under the "Configuration" heading as well.

Basically I feel the "Building an exhibit" section was intended for exhibit curators, not developers (because we didn't have anywhere else for curator-oriented documentation at the time), and curator-oriented documentation doesn't seem like it belongs on Github, which the vast majority of curators have never heard of (or at least never use). So I'd like to orient the documentation on the wiki towards developers as much as possible, and not confuse things with more curator-oriented terminology (e.g., "Building an exhibit").

[aeschylus]

I don't see anything in the resource scenarios page that is inaccurate or out-of-date as far as I know, but might add a section about "indexing" OCR-ed materials for search that discusses adding a IIIF search service endpoint to manifests, or rather, importing manifests that happen to link to a service, in order to address the likely question: "how do I get the search thingy to happen?"

Is this relevant here?