#2578 - Official non-maintained status
-
By Chris Graham
- Added
- 14 views
| Identifier | #2578 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | Official non-maintained status |
| Status | Completed |
| Tags |
Risk: Deprecates functionality (custom) |
| Handling member | Chris Graham |
| Addon | General / Uncategorised |
| Description | Particular low-use/high-maintenance features will need to be sponsored.
Sponsorship involves taking direct responsibility including testing and bug fixing, or paying someone (such as ocProducts) to do that. In some cases it may also involve taking some down-stream responsibility, funding or maintaining frameworks or projects that Composr functionality is depending on. Why? 1) Ongoing maintenance of a huge legacy of features is too burdensome 2) In particular some features may depend on third-parties, who may change things at any time 3) In particular some features may be particularly fragile, with a need to constantly bear them in mind for touching many different parts of the system, and regular re-testing, even when hardly anyone uses them 4) But we don't want to remove these features if they will continue to be very important for a small segment of people and need to be in the core of a CMS framework 5) We should not leave things decaying like other software does, conveying important and accurate information to our users is important 6) We want to guide people to a premium experience, i.e. let them know if their configuration isn't optimal 7) We want to give organisations the ability to fund things they are depending on, which seems fair There will be an official codified mechanism for saying which affected features are currently sponsored and not. This mechanism will be used to automatically: - generate a central page on our website (this page will include text derived from this issue's text, and a codename-sorted table of features) [using a block] - add warning notes to feature-associated tutorials [using a Tempcode symbol] - add warnings when the functionality is installed (if relevant) [using a 'checks' hook, or using Tempcode symbols] - add warnings when the functionality is used [using a function call] - add warnings next to config options relating to functionality - automatically override addon categorisation to being 'Development' [a bit of ternary coding within the addon_registry file, where a function is called to get the status] - our release process should simplify down if stuff is not maintained, e.g. if no third party forum drivers are being sponsored, the "test on third party forum" release testing step should be removed - automatically add/remove stuff from our feature list [a bit of ternary coding where a function is called to get the status] Warnings would always link back to the central page on our website. Any of the existing "unsupported" or "(not) recommended" or "not fully supported" labelling would be replaced with this new system. Data will be drawn from a .csv table in the project, with the following columns: - Feature codename - Feature title - Bug-fix sponsor (may be blank) - Current active sponsor (may be blank) - Notes - Non-bundled addon Note that sponsoring functionality initially is not the same as sponsoring ongoing maintenance. Once something is implemented and delivered there isn't a guarantee it can be maintained forever without ongoing sponsorship. No non-bundled addon will be put into the table *unless* it is being supported. The default assumption should be that no non-bundled addon is supported by the core developers. People wanting to support non-bundled addons can enquire and get them added to the list. Most will be supported by bug fixes, and automatically updated as Composr APIs change -- but not to the normal expected quality, and not proactively tested. Bugs may be reported for unsupported functionality, and it may be fixed quickly as normal, or may be left on the tracker indefinitely -- depending on developer availability, ease of fixing the issue, and our sense of priority. The release process should link to the new maintenance page, so the releaser is aware of all complexities that are being sponsored. |
| Steps to reproduce | |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
--Patrick
This isn't really about non-bundled addons per-se. Some show up in the list because they are particularly liable to break (so need special warnings) or are flag-ship, but the assumption is that any non-bundled addon could become unsupported unless explicitly given that flag-ship support.
It's more about ensuring the core product is predictable. Trying to guarantee addon stability is not ever really going to be expected I think.