Project Open CSP

What is the goal of this initiative
The goal is to have a MediaWiki solution that can serve as content services platform for large companies.

Such a platform should be an open source alternative for products like Confluence.

Compared to those products such a platform would typically provide better flexibility and lower cost.

What do CSP users want?
The assumption is that companies want:
 * An easy to install CSP framework with lot's of out-of-the-box features
 * High flexibility in creating custom features and adapting features to company processes, policies and standards
 * Ongoing development in line with common DevOps practices

CSP Meetings
Regular meetings are held to discuss the CSP.

2021-06-02

CSP Topics
Topics that have been discussed (CSP Meetings) or will be discussed, are:


 * Editing content-centric pages

An easy to install CSP framework with essential features
The CSP framework should have a set of essential features that are supported by high quality extensions. Also they have to be tightly integrated and work together perfectly. The essential features with their supporting extensions are:

Plug-in market
The CSP framework is a perfect foundation for plug-ins that can be installed on top of it. These plug-ins of course need to work well on the framework, but need not guarantee to work well with other plug-ins. Suppliers can provide suites of plug-ins that work together well, but the user of the CSP decides which plug-ins to use. The purpose of the list below is to create a shared understanding of what plug-ins can do.

Support for DevOps practices
Some of these practices need special attention because they are not straightforward for a MediaWiki based CSP. They are: The main reason why these practices need special attention is that features often are (partly) implemented as content. Templates, forms, Lua modules and widgets are pages in the wiki and therefore technically should be considered as content since they live in the database. MediaWiki doesn't provide a standard way to deal with this in the mentioned practices. For version control those pages need to be as files on the server. For continuous integration and deployment there need to be tools to get those files as pages in the deployed system. For automated testing there need to be tools that work within the system on those pages.
 * Version Control for all system artifacts
 * Continuous integration and deployment
 * Automated testing

Some tools are available to support this.