MDN/Projects/Development/Git Backend
From MozillaWiki
< MDN | Projects | Development(Redirected from MDN/Development/GitBackend)
Project statement
Kuma implements a crude version control (VC) system for wiki pages atop a MySQL database. This system is cumbersome and full of reinventions of things done better elsewhere.
Git is a distributed version control system that is popular, well-supported, and does most of the things Kuma tries to do in much more elegant ways - at least, with respect to VC.
So, it might be interesting to look into swapping out Kuma's use of MySQL for version control and replacing it with a Git-based backend.
Some improved VC features we could employ:
- overall better version control mechanisms & history retention
- tagging & branching, to accommodate content that varies with product versions, dev cycles, etc
This could also offer a lot of generative opportunities to consume & manipulate the MDN document corpus:
- mirroring the entire public document corpus on GitHub
- e.g. Content for 3rd party apps. Allow 3rd parties to build e-books.
- allowing the MDN document corpus to be manipulated by non-MDN tools and scripts
- e.g. Don't like the Kuma editor? Build your own.
- accepting Pull Requests against the corpus, allowing for reviewable changes that span multiple documents
- e.g. Mass atomic page moves. External tools to update compatibility info across many pages
Inspirations
Using git as the data backend for a wiki is not a terribly original idea.
- gollum - GitHub's wiki
Implementation resources
- bug 756547 - Investigate a git-based backend for the wiki
Next Steps
- Experimental research into using git as a data backend in a Django site
- Migration scripts to convert from documents in MySQL to a git repos
Experiments
- Create a script to export some wiki content into a git repo and invite new contributors to edit there
- Validates or invalidates the assumption that git-based content attracts new contributors
- Try bug 938169 again with a script that manipulates files in git
- Validates or invalidates the assumption that git-based content lends itself to more tooling