Ideas for Student Projects for 2008
This page gathers all the ideas and pointers/references for the 2008 intern and Summer coding programs.
| If you see an idea here you want to learn about or hack on, contact the people associated with the idea. |
JBoss.org project ideas are found here: [1]
What could these students do for Fedora with a Summer?
Projects can occur in an upstream, as long as the work happens through Fedora and benefits Fedora.
Feel free to comment on the ideas posted here, putting your WikiName in front of your comments. The goal is to consider ideas as proposed until they have faced sufficient peer review, i.e., have stayed unscathed on the page for a while.
Apport
Status: Proposed
Summary of idea: The QA team has a half finished port of Ubuntu' Apport, it would greatly enhance the handling of crash reporting if we were able to finish this work.
Contacts: Added by DavidNielsen, I have no skills but hopefully WillWoods will be able to function as mentor. KyleMcMartin is willing to mentor this.
Notes: More information Apport can be found here: https://wiki.ubuntu.com/Apport
Package WebUI
Status: Proposed
Summary of idea: We need a web interface that is made for end-users to access information about packages. This will be similar to packages.debian.org or packages.gentoo.org in some ways but we hope to improve on those in several ways.
Contacts: Toshio Kuratomi(abadger1999) has agreed to take point on this. Interaction with other developers will likely be needed as this touches many systems. Luke Macken(lmacken), John Palmieri(J5), Ricky Zhou(ricky), Seth Vidal(skvidal), and Mike Bonnet(mbonnet) are all involved in projects that touch on the work to be done here.
Notes: This needs to be an enhancement of the Package Database . The DB schema will need additional tables to reflect the enduser view of data. We'll need to generate dynamic web pages to display the information to the end user and allow them to give feedback/enhanced information about a package.
Design Requirements:
- This must integrate with the PackageDB. Therefore it will be a piece of a larger TurboGears application. Knowledge of TurboGears and python is not required but a willingness to program in them is :-)
- It is meant to be task and application oriented rather than package oriented. The aim is to answer questions like "What application will let me make drawings?" "Is there a python library for formatting documentation?" "I don't like "deluge" but I need something that does a similar thing?"
- We already have package information in several sources. We want to avoid duplicating information where possible but for efficiency we may need to pull some of the data into our database.
- The interface should link back and forth with the existing PackageDB but it is not simply another view of the data. Additional data will be involved.
- Allowing the user to contribute to the knowledge about the package is a goal.
A mockup of what a page could look like is in the MyFedora proposal . Note that the header information is MyFedora UI rather than PackageDB Ui and we'd want to be describing gimp as an application rather than gimp as a package.
Jack driver for Audacity
Status: Proposed
Summary of idea: The Jack Audio Connection Kit enables low latency interapplication audio connections. Many applications currently in Fedora support it and can connect to each other and to the audio card. Audacity is one of them. But its Jack support depends on PortAudio, and to be kind, PortAudio Jack support is sorely lacking. Audacity is an extremely popular audio editor but its main weakness is its lack of a proper native Jack driver. Having one would make it a lot more useful in the context of an audio content creation environment.
Notes: Why is the PortAudio driver not so good?
It cannot react dynamically to changes in the Jack graph, that is, Jack applications already running can be seen by Audacity, applications started after Audacity starts are invisible until Audacity is restarted.
Jack ports can only be selected in the Preferences menu of Audacity. The standard way of handling this in Jack applications is that in the preferences menu you select either the Jack driver or an auto discovery mode. If the Jack driver is selected then the application will connect (register ports) to it on startup (if Jack is running) and will register input and output ports with Jack. Those will be seen in the Jack graph and can be source or sink of audio information to/from other apps and/or the soundcard. Normally the connection with other apps or the soundcard is done externally. Some programs add internal means of connecting to other apps and that is generally not done through the preferences menu (Jack is dynamic), and can show applications that started after (in this case) Audacity starts. Some programs have the extra option of connecting automatically on startup to the first n physical audio output ports which facilitates trivial use of the program.
BastienNocera: we use PulseAudio by default in Fedora, and I don't really see the point of using Jack if we use PulseAudio for "normal" users (most users won't be changing that default). You're better off pushing this request to an Audacity SoC project.
Func / Network Automation
Status: Proposed
Summary of idea: Func is a network applications framework that allows for powerful remote manipulation and scripting of very large numbers of Fedora machines.
This idea is to expand Func by writing lots of useful modules to do all sorts of powerful remote things, making it into the world's best API for remote scripting Fedora over lots of machines at once -- with an emphasis on integrating Func with other tools we already have in Fedora. This would be a particular good project for someone who had an interest in networking, clusters, automation, or security related topics. Contributions to Func wouldn't be limited to just writing modules, as anything networking/automation related is fair game. Contact MichaelDeHaan for more information.
Contacts: MichaelDeHaan
Notes: see https://fedorahosted.org/func
koji hiding binaries/ import secondary repos
Status: Proposed
Summary of idea: For various reasons we need to be able to use a second repo. but still know what was in the build root. or to be able to hide builds for pre-release, security issues. Koji needs to be able to import repodata and know where binaries are while not making them available. We walso want to be able to mark a build as being embargoed and hide it completely. from cvs through to the build happening. to be opened up when embargo is done.
Contacts: DennisGilmore
Notes: https://fedorahosted.org/koji
Integrate Fedora Infrastructure and Eclipse
Status: Proposed
Summary of idea: At present, there is a largely functional specfile editor plugin for Eclipse shipping in Fedora. It would be nice to expand the usefulness of the plugin with the ability to push builds to koji. Using mock from within Eclipse and doing pkgdb and bodhi work would also be nice.
Contacts: AndrewOverholt
Notes:
A Gobby plugin for Eclipse
Status: Proposed
Summary of idea: The Eclipse Communications Framework has shared editing support. It would be nice to have a gobby backend for this so that Eclipse users could take advantage of Fedora's existing gobby server.
Contacts: AndrewOverholt
Notes: http://blog.mricon.com/2008/02/why-is-there-no-gobby-support-in.html , https://bugs.eclipse.org/bugs/show_bug.cgi?id=219829
Windows Data Migration Tool
Status: Proposed
Summary of idea: Anaconda supports partition resizing (including NTFS) in Rawhide now. It would be great to combine this with a data migration tool for Windows or dual booting users.
Contacts: RahulSundaram
Notes: I only have the general idea. Others more qualified, feel free to volunteer
Automatic Updates with dynamic bandwidth throttling
Status: Proposed
Summary of idea: The idea is to update the system using idle bandwidth in an asynchronous, prioritized and throttled manner, i.e to update packages asynchronously from the server. This way the user can continue working while the updated packages are being downloaded without any noticeable changes in bandwidth.
Updates can be done automatically by a cron job or with yum-updatesd, but this will make yum/pup to use whole of the bandwidth. yum has a throttle option but it decides the upper limit of usage of bandwidth. Whereas, with asynchronous mode, limit can be decided dynamically depending upon the current usage. In many developing countries most of the people are on low bandwidth networks or have limited access to Internet. This will help them to keep their system updated with maximum utilization of their bandwidth.
Contacts: SunilKumarGhai
Notes: [1] We can also have some kind of general framework, which can be used by other applications to use throttling in services they provide. [2] We can implement this with repositories over http only. ftp repositories will not work. [3] Maybe work with PackageKit? -- RichardHughes
@RichardHughes: As the idea is moving in development of framework as mentioned in [1] point, we would be able to use it. But still as PackageKit has YUM backend so only http repositories will work. -- sunil
Corresponding Source Web App
Status: Proposed
Summary of idea: Finish design and implement web application that provides downloadable SRPMS for any package+tag in the Fedora Package Source Code Control system. While we provide SRPMS for all packages at release, the updates and rawhide trees churn their packages more rapidly, and will remove the koji-built SRPMS when the binary packages are removed. This would allow people to request source corresponding to the packages they have on ISO media or otherwise.
Contacts: MattDomsch
Notes: http://git.fedorahosted.org/git/?p=correspondingsource.git;a=blob;f=DESIGN;hb=HEAD has mdomsch's thoughts on how it should work.
Extend Bootchart to support SystemTap
Status: Proposed
Summary of idea: Bootchart is a tool for performance analysis, and visualization of the Linux boot process. At present, bootchart uses a logger script to collect the boot information from the /proc interface. It also uses a parser to extract information in a non-standardized format. It would be nice to:
- extend bootchart to collect information using SystemTap instead.
- code the boot information in XML format.
- explore additional metrics that would make bootchart more useful, i.e. finding out the working set size at various points of the boot process, etc.
- test bootchart on Fedora 8/9/rawhide dom0/domU/kvm/etc.
- propose (and possibly implement) suggestions on how we can improve the boot process.
Skills needed: Strong background in Operating Systems. Familiarity with Python, Java/JAXP, XML and C programming. Some experience in kernel internals would be helpful, but not necessary.
Contact: EugeneTeo, eteo_at_fedoraproject_dot_org
Notes: See http://bootchart.org/, http://sourceware.org/systemtap/wiki/, http://people.redhat.com/berrange/systemtap/bootprobe/
A visualization tool for SystemTap
Status: Proposed
Summary of idea: SystemTap provides an infrastructure that simplifies the gathering of information about the running Linux kernel, so that it can be further analyzed for performance or functional issues. This project involves writing a graphical tool for visualizing this information in real-time, so that anomalies can be easily identified. The tool should use configuration files in XML format to describe how it should interpret the output of the scripts. Users should be able to extend the tool by adding new SystemTap scripts. How information should be visualized meaningfully requires more thought during the design phase. One of the main objectives is to make SystemTap user-friendly, and easy to use.
Update: I wrote the following to a student recently. Here's more description of the project: The objective of the project is to create a visualization tool that we can display graphs and statistics in a meaningful way. Another objective is to investigate how we can gather important statistics from SystemTap, and have it formatted in a way that is easy for the tool to display the results. I am not looking at yet another gnome-system-monitor though. A user should be able to specify a systemtap script, have it conform to a specific output format, write a XML configuration file to describe the input format, and output format, and have the visualization tool display it.
For example, we want to monitor lock contention in Linux. We write a script to get hold of futex locks. We write a XML configuration file, specify the output format of the script, and then display the graphs/statistics.
program locks app1 #245 ####### app2 #23 ### app3 #423 ##############
Another example, we want to monitor I/O activities in the system, we take an existing script, modify it to display output for the visualization tool. We write a XML configuration file, specify how the output is like, and then display the statistics:
program reads writes app1 234 23 app2 123 2333 /--------\ app1 _/----\___/ |------------------ app2 -------------\_______/--------\_____
Skills needed: Strong background in Operating Systems. Familiarity with Python/GTK+, and C programming. Some experience in kernel internals would be helpful, but not necessary.
Contact: EugeneTeo, eteo_at_fedoraproject_dot_org
Notes: See http://sourceware.org/systemtap/wiki/, http://stapgui.sourceforge.net/screenshots.shtml, http://www.kernel.sg/roller/eugene/entry/mortadelo_a_graphical_systemwide_strace, http://lwn.net/Articles/271796/
PackageKit Offline Use
Status: Proposed
Summary of idea: Many computers are not connected to the Internet and cannot be updated easily. A solution should be found to use libpackagekit and be distribution neutral so all distros can benefit. For this task, first we would generate top-level use-cases for offline use, and expand on existing use cases. This task would involve reviewing Opyum or APTonCD for ideas and ways to do things better.
This would possibly involve using avahi for client->client transfers, and would have to deal with the trust issues that arise from this. It would also involve generating offline packs for automatic install or automatic update. ServicePack CD's could be shipped on magazine covers with updates to all the typical fedora applications for people without inexpensive network access. This could be investigated further.
Contacts: RichardHughes, richard_at_hughsie_dot_com
Notes: The applicant would need to be familiar with C and a little python, but would be a great way to get into development of a young fast-moving software project.
PackageKit Self Check
Status: Proposed
Summary of idea: PackageKit is complex, and relies on many different parts of the stack, e.g. yum, rpm, dbus, etc. There is currently only limited build time self-checks in the PackageKit source package. We would need to design of an end-to-end test harness for packagekit that would test .rpm and yum on local temporary repositories for a complete self check of the code pathways and packages used. This could be used to trivially check each version of these components before being pushed to an update repository.
Contacts: RichardHughes, richard_at_hughsie_dot_com
Notes: The applicant would need to be familiar with C and a little python, but would be a great way to get into development of a young fast-moving software project.
Non linear ogg editor/ screencast helper
Status: Proposed
Summary of idea:
Still we are missing a good non linear editor for ogg videos. This can be a simple GUI based application to do non linear editing of ogg. Like cutting, mixing the videos. Adding still frames to the video etc. Though this is not a project to be finished within 2-3 months, but we should be able to have a basic application running to do simple edits.
May be having feature of upload videos to fedoratv or integrate itself with recordmydesktop to get screencasts directly. I am looking for more ideas on this.
Contacts: KushalDas kushaldas AT fedoraproject {NOSPAM} DOT org
Notes: Recommended choice of language is Python or C
ValentTurkovic: I have 2 suggestions; First is to try and resurrect Diva Project who started as GSC project in 2006. Second is to work with Pitivi Project because it is on a good path and has ogg editing functionality and easy enough interface. To get an overview of this Diva Project rise and fall please read these two posts. UPDATE: There are two projects that look promissing: saya-videoeditor [2] and myvideoeditor [3]
MDK: State of Diva [4]
Comment on Diva [5]
also look at video demos of Diva Project: [6] [7] [8] [9]
Fedora WebInstall
Status: Proposed
Summary of idea: One of the items that other distributions have been able to accomplish that is still lacking in Fedora is the ability to have a web link, which will allow an update and/or install using an approved yum repository. Similar to OpenSUSE's misnamed One-Click install, or Ubuntu's AptURL feature, building a package repository reference which then uses PackageKit or something similar.
Contacts: ClintSavage herlo AT fedoraproject DOt org
Notes: Proof of concepts are available from the Ubuntu and OpenSUSE website's respectively.
http://packages.ubuntu.com/gutsy/admin/apturl
http://en.opensuse.org/Standards/One_Click_Install
ILA
Status: Proposed
Summary of idea: ILA is "Sanskrit" word meaning "Terrestrial"... The Idea is to integrate all computers reachable (via any kind of network, internet to be most obvious) into a parallel web which is reachable by a single click or shortcut...
let me put the last line as first... "A parallel web which doesn't depends on a central service provider for any of its functions... the core part of the node functionality is loaded with the desktop" so every computer online/lan is capable of being a node depending on the modules activated
Its modular so that new features can be made available...
The architecture, language, implementation are open to discussion... I have a few ideas but most relevant thing to write here would be use-cases which will make the objectives of the project clear..
1. A User is stuck on some problem he just clicks a shortcut to make visible the desktop application goes to query tab and fills the question then hits 'Ask'... now all the other computers (reachable) who have selected i-want-to-answer-this-type-of-questions (which is optional) will be shown a popup on the desktop... all the answers that are sent are then shown on the system where they originated. [much better then a search algorithm you are getting reply from real people]
1. Can be used for file sharing [no need to explain just like any good P2P]
1. A modular design will allow users to choose from large number of attachable modules like the above two such as Distributed-CPU-Utilization applications (like SETI), Instant messenger, feeds collector, news (users can add news and everyone can see it in diff categories)... [use your imagination]
1. The only requirement to use a feature or service is just network reachability. no dependence on any central service provider
First Issue that I see is... It "Should" be usable... (still its an abstract statement :-) ) Although I would like it to run on Fedora and other Distros, porting to any plateforms should be possible Idea is still in abstract form is "Remove dependence on centrally controlled systems...integrate this functionality in the OS" so that new kind of apps/tools/featuers can be created.
Contacts: Added by SiddharthUpmanyu, If you want to take this project contact me at siddharth AT techbugs DOT org.
Transifex ideas (#transifex)
The following are some ideas on Transifex that came up. Feel free to contact DimitrisGlezos for more info and/or extend them with new points in your application.
If you want to discuss any ideas you might have, please contact DimitrisGlezos right away.
You might also want to take a look at L10N/Tools/Plans .
Transifex: Clients, APIs and RPCs (#tx_client)
Status: Proposed
Summary of idea:
Transifex works well as a server and the website workflow works well with new content providers (eg. translators), however not all users find the website efficient enough. Implementing an API callable over http will enable a Command Line Interface, AJAX calls, and integration with other tools.
Contacts:
DimitrisGlezos
Notes:
- Duplication of website functionality
- Damned Lies interaction? (eg.
tx get-file anaconda el.po) - How can we make login work?
- Security a challenge
- Hook-up with Pootle as a use-case scenario?
- If the server has plugins enabled, how is this going to be implemented here? (Interaction with student working on extensions might be needed)
- (...more ideas?)
Transifex: Extension engine (#tx_ext)
Status: Proposed
Summary of idea:
Refactor Transifex's code with hooks (pre, post commit), overridden functions, and classes in order to add a plugin/extension mechanism. Abstract file metaphor, and make support for PO files a plugin and implement a new one for image submissions.
Contacts:
DimitrisGlezos
Notes:
- Student might need to work with the student working on the client to discuss how the client can be extended to implement these plugins.
- Metrics will be needed to see how good the refactoring was, and what opportunities it will provide -- these metrics would be good to be mentioned in the application itself.
- (...more ideas?)
Transifex: Permission and authorization layer (#tx_perm)
Status: Proposed
Summary of idea:
Add user/authorization/permission layer on top of Transifex, to improve the workflow Transifex creates by identifying key user groups and implementing functionality for each one.
- Developers, administrators, language leaders, editors, translators, anonymous users: They all have different things to do in Transifex
- Add OpenID support
- Introduce string, release, translation freezes that influence what some users can do
- Fine-grain permissions in Tx: Language maintainers, approvals by proj/lang/branch, etc. Who owns what, who controls what. Add ability to "hold" and "release" a project/branch, like in elvis.
- Requirement for this idea is to work with the creators of Vertimus. This idea might (or might not) have common ground with Vertimus, and we need to make sure that either Tx can interoperate with Vertimus, or that the V folks know what we are working on and see how we can work together (note: Vertimus is written in PHP, but some interest has been raised for finding ways to work with Tx).
Transifex: Add async repo support (#tx_async)
Status: Proposed
Summary of idea:
Currently Tx requires a constant sync with the remote repo. A submission triggers a push, and pulls happen continuously. We need to add a feature to extend this paradigm with submissions living in Tx, until the next push is run (probably by the developer or an editor).
This way we can enable a bunch of nice stuff like, instead of Tx pushing, add support for the developer to pull whenever she needs. Also, having a temporary upload place which needs approval before actually being committed will help QA and get new translators more easily (language leaders can review). These could either be used as a temporary upload space or as a way to allow non-authorized submissions (an authorized user can move a Draft to an actual submission).
Idea: Split files into multiple chunks and submit them all together?
Contacts:
DimitrisGlezos
Transifex's Submissions revisited (#tx_submissions)
Status: Proposed
Summary of idea:
Currently Tx supports only a small set of submission methods, all tied in with a version control commit approach. We want to create an abstract submission system decoupled from vcs. On top of that we want to rebuild all the current submission methods and to implement a set of other requested methods such as email delivery, filling a ticket on trac or bugzilla etc.
In addition a primary goal is to build a CLI Client so translators can submit their translations directly from their terminal.
Info: Proposed by Christos Trochalakis (application: Tx Submissions revisited )
Transifex: Tx Committer service (#tx_committer)
Status: Proposed
Summary of idea:
Currently Transifex runs as a web server, running the actual commits within the same process. This could be a bit of a security risk, and we'd like to have the commit service run as a different user. An advantage of this is that any repo can run this committer and control the submissions instead of giving SSH access to a downstream project.
- Split committer into a different component
- Move commit code outside transifex/ and into transifex-committer/
- Practically, have it behave as a different application. First, we could communicate with it via an API and then via JSON to have it remotely.
- Use-cases: projects behind a firewall, upsteam projects not wanting to give SSH access, etc.
- Work with SELinux a plus.
Contacts:
DimitrisGlezos
Transifex: Server-federated architecture (#tx_federated)
Status: Proposed
Summary of idea:
One of the most important assets of Tx is its community bridging architecture. When multiple Transifex instances exist, they might want to share stuff, like users, translation statistics and maybe submissions. Eg. a Fedora user could submit something to the Debian server, which will wait the approval of a Debian language leader.
- For a single Tx instance to scale well, one might want to split its functionality into (say) el.fooTx.org, pt.fooTx.org, etc.
- This splitting/joining requires something like a server to server architecture/protocol and the ability to aggregate and delegate stuff on both sides
- Some projects might want to have their own Tx instance which contains internal projects, not publicly visible. At the same time, they might have public projects wanting to freely receive translations, but also they might want to allow their internal translators to use this instance as a gateway to all other Tx servers.
- Minimizing the independence between the scattered Tx instances (ie. building bridges between the Tx "islands") will bring the whole "community bridging" idea of Transifex to a whole new level. This is the goal we want to reach in the long term.
The most important aspect of this idea is architecture design. The student will need to have a very good image of content and translation workflow, the process Transifex adopts, and study how open source projects work together.
Also, most likely the student will want to discuss a lot with the main Transifex developers. Fluent English is probably an important asset for someone applying for this idea.
Transifex: Usability and efficiency enhancements (#tx_enhancement)
Status: Proposed
Summary of idea:
Currently our application to submit translations (Transifex) doesn't have i18n support for translators to be able to translate it. Definitely it is a thing than we have to do. The admin face of transifex needs some enhancements. Currently we just have the option to add modules and repos, but we can't handle them with edit or remove options. All interactions with the user over the application could be quicker and more efficient using Ajax calls mainly with JSON. It could improve the user experience and make a great application improvement for all translators.
Contacts:
DiegoZacarao, DimitrisGlezos
Notes:
- Add i18n support.
- Add user friendly interface to handle modules and repos.
- Should we merge the two modules lists of t.fp.o?
- Make all relevant interactions of application be called using Ajax.
PS: The idea is based on what I'm able to work on.
Transifex: Online editing, integration of Pootle (#tx_pootle)
Status: Proposed
Summary of idea:
Currently, translators have to manually download PO files from outside of Transifex, change them, then use Transifex to submit these changed files to a project's repository. It would lower the bar of entry quite a bit if they could edit the translations, one at a time (i.e.: not the complete PO file, but individual messages), directly in Transifex. With Pootle , there is a web-based PO file editor which could be integrated with Transifex.
The work proposed here involves getting Pootle and Transifex working together, in a way that Pootle uses Transifex to handle and submit files. The idea is that we have a community that already uses a workflow around traditional, VCS-centric translations, which would like to use a web-based translation for some modules. Here are some details about what could be done:
- Add necessary configuration options in Pootle to use Transifex for certain tasks and particular modules.
- Abstract what is needed to retain compatibility with the traditional way of handling files in Pootle.
- Extend Transifex in a way that accepts submissions without the web interface (might need some discussion with the student working on the Command Line Interface).
Contacts:
NilsPhilippsen, DimitrisGlezos
Notes:
- Edit translations directly in Transifex (or in a seamless, integrated way with Tx), operating on individual messages.
- Compare pootle to locally running PO editors (e.g. kbabel, gtranslator, poedit), check if essential functionality is missing and eventually implement it (e.g. does it display eventually included source code comments which help translating the message, cf. "xgettext --add-comments ...").
- Evaluate whether certain Pootle functionality (e.g. translation suggestions) is needed or can be disabled for Transifex.
Smolt: Pretty Web 2.0 Interfaces
Status: Proposed
Summary of idea:
smolts.org stores alot of information already. Getting the information out to the public in the way that is useful to people is hard. There is a number of ways this can be done, and we've discussed many. We are looking for someone who is interested in finding out ways to tell people more about their own computer.
The Smolt program collects statistics about hardware running Linux and other data that goes with it. It collects lists of hardware devices, type of CPU, hard drive information and other statistics for each machine. While we can deliver statistics that are useful as fun factoids, they do not help out people looking for detailed information. This also does not inform people about any known issues about their machine. Two classic examples of what we are looking for are these:
- Joe wants to know how many machines running Fedora 9 Betas have SELinux enabled
- Fred needs to know that there is new eratta for his soundcard, perhaps we can make sound work on his new machine finally!
- Tim's machine works perfectly, how can he tell us this, so that we can mark our stamp of approval
These are only guidelines of the things we are looking for. This project is very open ended, and you can do what you feel like. New Ideas are very welcome. You will work concurrently with one or two other developers who will work on parallel ideas, so you will not be completely on your own.
You will need only some basic web skills and a basic understanding of data structures. This project is based on implementing whiz-bang ideas, and not on using technology X. Smolt is based off of Turbogears, SQLAlchemy, and MySQL. Basic experience in any of these technologies, or just Python is a plus..
Contacts:
- YaakovNemoy
- MikeMcGrath
Notes:
- Create a good web interface to access data from the server
- Make Smolt more helpful to the end user
- If you like buzzwords, this project is very Web 2.0 oriented.
Election Software
Status: Proposed
Summary of idea: Currently, our election software can only handle one groups (FESCo, FAB, etc.) election at the time. We would like to see it modified to handle multiple groups at a time.
Contacts: ToshioKuratomi, BrianPepple
Notes: The current software we're using resides at http://cvs.fedoraproject.org/viewcvs/fedora-vote/?root=fedora
If there is enough time during the GSoC, we would advocate rewriting this software as a TurboGears app. This will make it 1) fit into our existing infrastructure (auth will be very easy, for instance). 2) Make it more extensible. So we could add history view of past elections, on-the-fly updates of how the vote is going, etc.
Spin chooser
Status: Proposed
Summary of idea: In this idea spins can be chosen while installing fedora. If somebody has downloaded a dvd or a cd he can chose the a predefined group of packages defined in the package chooser such as choosing gamer will install all games and utilitiess available in the dvd and the rest from internet. This would save people time as they won't have to select apps one by one in the package chooser
Contacts: arnavkalra007@gmail.com
Notes:
Idea Name (Template)
Status: Proposed or Ready for Use
Summary of idea:
Contacts:
Notes: