Welcome to docEng Discussions! Please Say Hello

[orcmid]

👋 Welcome!

Discussions is a place to connect with others curious about, interested in, or wanting to apply Document Engineering, including construction of guides and tools that support authors and document-engineering lifecycles.

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• The docEng project is about words in the open and code in the open, and it demonstrates some of both.
• docEng Discussions is a way to discuss aspects of this, including the nature of Document Engineering and the particular avenues addressed here, have much to do with using GitHub as an instrument.

To get started, comment below with an introduction of yourself. Describe your interest and a little about how you might participate as a contributor here. Those will be words-in-the-open and you can always edit your own, so don't worry about perfection. Rely on the welcoming environment for cooperative effort that is intended here.

[orcmid]

My name is Dennis E. Hamilton. My Internet and gaming handle is "orcmid." I have had that since around 1978 when I participated in my first on-line multiplayer game, DecWars.

I have always been interested in documents as an object of interest almost more than I am drawn to writing. That started for me as a youngster fascinated by rubber movable type used with stamp pads, and then spirit duplication using a cooking tray, and even making mimeograph masters after getting my first typewriter, obtained as a premium for selling newspaper subscriptions on my morning paper route.

When I began working with computers in the late 50s, one of my first interests was in documentation, what are now called "man pages." We did not have those on-line, there was no "on-l;ine" available for that. As a student programmer, one of the main projects I was part of involved creating a guide to a collection of IBM Type 650 software from various sources for use in social-science computing efforts.

Documents and document processing have always arisen in my career, especially at "The Document Company" (Xerox Corporation) including XSoft, the California-based software subsidiary. There my interest was focused on document-management systems, standards for interoperability of document-management systems, and since retirement, standards for document formats ODF and OOXML. Long before that I also had a small hand in a TIFF specification version, and going farther back, the ASCII character code standard). I also had a glancing relationship with the International ODA (Open Document Architecture) and SGML specifications before XML ate the world (since eaten by JSON).

Document Engineering is about arrangements for the lifecyle of words and documentation, especially in the open. My blogging involved a little document engineering, once I created a tool-chain for managing web sites and blogs. I adapted the Microsoft Site Server model involving Front Page, Visual Source Safe, and IIS for local creation and management with publishing by FTP to the public web locations. A VSS feature for sharing content across projects provided a way to separated authoring from the periodic capture of a release that would be synchronized with a web site. I still use that. I do. At some point I will not be able to keep the setup running.

In the midst of my developing personal web sites (and a Software Engineering online team project), I realized that I was carrying out document engineering. I then created procedures and templates for my implementation of some particular document-engineering patterns There are techniques in the organization of web sites and how their construction is reflected in materials on each site itself. I do not claim that the sites are self-documenting, only that each site has a skeleton and scaffolding that is available for inspection, and there is a way to know the history of site materials and the changes and work-items introduced over time. My GitHub projects embody a flavor of that.

Creation of GitHub project orcmid/docEng is intended to include solutions to a particular problem. I keep needing to organize document engineering in GitHub projects and their documentation. Much of it is reusable across projects and I was wondering where to put such introduction, getting-started, and help materials for reuse. docEng is a place where such content can be housed as well as employed for it also. There will be the Document Engineering of docEng and also the capture there of patterns, procedures, and guides usable in other efforts.

The research challenge for docEng is identifying how a GitHub-platform environment is made practicable for writers that are not software developers or even super-users. Put another way, "If pandoc is the answer, what is the question?"