This year's Google Summer of Code is under way. Updates are posted here: http://gsoc2010.wordpress.com/
Howdy Students! Google Summer of Code is a program in which Google sponsors exceptional college students to develop open source code under the guidance of mentoring open source projects. WordPress is very pleased to be participating as a mentoring organization again this year. Students who complete their summer projects successfully and on time are paid a stipend by Google that adds up to $5,000 for the summer. Project progress is evaluated at midterm and at the end for payment consideration. To apply for a GSoC slot working with WordPress, you should be proficient in PHP (and JavaScript if your project involves a significant amount of front-end code), and have familiarized yourself with the WordPress codebase.
Applications are now being accepted; the final application deadline is April 9, 2010. Below are some suggestions for project proposals, our list of potential mentors, and instructions for how to apply. Please be sure to use our GSoC 2010 Application Template. The very best way to up your chances of being selected for a project is to start learning the WordPress codebase now, get familiar with the development process, and submit a couple of patches so we can get an idea of your abilities. We've also listed some resources for getting started on our GSoC home page.
Note to community members: Ideas should only added to this page by approved mentors, as they can only be taken on with a mentor to supervise. If you would like to propose an idea for a student to do, please suggest it to the core team to see if it's something they want to pursue (try wp-hackers, wpdevel.wordpress.com, or the IRC chat at irc.freenode.net #wordpress-gsoc). If you want to propose ideas for WordPress in general, please do so at the Ideas forum.
If you have your own idea for a project, include it in your application and describe it thoroughly. You are not limited to ideas from this list.
Know you want to propose a GSoC project around WordPress, but aren't sure what you want to do? Below are a few ideas we think would work well as GSoC projects. Also see the popular ideas submitted by members of the WordPress community. If you share one of their passions, why not make that idea your own? Also, check out the ideas from last year.
Update 4/08/2010: Some Ideas have gotten more attention than others. Since applications are due tomorrow, we're adding the number of applications each idea has received so far, so if you are going to submit an application you can potentially choose an idea with less competition.
This is an idea that's been suggested many times and it never seems to make it into a release. We'd love for someone to take this one. When you first set up a WordPress site, there are certain steps you have to go through. Pick a theme, change your password, edit your tagline, choose your comment settings, etc. It would be great if on the Dashboard screen there was a module that kept track of how many of these things you've done, and marked off your progress, much as LinkedIn does when you set up a profile. Each successive login would offer the user an option to finish/enhance their site setup by completing another thing(s) they haven't gotten around to yet.
Have you ever wished for a bug tracker that was built on WordPress? Every now and then when we feel pain using Trac, we look around but never see anything better. Some of the core contributors think that a very decent issue tracking system could be built on WordPress, allowing us to have complete control over the tool we use to manage the development of our, well, publishing tool. Some features would include creating tickets, assigning owners and reviewers, milestones, etc. (look at our Trac setup to see what we've got now). We'd need SVN tie in for commits as well. Depending on the scope of the project, someone else could write the SVN part if you just write the bug tracking application on WP.
Something we've never gotten around to is adding ajax paging to the list-type screens (edit.php, etc). Currently, getting to the next page of items means a screen refresh. For this project, add ajax paging to all the list-type screens in the WordPress admin. We have all the underlying PHP, but it needs some JavaScript love (jQuery, specifically). Another frequently requested feature is the ability to sort by columns on list-type screens. We don't want to make every column sortable -- columns with multiple values are better dealt with using the existing filters -- but some things would be great to have. For example, on edit.php, sorting by column might include the publish date, last modified time (would be a new column), title, number of comments, etc. How the list sorting would be affected by paging would need to be considered. See other places we could use more jQuery to enhance the user experience in the admin? We would love to hear all your suggestions and have you roll it into one big AJAX admin project.
Importing and exporting blog content is an important function within WordPress. Project idea 1: turn the import process into a core plugin, with individual installers only called upon as needed, rather than all being preloaded in core. Project idea 2: create a WordPress import/export process that doesn’t need a file, but connects directly to the blog for the content transfer instead.
WordPress generally gets good reviews for accessibility, but we can always do better. Sometimes there's a split though... providing the best possible experience on modern browsers with JavaScript enabled for the average user is not always the same as providing the best possible experience for people who need extra-large minimum font sizes, click targets, no JavaScript, etc. This project would be to create a version of the admin that is optimized for these users: large fonts, high contrast, no JavaScript, large click targets, etc. This project would be done as a plugin, but if successful, would likely be integrated into core as another admin 'theme' along with the blue and gray choices people currently have. You should have a solid foundation with section 508 requirements and coding techniques to be compliant. Design help will be available from the UI/accessibility groups as needed.
WordPress saves post revisions, but changes to theme files are not recorded, though the presentation layer is sometimes just as important. Build a versioning system for template files within the theme editor.
Improve comment moderation in the administration pages so that when threaded comments are enabled they are displayed when moderating individual posts comments. It would also be useful to allow comment re-parenting so as to fix issues where a comment reply is not associated with the correct parent. Support should also be added to the XML-RPC api to allow an external app to implement similar functionality.
In the coming year, the WordPress media handling functions are expected to be redesigned, with new features added and significant recoding of existing features, some of which will be moved into core plugins. There will be many components to the media overhaul, any of which could make a great Summer of Code project. We'll be looking to add things like slideshows, better gallery functions, creating more user settings for media files and templates, and dozens of other features that could be packaged up for SoC projects.
Currently, if you want to move your WordPress install to a new host and keep the same domain, you only need to move all the files (WordPress Core, Themes, and Plugins), and then export/import the database. It’s pretty straight forward, but still more complex than many users are capable of.
However, if you want to change the domain (even without moving to a new host) you have to export the database, do some search and replace on the .sql file, and then re-import the updated database. Even then, if the new domain has a different number of characters in it than the old one did, you can run against problems if any of the places you replaced the name happened to be inside a serialized array (almost all the options, including things like widget settings, text widget text, etc).
The goal of this project would be to make a these kinds of transitions simple and smooth. If only the domain is changing, then when the user updates the WordPress URL we would update internal links in their posts, settings, image urls, etc. If they are moving to a new host, allowing them to install WordPress at their new host and enter their credentials for their old host (WordPress admin credentials as well as FTP credentials) and WordPress would simply import everything (posts, settings, uploads, theme, plugins, etc).
The Profiles.WordPress.org site is meant to be a place where you can see at a glance a person's involvement with the WordPress project. For example, if you look at Aaron Campbell's profile, you can see that he has 18 plugins, several Trac tickets that he’s been active in over the last couple months, as well as some interactions in the support forums as well as the ideas forum.
The goal of this project would be to create a BuddyPress plugin that would enhance these profile pages and attempt to create a 'rank' based on the user’s activity, which could be used to weight their comments on the Ideas forum, trac tickets, etc. The plugin will need to specifically work on Profiles.WordPress.org but also be something that other sites or projects could benefit from.
Currently I can’t think of that many enhancements to the existing profile information, except maybe showing plugins that the user is a contributor on not just plugins they started. If you have other great ideas, we’d love to hear them.
The rank will need to be well thought out, to make sure that contributors are given better rank than people that leave useless comments on Trac, etc. We could possibly add more weight to patches than to posts, or even look for commits that gave props to the user, etc.
If you look at trac, there are literally hundreds of tickets for bugs, enhancements, feature requests and blessed tasks that never quite make it in. Not every GSoC project has to be a big single-feature goal. Helping us improve existing core WordPress code is also very valuable. For a Full-Throttle Trac Annihilation project, you'd want to identify the areas of code you're most comfortable working with, and identify a scope/minimum set of tickets that you will fix and close by the end of the project term. This could be based on a component, such as accessibility, comments, UI cleanup (Jane would love this) or upgrading, or could be a selection of specific tickets you think are important to address and would provide you with a summer challenge. The benefit of this project type is that you will have the entire development community to give you feedback as you work.
In various places in the WordPress UI, there are times when you're waiting for something to happen: a post to publish, a file to upload, a plugin to install. Each of these instances uses a different method of showing the user what's going on: a spinner, "crunching," and plain text announcements when it's done, respectively. This project would be to create a progress bar for actions that require time to elapse, and embed it into all the functions of this type.
When the new Dashboard was created in WordPress 2.7, the modules we selected were based on user feedback, but we didn't have time to do things like making QuickPress configurable, making the Comments module use "the river of comments" rather than a set number to display, etc. This project would involve 1) updating the existing modules to be more configurable and/or dynamic, and 2) create additional Dashboard modules (such as Recent Posts, etc) that we could package up into a plugin, kind of a Dashboard modules extension pack.
BuddyPress is a plugin for WordPress that turns a WordPress blog into a social network. Since BuddyPress is still relatively new, there are infinite project possibilities, and we're interested in any proposals that involve extending BuddyPress.
The WordPress theme directory does not currently accept child themes, as WordPress has no way of ensuring that people have the proper parent theme installed. This project would modify WordPress so that it could download child themes and resolve their dependency on a parent theme.
GlotPress is a web-based collaborative translation tool. It is a web alternative to poEdit and the rest desktop gettext editing tools. Code-wise GlotPress is based on BackPress and a tiny MVC layer on top of it. The project will be to add functionality to GlotPress:
You will like the project if you also like object-oriented programming and clean, self-explanatory code.
bbPPress is the forum software of the WordPress family. Led by Matt Mullenweg, the bbPress project is undergoing something of a rebirth, and now is the perfect time to get involved. Making bbPress a WordPress plugin would be a good project, or adding additional features.
Additional members from the WordPress open source community may be added as mentors based on project needs.
Additional members of the WordPress core contributor community will help guide students through interaction on the blog we will set up up for this purpose, where they will give feedback on weekly student reports and respond to student questions.
Excited by the possibilities, and want to know what you have to do to apply? Awesome!
Good luck!!!