Closed Bug 1240774 Opened 8 years ago Closed 5 years ago

Generate and expose a UUID identifying MDN pages

Categories

(developer.mozilla.org Graveyard :: API, enhancement)

All
Other
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jwhitlock, Unassigned)

Details

(Keywords: in-triage, Whiteboard: [specification][type:feature])

What problem would this feature solve?
======================================
MDN requires a way to associate a page with a BrowserCompat (BC) feature, so that the specification and compatibility data can be injected into the page at render and display time. The design used a slug, that was not expected to change, as the identifier. However, there was no agreement on the format of these slugs [1], so new ideas were explored.

Instead, a UUID will be used to identify BC resources, including features [2]. If the UUID is generated on the MDN side, and uniquely identifies an MDN page and its localizations, then this can be used as the BC Feature UUID as well.

To reuse the UUID, it needs to be available in the Kuma page API [3] during the import process.  If the UUID is available in the API, the KumaScript can be used with no parameters for the default case of a feature reference page, and with a UUID or alias parameter when embedding compatibility information on tutorial or other pages.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1078699#c2
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1230306
[3] https://developer.mozilla.org/en-US/docs/Web/CSS/background$json

Who has this problem?
=====================
Staff contributors to MDN

How do you know that the users identified above have this problem?
==================================================================
The initial conversion of MDN pages used slugs as the identifiers, and staff had difficulty using these for Javascript reference pages, because the  auto-generated slugs were unintuitive for the long JS URLs.

How are the users identified above solving this problem now?
============================================================
The importer was updated to show the conversion KumaScript, so that manual conversion was a copy-and-paste operation. However, manual conversion of pages has halted until UUIDs are available.

Do you have any suggestions for solving the problem? Please explain in detail.
==============================================================================
Add a UUID column to wiki Document model [4], and populate it in a data migration. Add this UUID to to the JSON data returned by the API.

[4] https://github.com/mozilla/kuma/blob/b96ff3b53a60d0b5a0b6d26aa4d63f5cc1653e3e/kuma/wiki/models.py#L174
[5] https://github.com/mozilla/kuma/blob/b96ff3b53a60d0b5a0b6d26aa4d63f5cc1653e3e/kuma/wiki/models.py#L638

Is there anything else we should know?
======================================
This should be done before the BC API uses UUIDs as primary keys, so that the BC importer can import the UUIDs, rather than requiring a data entry job to go from BC data to Kuma data.

The UUID was added in https://github.com/mozilla/kuma/pull/3795, as part of bug 1246967.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.