Configuration Tools

Configuration tools make it easy for a Community facilitator (system administrator) to configure the environment for their community of writers.

Wiki has the following hierarchy:

Configuration (traditionally considered) applies to the farm (server) / site level of hierarchy. It is the way we code the properties of an entire site of authors (farm), or an individual site owned by an individual author.

Tools applied to a farm or site affect the behaviour and possibly look of the entire site or sets of site. This is a very different behaviour to tools that affect the refactoring of an individual paragraph item of content, that may be forked and present in multiple copies across many sites and owners.

We anticipate a time in which there are many softwares that take a view on how to present federation json. Wiki-clients, and in particular wiki servers are constructed in a minimal fashion so that it is within the reach of an individual developer to create their own opinionated view of the data, and implement this in a new server or new client.

In such an ecosystem of agile software development, configuration may be something that many servers wish to take advantage of / interpret.

Wiki needs a way to indicate to the author that their actions will effect a site or a farms scope, and to distinguish this from item-scope.

This will help both in terms of navigating the complexity and abundance of tools that we anticipate the community providing, and help build a mental model for the author regarding the architectural consequences implicit in their actions.

That we consider configuration of the server to be one of a number of Dimensions of Wiki. We ask ourselves why configuration needs to be it's own distinct format, readable only by a system administrator.

Rather we propose that site configuration be simply another wiki-page json file stored on the server. Human readable, forkable, and able to leverage all the usual tools of wiki - just in it's own domain.

The current Status Folder represents the way this domain is implemented in the flat file architecture of wiki. We anticipate the ability to place wiki-pages in this folder to alter the configuration of a wiki site.

By convention wiki-plugins that affect the scope of an entire site, would be placed on a wiki-page in the status folder. Should the wiki-client have permissions to modify this site-json, the author (previously know as a site-administrator), would expect the behaviour to affect the entire site and not simply a single wiki-page or item.

As with any wiki-site, we have the concept of About Home. The welcome-visitors page, could be names welcome-facilitators, or more conventionally "welcome-administrators".

Such a page would be read by the server on boot, and information contained in the page-json parsed as with any configuration file to alter the behaviour of the server. this mechanism could be extended in the future (as it is for refactoring tools (ie our present wiki-plugins) to be a browse-able suite of pages containing explanations and interfaces that affect site-configuration.

We choose this name advisably. Not because we seek to reenforce the current politics of system administration, but because we wish to use language that is hard to co-opt and points to dangers implicit in the architecture.

Site administration wiki-pages could have a "red" halo of power associated with them by the wiki-client signifying their domain to the author.