Event Timeline
Comment Actions
Selected architecture principles:
| Principle | Action API | RESTBase | ... |
| Software that interacts with users SHOULD provide consistent internationalization across platforms and follow accessibility guidelines | |||
| Our software SHOULD provide extension points that empower the community with ways to develop workflows using scripting languages, and ensure safety and maintainability of custom scripts. | |||
| Public APIs of our services SHOULD be modeled around abstract use cases, not catering to a specific user interface. | |||
| Data we offer for re-use SHOULD use clearly specified, stable data schemas based on widely used open standards. | |||
| Software components SHOULD be designed to be reusable, and be published for re-use. | |||
| Software that exposes public interfaces for use by other software SHOULD be subject to release management with clear and consistent versioning. Any breaking changes to such interfaces then MUST be announced in a timely and predictable manner over relevant channels. | |||
| Any elements scheduled for removal from a stable public interface MUST be documented to be deprecated beforehand, and SHOULD be kept for for backwards compatibility for a reasonable time. | |||
| All code SHOULD be designed for testability. | |||
| Comprehensive documentation SHOULD be maintained along with the code. | |||
| MediaWiki SHOULD be easy to install and upgrade in a development environment. | |||
| The MediaWiki stack SHOULD be easy to deploy on standard hosting platforms. | |||
| Small MediaWiki instances SHOULD function in low-budget hosting environments. | |||
| Our software and infrastructure SHOULD be designed to be resilient against spikes in demand and failure of backend systems. | |||
| Services and APIs SHOULD be designed to allow the identification of read-only and read-write HTTP requests to optimize routing and caching. | |||
| System design and technology choice SHOULD aim to reduce operational overhead and the cost of change management. | |||
| Our software and infrastructure SHOULD be designed in such a way to prevent unauthorized access to sensitive information, and to minimize the the impact of individual components getting compromised. | |||
| Our system architecture SHOULD isolate components to reduce attack surface while minimizing system complexity. | |||
| Tools and processes SHOULD be designed to allow us to be responsive as well as proactive in ensuring security. | |||
| Our deployment infrastructure and dependency management SHOULD make it easy to keep system components up to date. | |||
| Our deployment infrastructure SHOULD make it easy to change configuration settings without disruption. |