Community Platform Engineering/FY13 Plan

FY2013 Plan

Red Hat tracks a lot of things by "fiscal year". Every public company has a different definition of when the "fiscal year" begins and ends, but for Red Hat, it begins on March 1, and ends on the last day of February. The "fiscal year" numeric naming is attached to the latest calendar year in the "fiscal year". Red Hat Fiscal Year 2013 (henceforth abbreviated as "FY13") begins on March 1, 2012, and ends on February 28, 2013.

This document is Fedora Engineering's "working plan" for FY13.

New Hires

In FY13, Red Hat hopes to hire people to fill the following full-time Fedora Engineering positions:

• Web Application Engineer - Python, TurboGears, JavaScript
• Fedora Marketing Lead - Lead Fedora Marketing Team, create collateral (internal and external), assist in event coordination, manage Fedora Community Budget, coordinate with Red Hat Marketing This person is being hired, but they're not going to be officially part of Fedora Engineering.
• Fedora Cloud Lead - Work closely with Fedora Cloud SIG, identify areas for cloud technology adoption, compose cloud strategies for Fedora Infrastructure and Fedora users, work with Cloud upstreams (both Red Hat and beyond).

Projects

Fedora Engineering is constantly working on any number of initiatives, but for FY13, our focus will be primarily on six "big projects", in addition to several smaller projects. These projects are both "big" in scope and in importance (and arguably, in time to complete). We reserve the right to add additional projects, big and small, and to postpone or abandon projects. We also are interested in feedback from the Fedora Community on these projects, both in concept, and as they progress towards completion.

These projects are summarized here for simplicity, in each case, further documentation about the projects will be forthcoming (and linked from here). Interested community members (at any level) should contact the corresponding Project Lead.

Big Projects

AMQP Enablement

Project Lead: Ralph Bean

Create a Messaging infrastructure within the Fedora Project to facilitate communication, interaction, and integration between services within the Fedora Infrastructure. An old idea, to be sure (first suggested in 2009), but the time has come to roll up our sleeves and get it done. Some old notes can be found at the Messaging SIG page.

Focus is to enable event messaging coming from every possible useful component within Fedora Infrastructure and beyond (e.g. Bugzilla).

Bodhi 2.0

Project Lead: Luke Macken

There are a lot of issues with the existing Bodhi deployment and its functionality, and a general consensus of how to move forward with the next major revision of the Bodhi Update Management software.

Proposed enhancements include:

• Ensure that a package and its dependencies are always pushed together as a single update unit, even if the update unit is maintained by multiple parties, pushed initially as independent updates.
• Ensure that packages are not pushed which would break dependencies within Fedora (or EPEL).
• Improve the "karma" system
• Cleaner Web UI

More details can be found here: https://fedoraproject.org/wiki/Bodhi/2.0

A rather old mockup can be found here: http://lewk.org/img/bodhi-20-frontpage.png

Eucalyptus Sandbox

Project Lead: Seth Vidal

Fedora currently has more x86 hardware than it needs, so instead of having a fire sale, we will build a Eucalyptus Cluster Sandbox Cloud. This will serve as a proof of concept for Amazon compatible cloud deployments for Fedora Infrastructure and provide a sandbox for qualified Fedora community projects and efforts, including, but not limited to, future buildserver initiatives.

Mailing List Improvement Application

Project Lead: Tom Callaway

At the risk of oversimplifying the most complicated project on the list, this application intends to provide a consistent, real-time, forum style interface for Fedora's mailing lists. Fedora Community members who prefer a mailing list model for communication can continue to receive mail, while Fedora Community members who prefer a forum-style interface to communicate can do so, and both groups are seamlessly communicating with each other.

The point of this effort is not to argue the pros and cons of forums vs mailing lists, but rather, to accept that both have merit and embrace them for what they are and what they can bring to Fedora.

Notable UI concepts:

• Support threading
• Robust search
• User karma (possibly thread karma?), where user and/or post "scores" would be sent in mail headers for possible client side filtering (and UI filtering, e.g. "Don't show me topics started by users with < $FOO karma" or "Hide comments on topics from users with < $FOO karma"). This would be a case where the forum interface would be richer than the mailing list side.

With mailman3 finally getting close to release, we've looked into building an archiver interface on top of it. It looks like it would be very easy to write an interface that does what we want on top of it. We've started working on something with the | hyperkitty archiver It is understood that this project is going to be rather complicated. Lastly, the intent is not to build a "scraper", but rather, to create an infrastructure that populates the forum and mailing list aspects simultaneously.

Some writeups from Mo Duffy here:

• http://blog.linuxgrrl.com/2010/03/16/a-rich-web-interface-for-mailing-lists/
• http://blog.linuxgrrl.com/2012/03/13/mailman-brainstorm/
• http://blog.linuxgrrl.com/2012/03/14/mailman-brainstorm-2/

And if you don't care at all about forums, at least there should be an improved archiver as part of this goal. :)

P.S. No PHP. We promise.

OpenBadges

Project Lead: Ralph Bean

Fedora will setup an instance of the Mozilla OpenBadges API, and integrate badges cleanly into all possible areas for Fedora Community participation. This includes the possibility of pushing badges directly to the Fedora desktop. Much of this work will depend on the AMQP enablement.

We will build off the very basic ideology found in Fedora Tagger, and in fact, Tagger will be the first Fedora application to be Badge enabled.

Mozilla OpenBadges Home Page: https://wiki.mozilla.org/Badges

Maintenance of existing apps

Project Lead: Toshio Kuratomi

Maintaining our existing apps is a big job. I've been spending a large part of the last six months getting FAS into a state where we are releasing regularly with new contributors able to dive in and contribute new code that they see in a new release in a timely manner. I want to do the same for our other apps and also grow the number of people who can be manage releases of the apps we have.

The next application that I'm going to be working on is pkgdb. I'd also love to find people who would like to manage a FAS release or two. FAS is pretty routine to release now. It would be great to find people who would take over the reigns from me to make releases of it.

Smaller Projects

More Fedora Apps as Games

Project Lead: Tom Callaway

The idea here is to build on the work in Fedora Tagger and OpenBadges to bring more Fun (the unofficial sixth "F") to Fedora.

Wherever possible, these "game" apps should try to have a tangible win for Fedora, for example, playing Fedora Tagger improves the Fedora Packages search. That said, it would even be interesting to build Game or Game-like apps that Fedora Community Contributors and Users enjoy, even if they don't have a tangible benefit to a Fedora need. Not a big priority, but something where we are open to community ideas. One possible idea: An avatar creation/customization game/tool.

Statistics ++

Project Lead: Ian Weller

With the AMQP enablement, all sorts of new and fun statistics will become possible. A big picture future goal would be to create an intelligent statistics interface to Fedora to allow people to generate their own statistical queries, along with showing some common ones (user created ones, even). However, in the near term, we are far more likely to provide some new statistical reports based on the data generated via AMQP enablement. We are also open to suggestions on areas where you would like to see some statistical data.

Static Analysis

Project Lead: David Malcolm

Continuing to improve upon the Python Static Analysis tools and perform static analysis on major Fedora components.

See: https://fedoraproject.org/wiki/Features/StaticAnalysisOfPythonRefcounts#Current_status

Finish off Fedora Packages & Tagger

Project Lead: Tom Callaway

Polish off the remaining known bugs and roll these instances into their final production home. Also, work on enabling PackageKit to use Fedora Packages for searches instead of using blind repodata. Migrate functionality to Packages from packagedb.

Improved Fedora Search

Project Lead: Ricky Elrod

Improve Fedora Search, most notably, the wiki search, using FOSS as opposed to proprietary appliances/software.

Other Ideas

These ideas don't have owners, nor do they have any guarantee of actually happening this year, but if you're looking for something to do, these would be appreciated.

• A Meeting App - next meetings, hot topics, who's saying what, etc. using meeting bot logs
• Teach meetbot how to handle voting
• Spin Master - analysis of what packages added/removed in each spin for each revision
• Automate nightly spin compose tasks, currently a manual process.
• Openshift - Possibly move some simple apps into openshift, get FAS running in Openshift as it's needed for all of our other apps to run
  • The idea is to have development environments for our apps that people can pull up quickly and easily with minimal input from the fedora admins. Then, for the simple apps, we can additionally have those apps run in openshift in production (which cuts down on work that we need to do to maintain those servers and deployment as an rpm, etc)
• Improve Fedora Hosted - Something more like gitorious, gitlabhq, allura