[ ] I know I just got done moving many of the examples from the sile repo to this website repo, but I would like to move some of them back. In particular now that the package system is much closer to expecting packages to be idempotent and each package has a dedicated subdirectory instead of living in a zoo, I think it might make sense for there to be one example entry per package stored next to the package sources. This would not be managed by whoever was maintaining the package & documentation. We could make rules like they must work in the plain class, etc. That would aid our testing a bit because we could have a whole class of tests that just made sure packages function and their showcase documents build (different from point-perfect regression testing). Additionally we could build the PDFs that showcase each package and embed a shrunken version of them as thumbnails in The SILE Book at the start of each package's documentation.
[ ] The could go for classes and ever languages: one showcase document that at least runs each function once in isolation (as opposed to the current approach to manual that loads all packages in the main document class) could be useful, but for SILE testing and a more complete source of examples for the website.
[ ] With those done, the website repository could focus on mixed use showcases, more "show and tell" sort of examples that use an assortment of tools. They could be tagged with what packages/classes/languages they showcase and be show along with the upstream showcase for specific packages.
c.f. #2
I suggest refactoring the website examples a bit:
[ ] I know I just got done moving many of the examples from the sile repo to this website repo, but I would like to move some of them back. In particular now that the package system is much closer to expecting packages to be idempotent and each package has a dedicated subdirectory instead of living in a zoo, I think it might make sense for there to be one example entry per package stored next to the package sources. This would not be managed by whoever was maintaining the package & documentation. We could make rules like they must work in the
plainclass, etc. That would aid our testing a bit because we could have a whole class of tests that just made sure packages function and their showcase documents build (different from point-perfect regression testing). Additionally we could build the PDFs that showcase each package and embed a shrunken version of them as thumbnails in The SILE Book at the start of each package's documentation.[ ] The could go for classes and ever languages: one showcase document that at least runs each function once in isolation (as opposed to the current approach to manual that loads all packages in the main document class) could be useful, but for SILE testing and a more complete source of examples for the website.
[ ] With those done, the website repository could focus on mixed use showcases, more "show and tell" sort of examples that use an assortment of tools. They could be tagged with what packages/classes/languages they showcase and be show along with the upstream showcase for specific packages.