Websites/Mozilla.org/Publishing
This page describes Project Nucleus, a web development project that will modernize publishing on www.mozilla.org.
Contents
Why does this project matter?
www.mozilla.org contains content owned and maintained by numerous teams, including...
- Marketing and engagement content, such as http://www.mozilla.org/en-US/about/
- Policy content, such as http://www.mozilla.org/en-US/privacy/
- Encyclopedic content, such as http://www.mozilla.org/about/forums/
- Product details, such as http://www.mozilla.org/en-US/firefox/23.0/releasenotes/
- Security bulletins, such as http://www.mozilla.org/security/announce/
Here is a list of known, existing publishing workflows. These publishing workflows are pathways whereby content owners can publish content directly to www.mozilla.org. They are distinct from content that is updated by web engineers in response to a request. In many cases, these workflows are essential: For example, the release and security teams must be empowered to publish releases and security bulletins without engaging a web engineer.
While numerous teams have accountability for content published on www.mozilla.org, the www.mozilla.org product manager (Jennifer Bertsch) and the Web Productions team share ultimate accountability for the coherence, functionality, appearance and efficacy of the website.
In order to allow certain content owners be to publish directly to www.mozilla.org, while maintaining the overall branding and functionality of the website, the Web Productions team will undertake a project to provide a publishing system (or multiple publishing systems) that satisfy content owners' unique needs.
(Note: Earlier versions of www.mozilla.org allowed anyone with SVN commit access to publish content to the website. For technical and other reasons, this pathway is not available in the modern website. Until an alternative exists, these workflows are still in place, and they block the Legacy Migration project.
Roadmap
Proposed/requested publishing flows to add to Nucleus
Team
- Product Owners - Jennifer Bertsch, Chris More
- Web Engineers - Paul McLanahan, Josh Mize
- Product Engineer - Justin Crawford
Architecture
Nucleus is a Django (Playdoh) project intended to house numerous applications, each intended to publish a distinct type of templatized content for publication in Bedrock (www.mozilla.org). Nucleus resides on the stackato PaaS and exposes a public API (for reads) and an authenticated API (for writes), as well as a user interface in Django's standard /admin. Bedrock will query the Nucleus API periodically, consume the JSON found there, save it in Bedrock's database, and then serve that data when users request those pages. Other applications may query the Nucleus API too for their own publishing needs; its data will be public.
Why decouple nucleus from bedrock?
- different access control; keeping bedrock very protected from multiple users, multiple environments
- we're not ready to enable /admin or handle sessions in Bedrock
- different SLAs; nucleus admin does not require the same uptime
- separate content from publishing; nucleus serves data to multiple consumers
- allow demo/dev/stage to pull in production-quality data
Why use a local (in Bedrock) copy of nucleus data?
- we don't want to rely on the nucleus system for realtime responses
Why put the local copy in Bedrock's database?
- the number of webheads means lots of copies of the same file if stored in filesystem; introducing potential for error
