...
- Small number of folks met Oct 28th for doing a one-day documentation review.
- Not a technical review, focused on community perspectives
- Marked docs that could be improved
- Good notes/suggestions on ways things can be improved. Mostly around better organization, de-duplication, defining things better. These notes can drive documentation updates
- There may be a couple people who are interested in documentation during the sprint, but there may be enough suggestions to support a documentation sprint later on this year or next year.
- Most of the suggested improvements are not technical, so it is not necessary for doc writers to be committers, developers, etc
- awoods: Each release has their own wiki space, but we have a 5.x "head". It looks like the 5.x "head" is what was reviewed. Presumably, it'll be re-named to 6.0. A bulk of the review is likely based on 4.x/5.x understanding. New content and/or updates would need to be added for fcrepo6
- dwilcox: Hopefully, the front-facing parts of fcrepo6 won't change that much from 4/5, but new docs will be needed.
- Fcrepo6 documentation was out of scope for this review. That could be its own sprint, not sure if it should be its own separate effort, or part of a fcrepo6 sprint. Difficult to do anything for fcrepo6 yet, since it doesn't exist. It'd be difficult to write docs for it at this point.
- Desire for a regular rhythm for doc updates.
...
- As an aside:
...
- Islandora stores it's documentation in Markdown . Might be something we want to consider for Fedora.
- On the pro side: It makes it easier to couple code changes with documentation changes
- in a PR
- On the con side: people have to know markdown and git to contribute documentation
- ISLE also does this.
- it'll be interesting to watch how other projects evolve
- Islandora stores it's documentation in Markdown . Might be something we want to consider for Fedora.
Fedora and OCFL:
- There will be support in the spec for extensions (generally speaking) at the ocfl-object level
- Proposal right now is that there'd be a directory (maybe called "extensions") whereby OCFL extensions can define a subdirectory to put stuff in, functioning as a sort of namespace. All content under the "extensions" subdir must be in a subdirectory defined by some extension.
- Mutable head was brought up at the leaders meeting, holding a vote right now (through tomorrow, Nov 1) for approval.
- Folks seem to be aligning around the mutable head direction
- PW doesn't think it'll be that challenging to implement. Not very far into it yet.
- Peter Winckles started a draft proposal for a mutable head extensions
- Seems fairly robust, helped mitigate risk
- A fair number of changes were made 10/30, now would be a great time to re-read it.
...