Hi everyone, please find summarized meeting notes of the “Swift Documentation Tooling work group - call for interest (video call kickoff survey)” meeting below.
Attendees
- daniel-grumberg
- daveverwer
- DavidBrunow
- ethankusters
- finestructure
- franklin
- hannahj
- jack
- Joseph_Heck
- pbonneville
- QuietMisdreavus
- ronnqvist
- taylorswift
- tkremenek
- theMomax
- willimholte
Discussion
The main topic of the conversation was “How can we evolve documentation tooling in the Swift ecosystem?”
Joseph_Heck: I’d like for documentation tooling to support cross-module linking (writing a link to an API defined in another Swift module). This is also useful when you own a set of modules.
- taylorswift: swift-biome allows you to do this.
- jack: There are two interesting cases here:
- Documenting multiple modules or an entire package as a single unit
- Being able to reference other libraries that you don’t host yourself
- taylorswift: how are we going to handle multiple URL schemes?
- finestructure: As part of the Swift Package Index effort, we are considering building and hosting documentation for Swift packages, which might help with this. The build system is in place for that.
- taylorswift: I’m concerned with this effort being duplicated with the swiftinit site. Perhaps we can explore integrations. It’s time for the Swift Package Index to vend an API to query the availability of symbols.
- ethankusters: I think we should keep in line with the general Swift package philosophy. Being able to declare a base URL for your framework for easier integration when referencing other modules hosted on different servers.
- taylorswift: Concerns with internationalization, support unicode in URLs.
- jack: there was a proposal to turn non-alpha characters into hyphens, not great solution.
jack: I’d be interested in localization support for documentation.
- Joseph_Heck: Yes, there is a strong desire from the community to have localized documentation.
- jack: Yes, both for reading translated content and writing translations for content.
- ethankusters: This might relate with the efforts to localize the Swift book? There is an interest in using standardized documentation tooling for the Swift programming language book.
- daveverwer: A mechanism to visualize that there are differences between translated versions would be beneficial. It's unrealistic to expect all documentation to be immediately translated. Modification dates would be a good indicator, especially if the modification date for every translation (or at least every translation where the date differs) was displayed on each page.
jack: Also, I’m interested in the versioning of documentation, e.g., through tags.
- taylorswift: lots of packages don’t have version tags, they have toolchain tags
- Joseph_Heck: DocC has a concept of a bundle ID and that appears in links as well. There is also a version mechanism in DocC, and we need to make clear what versions mean. When do I need to specify a bundle ID/version number?
- QuietMisdreavus: it would be nice to be able to view the history of the docs.
- taylorswift: compressing data in an efficient format might be difficult. For example SwiftNIO has lots of tags; many duplicate data.
- daniel-grumberg: documentation is text-based, compression algorithms may do a good job at de-duping text content.
- franklin: might be good to also support viewing diffs of APIs across versions and see what documentation content has changed.
- daveverwer: this has been on my wishlist for a while. Some kind of mechanism to see the progress over time would be really great.
- willimholte: typo fixes have a different value in documentation changes. Do we want to allow hiding some changes and selecting what changes to display
- daniel-grumberg: can reasonably detect changes that only affect API rather than docs
- finestructure: Swift 5.6 has a new command to highlight API changes across tags. Might be possible to integrate that with documentation somehow.
- finestructure: is there a stable format to refer to a symbol?
- franklin: The Swift compiler uses USRs to uniquely refer to a symbol.
- taylorswift: swift-biome also uses USRs
- tkremenek: USRs might not be as rich as a concept for identifying an API over time. Is the USR the right tool to use for API changes tracking? USRs exist for both Clang and Swift. It’s a good identifier for a snapshot of the library, but for the evaluation of an API over time, do USRs make sense? Some APIs don’t have a binary compatibility concern. USRs are very tightly coupled to the definition. Might need another concept on top of that for tracking changes.
- ethankusters: If I add an overload, I want to know that an overload was added rather than the previous function was deleted.
- daniel-grumberg: introducing symbol versioning at the doc level or the ABI level could be interesting. Some other languages have that concept.
- tkremenek: Also the question of “what does versioning even mean” needs to be discussed. How is it different to binary compatibility?
- daveverwer: versioning of documentation and of APIs are related but different things
- pbonneville: how can documentation best surface API changes, doc comments?
- daniel-grumberg: also being able to highlight that specific doc comments have improved.
- pbonneville: Automatically add a note for when a documentation was last changed, versioning for a specific document.
- daniel-grumberg: is this something that would be authorable or automatically generated?
- pbonneville: plugging into the commit history would be interesting
- Joseph_Heck: “When was this latest updated” can be incorporated in articles, reference docs. And also the idea of API changes.
- ronnqvist: interesting that there are differences between symbols/new APIs, but also curation changes, new code samples, etc. Need to aggregate diffs over versions rather than on the fly taking two archives—enriching diff data over time.
- franklin: there might be parallels with documentation coverage, documentation diffs is interesting for authors to see how their docs have improved
- pbonneville: Starting simple, with a “last changed” date?
- ronnqvist: A page of documentation might have different sources, e.g., from doc comments in source or in documentation catalog via documentation extension, snippet file—how do you determine the versioning?
- taylorswift: how does this compose with package versioning?
- ethankusters: do we want to directly tie documentation versions to package versions? Might be good default. People will want to update docs without updating their package. Some might not use versioning.
- taylorswift: Use the patch version?
- daniel-grumberg: Patch version might not be the right tool if people are using the patch for functional changes only.
- tkremenek: SwiftPM can evolve as well. The versioning scheme could be enriched to consider documentation. Should there be a notion of documentation identity for non-packages?
- pbonneville: In the same way there is Package.swift with versioning, maybe there could be a configuration file for documentation catalogs.
taylorswift: it’s too early to issue recommendations for documentation, first need to build the tooling
- tkremenek: Agreed. Although it is still good to discuss potential arcs, there might be areas to prioritize.
ethankusters: I’d be interested in continuing to improve the out-of-the-box CLI experience. SwiftPM plugin infra is a good way for integrating documentation generation. Many languages have doc generation support out-of-the-box. Might be interesting to have that in Swift as well, showing up in swift help.
- Franklin: Yes, and I think it’d be interesting to explore the long term goals for hosting documentation. Swift-DocC added support for being hosted on GitHub Pages in Swift 5.6, is that the right long-term solution?
- taylorswift: GitHub Pages isn’t great for hosting docs over time. Links change, no way to redirect links.
Joseph_Heck: When I’m adding code snippets, I’d like to be able to include the same ones into different places without copy/pasting. Include? Snippets?
Joseph_Heck: When documenting internal APIs, documenting for developers of the packages not users. Ability to jump to source.
- taylorswift: How would it work if the other package is the same URL scheme that you are? Each hosting provider (BitBucket, GitHub) might have different ways of representing files/lines
- QuietMisdreavus: having a package define its base URL would help.
taylorswift: could the Markdown package support Collections rather than Sequence? Elements come as LazyMapSequence which aren’t Collections.
franklin: support for more languages, consistent documentation tooling regardless of what language you define your API in. The Swift community’s main language is Swift, but there are others, e.g., Objective-C, C++, REST APIs.
- tkremenek: Agreed. Bridging the gap to what Doxygen supports would be interesting.
Next steps
The group then discussed next steps, i.e., for each of us to think about what areas we’d be able to contribute to and in what capacity. Discussion can continue in the forums.Ted and Franklin will follow up with the attendees of this meeting.