Confirmed users, Bureaucrats and Sysops emeriti
1,057
edits
MDN/Archives/Projects/Development/CompatibilityTables/Vision: Difference between revisions
Jump to navigation
Jump to search
MDN/Archives/Projects/Development/CompatibilityTables/Vision (view source)
Revision as of 22:54, 25 September 2015
, 25 September 2015→Which product attributes are critical to satisfying the needs selected, and therefore for the success of the product?: clarify some text, add a question or two
(→Which customer needs will the product address?: copy edits, asking some questions for clarification) |
(→Which product attributes are critical to satisfying the needs selected, and therefore for the success of the product?: clarify some text, add a question or two) |
||
| Line 72: | Line 72: | ||
=== Which product attributes are critical to satisfying the needs selected, and therefore for the success of the product? === | === Which product attributes are critical to satisfying the needs selected, and therefore for the success of the product? === | ||
* Seamless communication flow between separate web applications | * Seamless communication flow between separate web applications: the database, the API, and the MDN production content should always present the same data | ||
* Every | * Every translation of a given article should display the same compatibility data, just presented according to the user's locale | ||
* Erasing contributions should adjust internal data representation to the ''sum of data entries between an initial state and the entry events applied in an ordered manner'', modulo what's been erased | * Erasing contributions should adjust internal data representation to the ''sum of data entries between an initial state and the entry events applied in an ordered manner'', modulo what's been erased | ||
* Import data should be structurally identical to the data Export output | * Import data should be structurally identical to the data Export output ''What does this mean??'' | ||
* ''data entry'' format should be structurally identical for both bulk and individual contribution | * ''data entry'' format should be structurally identical for both bulk and individual contribution | ||
* Data should not store localized labels | * Data should not store localized labels; these should be stored in a centralized manner which supports localization of those labels | ||
* Ability to snapshot | * Ability to snapshot the database ("export") into appropriate formats (json, HTML...?) | ||
* Ability to restore service quickly | * Ability to restore service quickly | ||
** Easy to maintain the service | |||
** Easy to restore backups of the data to roll back if a data irregularity occurs | |||
=== How does the product compare against existing products, both from competitors and the same company? What are the product’s unique selling points? === | === How does the product compare against existing products, both from competitors and the same company? What are the product’s unique selling points? === | ||