I would like to share feedback from Craig Cook, the person who is
responsible for supporting QMO's infrastructure.
On 6/20/14 2:33 PM, Parul Mathur wrote:
> Hi Craig,
>
> The Mozilla Quality Assurance team is looking for feedback regarding its
> website
http://quality.mozilla.org (QMO). As the person responsible for
> maintaining its infrastructure, I would be interested in hearing your
> thoughts on where you see room for improvement.
>
> 1. Going back all the way since you first started with QMO, what have
> been your biggest headaches with maintaining QMO's infrastructure? What
> about software security?
QMO is running on WordPress, an open source, PHP-based blogging
platform. It's very popular and very good at blogging, but it isn't a
full-featured, robust CMS for managing non-blog content (I'm defining
'blog' as an ongoing series of regular updates, published chronologically).
WordPress does support simple static pages (each a standalone, non-dated
page as opposed to a dated blog post) so we used those static pages for
the QA docs, but it's not really an ideal system. Organizing and
maintaining a large number of hierarchical pages in WP is kind of a
pain. That simply isn't what WP was designed for.
There were a number of functional requirements that WP doesn't provide
out of the box, so we turned to third party plugins. For example, WP
doesn't offer any kind of event management, so we're using a plugin
called The Events Calendar. WP can't syndicate content from external
websites, so we're using a plugin called FeedWordPress to fetch RSS
feeds and generate the Community page. We're using a plugin to generate
the breadcrumbs on doc pages, another plugin to display recently updated
docs in the sidebar, and so on. All things people wanted the site to do
but that WP doesn't provide without extra code.
QMO currently has 15 active plugins, though that number was even higher
not so long ago. For a while QMO was using BuddyPress, a very elaborate
plugin that turns a WordPress blog into a sort of social networking
site. It's basically a platform on top of a platform, but it was really
complicated and hard to use and prone to spam. In the end we barely used
any of the functionality BuddyPress promised and finally just removed
it, which made QMO much easier to maintain. Even then, keeping a large
number of plugins up to date can be tedious.
We deliberately didn't automate plugin updates because BuddyPress was so
fragile that we needed to test every new update to make sure it wouldn't
break the entire site. Even without BuddyPress, we're still not
automating plugin updates and tend to fall behind quickly. We're also
stuck on a very outdated copy of The Events Calendar because the plugin
authors completely changed the way it worked some time ago and we simply
haven't had time or resources to reengineer parts of the theme to work
with the newer version.
WordPress plugins are usually authored by individual volunteers, so code
quality varies widely. Mozilla's security policies set a high standard
for any third party software installed on Mozilla systems that could
potentially compromise the server or user privacy. Plugins need to
undergo a security review and they don't always pass, meaning in some
cases we have to find alternatives and/or work with the plugin
developers to patch the vulnerabilities.
> 2. What is the thinking behind the Community page in its current form?
>
https://quality.mozilla.org/community/
The original intent was to create a "QA Planet" that would syndicate
blogs of QA team members and contributors. Since then I'm not sure the
community has found value in it, so it may not be worth maintaining it.
> 3. QMO is currently powered by Wordpress. Is there any other team blog
> in Mozilla that is powered by Wordpress? What would be the pros and cons
> of having a Wordpress-powered team website?
All of
blog.mozilla.org is one multisite installation of WordPress and
many teams have their own blogs there. Otherwise the most prominent
instance of WordPress I know of is
hacks.mozilla.org. Mitchell's blog at
blog.lizardwrangler.com and Brendan's blog at
brendaneich.com are also
running on WordPress but they're more straightforward blogs without many
bells and whistles.
The upside of WordPress is that it's a hugely popular open-source
project, under constant development, and with a very active community.
It is first and foremost a blogging platform and that's what it's best
at. Many people try to bend WordPress into a more full-featured CMS for
non-blog content and, in my experience, the further away you get from a
traditional blog the more problematic WordPress becomes.
If QMO is going to move toward a more traditional blog, then it makes
sense to stay on WordPress rather than switch to some other blog
platform that may be less mature or feature-rich than WP. If QMO is
going to become less of a blog and more of a static site without the
need for regular chronological updates, then it might be better as a
standalone Django site. If it's going to be a wiki, then it should just
be a wiki.
If it's going to be a combination of everything (bespoke static site +
blog + wiki) then it's a case of finding some way to integrate several
different platforms as seamlessly as possible, which can be done with
proper planning (though an integrated wiki sounds like trouble).
Obviously it all depends on what sort of content you intend to host and
how you need to manage it.
> 4. Are there any Mozilla team blogs that are powered by Django? What
> would be the pros and cons of having a Django-powered team website?
Most Mozilla websites are built on a Python+Django platform. The only
Django-powered *blog* I know of is
https://mobilepartners.mozilla.org
which still isn't really a blog, but uses Mezzanine as its CMS
(
http://mezzanine.jupo.org). Mezzanine is pretty new and doesn't seem as
full-featured as WordPress, though I haven't worked with it myself so
I'm not really qualified to give a detailed assessment. I've heard mixed
reviews.
Again, the question of platform is mostly a question of the type of
content QMO will house. If it's a blog, I recommend WordPress. If it's
not a blog, then I do not recommend WordPress.
If it *is* a blog and you just really want to use something that isn't
WordPress, you should evaluate all the options objectively and make an
informed decision rather than take a knee-jerk opposition to WordPress
for the sake of it.
My best advice is: Don't start by picking a platform and then stuff your
website into its box. Instead, figure out what you want from this
website and then choose a platform that meets your needs. Define the
problem before you start trying to solve it.
That being said, you still have to work within some constraints. It's
really hard for one site to do absolutely everything, and cramming in a
lot of "nice to have" gizmos often detracts from the "must have" core
features. You start with a wish list then cut it down to something you
can actually build under the given constraints. Sorting out a realistic
set of requirements will inform your choice of platform.
> 5. If the QA team were to re-design QMO while retaining Wordpress, what
> would be the scope of work involved?
The current QMO theme incorporates a lot of custom code to enable
features and functionality that WP lacks out of the box, with third
party plugins filling in many of the gaps. The scope of a redesign is
only dictated by your requirements for content and functionality.
If WP meets your content needs without a lot of custom hacking, it could
be relatively simple to put together a new theme. If you need lots of
custom features, that obviously requires more effort and/or finding and
integrating suitable plugins. And, of course, if you add a lot of
plugins to get more special features, we could be right back where we
are now.
> 6. If the QA team were to re-design QMO while switching to Django, what
> would be the scope of work involved?
This would pretty much mean building a brand new site from scratch. It's
impossible to estimate the scope without a better sense of the
requirements, but to give you some sort of ballpark, the webprod team
typically does this sort of thing in around 8-12 weeks with two or three
dedicated developers, a graphic designer, a UX designer, a QA engineer,
and a project manager. It is not something to be taken lightly.
> 7. Going forward, what is your vision for QMO?
I'm probably not qualified to present a real vision for QMO since I'm
not a primary user. I'm sure your team and community has a much grander
vision than I do. You need to decide what you want to get from QMO and
go from there.
I hope this proves helpful and I'm happy to answer any other questions
or offer any further advice/opinions.
Cheers!
Craig Cook