Re^3: [OT] What is 'Good Practice' use of an .ini/.conf file: Database or Active Document?

[ozboomer]

You are already talking to the actual users of the process, and while the process might be hated by everybody, it seems to already have worked for 40 years. Your replacement of the change process to these file(s) will have to take into account that there are some parts of the existing process that actually work and the new process ideally doesn't break the things that already work while improving the things that are currently preceived as risks or hard.

This is the sort of thinking we've had behind adding some informative headers to the sections. The users can still do what they already do more-or-less BUT we introduce a process that does some reporting on those sections that are 'non-compliant' in terms of the headers the section includes.

Y'see, one of the problems is that the software we're talking about is totally 'closed' and we have no means of intercepting/controlling the input/usage/management of all these sections - we have to use the software to do all that - but there are text files of all the sections that are maintained 'live' by the software... and we can interrogate those text files with our own tools.

So, as far as the documentation of the sections is concerned, we were looking to develop some mandatory/optional headers to be included in the sections, with some application rules... and then our external tools would enforce the inclusion of those headers.

This would mean this current section:

123:
A1=12:MSMA=32:PX=2:
RP=12,23:

...would perhaps become something like:

123:
; Author: Fred Smith (smithr)
; Created: 12-Dec-2016
; Used by: MODV, MODS in XDR Region
; Purpose: Control the rate at which widgets collapse into wigwams
; Keywords: train, isolated, trim, summer
; Expires: 23-Dec-2016
;
A1=12:MSMA=32:   ; To set-up for the collapse
PX=2:
RP=12,23:        ; ...and into wigwams
;

I expect we'd supply some sort of template for users to fill-out and then paste the result into the software's text editor/input... and if our tools find something 'wrong' with the headers, it would be noted in a report.

I note that to get these folks to change their behaviour (and to get some management support about doing something to fix one of the problems that's been identified) will be/already is a significant battle... but they need to meet us somewhere half-way if they want to get their problems fixed, I reckon..

Anyway, this is something of a 'side issue', although I expect we'd get some good value out of it, as there are 1000s of sections with no documentation that the users constantly complain about... and get trashed/re-used accidentally.

Still thinking about the suggested options for how to actually manage the sections themselves...