Fedora Bounties
This page is home to project ideas that are important to the Fedora community but which have not yet been tackled. These ideas can provide a starting point for contributors who are looking for a larger project to undertake. Members of the community are welcome to add new ideas, but are encouraged to try their ideas for interest on the mailing lists first. In adding an item to this list, you accept responsibility for providing any needed specifications and assisting the implementors as needed.
Looking for Summer of Code ideas? We realize the selection here isn't very large. We would love to hear some unique and innovative ideas that you feel would benefit our open source community. As a distribution, we are proud to support a variety of different projects and to promote choice. Our Infrastructure and Documentation teams, among others, are always looking for new toys to help them get their jobs done.
A few other pages that might interest you:
You may find other information or additional ideas using the references listed at the bottom of this page.
Adding an Idea
To add an idea to this list, you'll need to have editing privileges on this wiki. This means that you must be a member of the EditGroup. See the WikiEditing page for details.
When you add an item, please provide a basic summary of what is needed, including basic technical specifications (if available) and what work has already been done. Please also list a contact for anyone who is interested in pursuing the idea.
Current Available Projects
These ideas are just raw thoughts for new projects. Some of these projects may already have people working on them, so you might check around before starting a new project. If a contact is not listed for a particular project, visit the Communicate page for details about how you can get in touch with our community. The fedora-devel-list mailing list would be a good place to start looking for suggestions and leads.
Working, Elegant DocBook to PDF Solution that Benefits all FLOSS
A very systematic, non-hacky, and distribution-agnostic way to do this would possibly be using ReportLab (python-reportlab package; refer also to [1] ). ReportLab uses a flexible, well-defined, and highly customizable XML schema called RML to produce PDF output. ReportLab is in use at a number of commercial sites and lends itself well to on-the-fly production. It is likely ReportLab 2.0 (not yet in release status, but fairly stable) would be required to provide Unicode/UTF-8 support. (Fedora repositories include version 1.2.1, which does not have this support.)
A working solution would include a set of XSLT (eXtensible Stylesheet Language for Transformation) stylesheets, and some Python scripts to apply them to DocBook XML source. The end goal would be a script that takes as input an arbitrary DocBook document that has been pre-processed and serialized by xmllint, and produces a PDF.
This link in the documentation toolchain is badly needed in almost every Linux distribution, and quite a number of other projects. Other solutions are stalled, some are and many involve non-free links in the toolchain.
Discussions ongoing on fedora-docs-list .
Fedora Documentation publishing platform
We've got a small mix of elements that we are working into a comprehensive, end-to-end documentation solution. Some elements exist, some need to be developed. All use popular open standards for XML document publishing -- a combination of Wiki, Plone, Python, TurboGears, DocBook XML, and good old Makefiles are just a few elements in the mix.
We are looking for a developer who can help tie together the elements into a single solution. There are still project-wide changes that can be made about which technologies to choose, and how to use them. One part of proposing for this project includes researching the existing situation and making some recommendations. Another is being able to propose to complete some or all of the pieces here, shown as a plan. You may find that some resources exist you can use in making your coding project happen. Ask questions on fedora-docs-list .
- As a first step, the new publishing platform could include adding a Publish as Draft functionality to the Wiki.
- Publishing platform should be able to use the Wiki's built in tools for converting Wiki content to DocBook XML, take the output and put it into CVS, wrapped in a full book-building template.
- Publishing platform needs to take (X)HTML that is output from the existing DocBook XML toolchain, and publish that to docs.fedoraproject.org
- Currently this publication is a set of static HTML pages that are built with PHP includes. As an initial step, this system may be rebuilt using Python or bash, which are languages acceptable for Fedora Infrastructure.
- One target location for publishing is a Plone content management system (CMS). If this Plone system is going to be in place in time for the development of this new publishing platform, then a new Plone module needs to be built. It should:
- Take a trigger from an earlier publication script to take incoming content, such as from email or Wiki's Publish as Draft function, to then ...
- Checkout and build HTML (and PDF) from documentation source in CVS, then ...
- Publish that content into the beginning of a Plone workflow as a
Draft, and ... - Be able to make a CVS commit back into the source document with the comments of an editor (as commit log and within the body of the content), so that an editor can send a document back to CVS for a re-write with one step, and ...
- When the writer has made changes to the content and wants to resubmit, there is a way to trigger the submission script to put this document back into the same Plone workflow record.
- ... plus other elements that come from the workflow.
Contact: fedora-docs-list .
Publication of all man and info pages for each release
We would like to have every man and info page for each release of Fedora Core and Extras to be available via a simple Web interface,
One option would be a directory full of formatted ASCII files. Another would be a simple search interface or contents listing, with the directory on the back-end.
One objective is to be able to browse manual pages of various releases.
Another goal is to have permanent URIs for documentation and reference.
Having a simple Web-based diff tool to see what was added/subtracted across versions would be cool too.
This could be a relative or a tie-in to DocsRawhide. The man and info pages for Fedora rawhide could be made available through this method.
In the future, I'd like to see this format extended to allow a Wiki-like ability to edit the man pages directly.
See bug #179524: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179524
Added notes from PatrickBarnes regarding the Summer of Code: This idea seems to have garnered quite a bit of interest for the Summer of Code. We have already had a few applicants apply with this idea. We will weigh these applications, and any more that come in ahead of the deadline, and choose one based upon the quality of the proposal. A few things to keep in mind if you wish to apply with this idea:
- The Fedora Infrastructure team, myself included, prefers to avoid PHP for a number of reasons. Python would be the preferred language for any web-based application. PostgreSQL and MySQL are available. SQLite and flat files could also be used.
- This idea seems easy (collect and reformat man pages as text or HTML and publish), but it really isn't a cakewalk. Carefully consider the amount of work involved.
- We don't have a central repository of all files included in the release in a flat-file format. Collecting all of the man and info pages might be the hardest part of this project. We have RPMs, SRPMs and the Source pointers from specfiles in CVS. The file metadata (XML) from the RPM repositories could also be used to identify the man and info pages available in that repository.
- Including man and info pages from released updates would be ideal.
- As there is competition for this idea, your proposal must be of the highest quality, written in your own words. Feel free to Communicate with the Docs team before preparing your proposal. There are no bonus points for getting your application in early.
Contact: fedora-docs-list .
Build an upstream-compatible L10N platform for Fedora
The goal of this project is to deploy a Web User Interface (WUI) that will facilitate translations in Fedora (scope still under discussion).
The most important process of the Fedora Localization (L10N) Project (FLP) is the translation of Fedora applications, documentation and websites in various languages. Contributors identify a resource that needs translation, receive the respective PO file, translate it, and commit the changes on our Source Code Management (SCM) system.
Currently Fedora has more than 2000 contributors who provide, on average, 1100+ committs every month for more than 84 languages. This process is currently done on the i18n.redhat.com server, which has some limitations:
- Translators need two different accounts, one on
fedoraproject.organd another oni18n.redhat.com. - The current system does not allow the FLP community to provide translations for:
- Projects hosted on our main development server,
cvs.fedoraproject.org, like our Documentation and, when F7 is out, probably all applications for which Fedora is upstream (Anaconda, system-config-*, etc). - Projects hosted on
fedorahosted.org, like smolt and pungi. - Projects hosted remotely. Fedora-specific examples are yum and yumex, non-Fedora are all other FOSS software.
This project has two goals:
- Deploy a WUI for translation statistics in Python.
- Provide seamless support for upstream-hosted PO files by acting as a mediator between the FLP community and upstream projects. Ideally, translators will see remotely-hosted PO files like local ones, checkout one with a click, and commit it back without the need to create a SCM account on the remote system.
Plan for development:
- Port GNOME's Damned Lies (DL) l10n statistics interface to Fedora. This step involves working with upstream DL developers and probably doing DL more modular and cross-project.
- Develop a Python program that can authenticate to certain SCMs and fetch PO files. The same program will be able to commit the PO files back.
- Hook-up Damned Lies to this program so that it lists externally-hosted PO files and allows downloading/uploading of them.
File:FedoraBounties l10n-shot.png
Central Proxy Library
Details at https://www.redhat.com/archives/fedora-devel-list/2006-May/msg00764.html
Contact: ?
Web App For Fedora Review Process
I would *love* to see some sort of fancy-schmany "Web 2.0", AJAX-y web application for the Fedora review process. The current process is quite manual and involves a lot of different technologies. It would be great to integrate the whole process with some sort of web application. I envision a lot of automating of the process including the SRPM verification steps and the rpmlint running. Builds could also be done by the system on at least one architecture and/or in mock. The reviewer would then only have to begin after all of the steps that can be automated have been completed. I personally do reviews by using a stock text file that I compiled from the review guidelines (http://overholt.ca/stockreview.txt). It would be great if we could integrate a web app with bugzilla via xmlrpc or at the very least spit out a text file that can be pasted into the review bug.
I think having such an application would ease the Fedora contribution process which would in turn increase the number of contributors -- and happy reviewers :).
Contact: AndrewOverholt (I don't have much experience with the underlying technologies but I have ideas for the design and functionality)
References
Mailing list thread: "Fedora Bounties (seeking ideas)"
Mailing list thread: "Google's Summer of Code 2006"
