Websites/Mozilla.org/Publishing

< Websites‎ | Mozilla.org

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...

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

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

Documentation

Subprojects

Code

Contributor Resources

Project Tools

Meetings