docs.txt 0.0.8 UTF-8 2023-09-02 *---|----1----|----2----|----3----|----4----|----5----|----6----|----7----|--* nfoWare/nfoWorks docEng ======================= DOCENG DOCUMENTATION GITHUB PAGES FOLDER ---------------------------------------- Documentation of docEng tools and approaches is provided here as the source of GitHub Pages for automatic publishing to . This scaffolding page is also published there as passive but reachable content. This scaffolding, and further arrangements are a case of document engineering applied to the docEng project and site themselves. MANIFEST docs.txt this manifest and job-jar file index.md Markdown source for the index.html home page published as about/ subfolder for the about page and subordinate material on the the purpose and management of the project and connection with the "principal investigator." images/ subfolder of images relied upon for various elements of docEng construction/ construction materials and documentation of the structure and authoring of the materials. models/ different models, primarily ones that I have used that demonstrate particular applied models and their workflows. preservation/ activities for preservation involving preservation/forking of materials to gitHub Pages projects *---|----1----|----2----|----3----|----4----|----5----|----6----|----7----|--* Copyright 2021-2023 Dennis E. Hamilton Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. *---|----1----|----2----|----3----|----4----|----5----|----6----|----7----|--* ATTRIBUTION Hamilton, Dennis E. docEng Documentation Source Code Folder manifest and job jar. Text file docs.txt version 0.0.8 dated 2023-09-02 available on the Internet at TODO * This will be the publication staging folder when publication is handled by generation under a framework such as Hugo. The extra stage is to allow review at the authoring location so only publish-ready material is brought here when the time comes. * This is one of the pages that is part of the authoring structure too, so we need to confirm that and also deal with it in the location information. * This is a variation on the site-server model. Document that in the preservation topic. * Explain how this folder is used to generate the GitHub pages, possibly with additional folders that are about the scaffolding and construction materials. * I am not going to use jekyll or use docs/ as framework pages. I will use docs/ as a publishing place for the static materials that are published to orcmid.github.io/docEng but not authored here. Authoring is elsewhere so there can be review, etc., before committing here. * The staging publishing place would be moved here to docs/ from another "publish/public" location that might be copied over a clone location of the GitHub orcmid/docEng/docs folder. * I am going to explore hugo and the hugo-books template with KaTeX support. * Add Apache license and notices page ?? . They apply to the docEng repo, what about the pages published here at docs/ ? * Figure out how to deal with the handling of Hugo frameworks in this context. I want to experiment first. How will that work exactly. * I have not completed the About and Construction stuff on how the default docs/ publishing template works. I do need to handle that. Also, if I branch off into trying a framework, I have to contend with that case also. * I really want to have a sandbox for trying different web-site frameworks and generation methods. I have added wingnut to GitHub. This might be the safest thing. Kept in a separate project so I can migrate it different ways and have it all work. I think what I did in the hexo case should be long forgotten though. * I can attempt to preserve Spanner Wingnut here also. That would be an useful case of the overall methodology. * Add Hugo under tools and handle the establishment and use of Hugo and templates. * If there is a dev for this Hugo-authored structure, it might be about the publishing in Hugo format. * It is tricky here between this site being in a particular Hugo templated and it being something else. So the native or plain case needs to be handled also. * Complete the current construction structure and the about and then also use the construction folder to document the framework(s) used. * Translation is a Skill and also Tools here. I don't know that it applies in nfoTools, although it certainly might on behalf of i18n. And accessibility (a11y). We will see. * There is a good article about translations using Microsoft Office at Provide a link to that. It is not quite accurate in terms of settings, but translation shows up as a feature (e.g., in Word) once the proofing tools are installed. (Not certain this is necessary. Must try another language to see.) * Rescuing and retargeting web sites is also a thing. I am doing that with the Site Builder scheme for nfoCentrale, exfiltrating wingnut, Orcmid's Lair, Miser, and nfoCentrale at least, along with nfo stuff. * I need to point out a significant difference between the GitHub scaffolding and the nfoCentrale Site Builder model around the preservation and visibility of the work items. * It is interesting that the Site Server/Builder stuff got all confused in creation of content management and commerce server arrangements, now vanishing from the Microsoft Learn documentation. The entire history of Microsoft FrontPage, FrontPage server extensions, and integration with source-code management (i.e., VSS) seems to have disappeared from MS corporate memory. * Microsoft Expression Web as a replacement was also not long-lived. The internal competition with Sharepoint was doubtless a factor. And now with concentration on Azure, the whole thing is upended. * The idea of scaffolding and then leaving the scaffolding as the record of the construction and actions taken with it is pervasive. It is like an aircraft carrying or having access its complete construction and maintenance history. This originated in a software engineering course team project (link to it in Orcmid), and I confess to getting fascinated with that and getting lost in it. There may be too much history and fine details, yet it is not known what detail or action will be particularly informative. There is scaffolding with the use of folder-name.txt files among GitHub pages and also other parts of a project's folder structure under git and GitHub. These can interplay. The disadvantage is that the TODOs vanish when they are done. The history vanishes into the git commit histories. * Bring a construction structure here and use that model for the docEng site, now that I know this works on GitHub Pages. There needs to be a folio on the idea, and then different ways of achieving it. On web sites with the Site Builder model, then on sites with the GitHub Pages model. Then when we want to use frameworks and have multiple targets, whether responsive web or persistent document forms, such as PDF or productivity formats (ODF and OOXML especially). *---|----1----|----2----|----3----|----4----|----5----|----6----|----7----|--* 0.0.8 2023-09-02T15:43Z More noodling 0.0.7 2023-08-21T15:10Z Add models/ and TODO musings 0.0.6 2023-08-17T02:44Z Expand substructure and expand TODOs 0.0.5 2022-10-13T16:08Z Manage TODOs, struggle with Site Server model handling 0.0.4 2022-03-26T21:19Z Manage TODOs and prepare for framework introduction 0.0.3 2022-03-21T17:18Z Manage TODOs, consider Hugo and wingnut approaches 0.0.2 2021-10-29T21:46Z Change "master" to "main," add rulers 0.0.1 2021-02-15T00:06Z Add attribution and account for index.md. 0.0.0 2021-02-09T22:31Z Supply minimal boilerplate for the docs/ folder ***** end of docs.txt *****