MDN/Archives/Projects/Development/CompatibilityTables/Vision

FOR DISCUSSION: This document is currently a re-hash of the deliverables. It will most likely be updated after a discussion with the development team.

Vision

Objective of this document

This document should be viewed as a summary of the project priorities to assist us in the decision process.

It is meant to follow the objectives of a Project Vision document defined by the Scrum Alliance.

« Every Scrum project needs a product vision that acts as the project’s true north, sets the direction and guides the Scrum team. It is the overarching goal everyone must share – Product Owner, ScrumMaster, team, management, customers and other stakeholders. As Ken Schwaber puts it: “The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is.” (Schwaber 2004, p. 68) »

Please keep this document as short as possible to reflect the current project direction regardless of the phase we are in.

Vision Board

Vision statement: Serve feature compatibility information across multiple outlets and formats without data duplication

Target group People who make contributions to the documentation site People who work on translating the documentation site People who make websites, visits the documentation site, and wants to learn if a feature is supported Browser vendors representatives who want to update their product’s support data People in projects who wants to use compatibility data into their app

Needs Make sure feature compatibility data is coherent all across MDN Easing data contribution Easing access to data

Product Specialized service accessible using a Web browser to search and edit data Capability to embed information within another web page Capability to edit data from within another webpage

Value Remove data duplication Improve resiliency of MDN site infrastructure

Ref: The Product-Vision Board

---

Expanded vision notes

Which customer needs will the product address?

Priorities are marked by a star (☆)

• View up to date feature support table embedded within documentation site ☆
• Add/Edit a given feature entry within the documentation site ☆
• A way to input/import data (outside of documentation site)
  • Scraping MDN ☆
  • Individual contribution
  • Bulk data entry that may span many features (some features may or may not exist)
• A way to maintain the data (outside of documentation site)
  • Search by Feature, Contributor, Specification
  • Individual contribution (i.e. contributor, time of contribution, contribution data)
  • Bulk data entry that may span many features (some features may or may not exist)
  • Erase one or many contributions
  • Labels so we can support same data display in multiple languages

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
• Ability to erase contributions
• Erasing contributions should adjust internal data representation to the sum of all contributions, in the order they’ve been inserted, modulo the erased entries
• Import data should be structurally identical to the data Export output
• Data input format should be structurally identical for both bulk and individual contribution
• Data should not store localized labels
• Ability to snapshot data ("export")
• Ability to restore service quickly

How does the product compare against existing products, both from competitors and the same company? What are the product’s unique selling points?

No feature for feature equivalent found yet

What is the target timeframe and budget to develop and launch the product?

TODO

---

System properties

Components

(incomplete)

1. Display current data
2. Search current data, by Feature, Author, Browser
3. Search contribution events, by Feature, Author, Browser
4. Compile a data view as the sum of contributions between an initial data and the sum of contributions applied to it
5. Render an HTML representation of the data (may or may not have more than one HTML format)
6. Accept writes only if authenticated to trusted authentication provider
7. CRUD Labels
8. CRUD Contribution
9. CRUD Browser
10. CRUD Browser Version
11. Frontend JavaScript client to add editing capabilities from documentation site embed

Properties that has common attributes

Common properties should indicate the system dependencies and, therefore, makes them critical to supporting other features of the system as a whole.

Data entry

Data entry ("Contribution") is required in multiple contexts.

Namely for the following type of data;

• Browsers
• Browser version
• Feature
• Labels
• Note

In their respective contexts;

• Bulk contribution
• Individual contribution
• Individual contribution from external site
• during initial import
• when making a change or creating a label

Search

Search is required for two different contexts: Current data, Contribution event log.

History of changes

Data contribution and Labels edits will be available for contribution.

In order to support moderation, and the underlying need to allow removal of unaccepted data, we must have a system that handles ways to apply changes in an ordered manner.