GSoC 2013
It’s time for us to apply for GSoC 2013 if we want to participate. I can take care of the application, but will need everyone’s help in producing the project ideas and mentor sections.
“Why didn’t we get accepted last year?”
We didn’t get accepted last year because our Ideas page wasn’t as good as it had been in past years, and they wanted to make room for some new orgs, so we got cut. Our ideas page wasn’t great because we were planning to embed students in regular cycle feature teams, but we didn’t write up all the potential features this might have included. This year we need to write out all the possible features.
PROJECT IDEAS:
The more project ideas the better, so things that aren’t targeted for the next cycle but that we might want to do as a plugin to get some traction for inclusion in a later release would be great projects, too. Project ideas can include core features, plugins, themes, unit tests, etc. This includes work on .org site things like the plugin used to power WordCamp sites. The projects must be code, though, not design, documentation, etc. List your project ideas in a comment on this post. Please give it a title, and a short one-paragraph description. If there’s a ticket or relevant thread somewhere, link to it.
POTENTIAL MENTORS:
Want to volunteer to be a mentor? You need to be good enough with wp coding that you currently don’t need oversight to generally get it right (though obviously we all can get better with more eyes on code), and have enough time to be available to your student for feedback and code review (at least once per week, though more often is better). The time commitment can be anywhere from one hour to ten hours per week, depending on how far along your student’s project is, and what there is for you to review (an hour or two a week is typical). You get a GSoC tshirt at the end. Want to be a mentor? Leave a comment on this post with a short/one-paragraph little bio about yourself, what kinds of projects you are interested in/qualified to mentor, and links to your website, wordpress.org profile, and twitter account.
LEAD DEVELOPERS:
I know you are right smack dab in trying to get this release out, which is why I’ll take care of the application and associated materials. That said, I’m a bit out of the loop with core plans, so coming up with the potential projects list on my own would mean they might not mesh with the actual goals/plans of core team very well. I’ll be looking to you guys to give me a sense of priority/possible plans for the next dev cycle, and to tell me who is qualified to mentor a project from the final list of volunteers. Will ping you offline for this.
Not sure how to write up a project idea or your short mentor bio? Take a look at the ideas page from 2011 for a guide.
Note 1: This year BuddyPress will be applying as a standalone organization with WP as the vouching organization. I’ll be helping Paul Gibbs get their application going.
Note 2: I haven’t announced it yet since it just happened, but we’ve been accepted as a mentoring organization for the Gnome Outreach Program for Women for the summer session. Unlike GSoC, where Google foots the bill, we’ll have to raise the money to cover our interns for the Gnome program, so I’ll announce it along with a fundraising drive. The Gnome program is a little broader than GSoC, and does allow non-code projects, so things like design, ux, documentation, translation, community management, etc would all be possibilities there.
trishasalas 6:16 pm on March 19, 2013 Permalink
Jen, I appreciate all the work you (and others) are putting into this. I’m fairly certain I wouldn’t qualify as a mentor (at least this year) as my WordPress coding knowledge is just now starting to solidify. However, I would like to know what I can do to prepare for future involvement (if anything). I would also be interested in learning more about the Gnome Outreach Program.
Eric Mann 6:23 pm on March 19, 2013 Permalink
I have a few ideas …
Idea 1: Dashboard Widget API
We have a great widget API for sidebar widgets, but the admin dashboard widget API is far less reusable. Certain widgets rely on the same code (i.e. feed widgets) without a clean abstraction layer to prevent changes to one from breaking another. This is one of the biggest reasons #19239 hasn’t gone anywhere yet. Merging the widgets required some hackery and the new widget in that proposed patch isn’t abstracted enough to be reusable anyway.
The idea would be to create a basic object template for dashboard widgets that can be extended in the same way WP_Widget can be, then to revise existing dashboard widgets to use the new API.
Idea 2: Post by Email Plugin
Deprecating the post by email functionality has been on a list of proposals for quite a while, and despite a patch (#22942) that disables the feature (similar to how Links were recently disabled), momentum has stalled since no clear alternative exists.
The idea would be to create a new plugin that extends post-by-email functionality in a clean manner. Host the plugin in the .org repo. Then update the existing patch on the above ticket for 3.7.
Idea 3: UUID Abstraction
One of the most talked-about “vulnerabilities” in WordPress is the ability to slurp down user IDs and login names programatically since user IDs are auto-incrementing integers. This could be prevented by changing the data structure to use UUIDs instead.
Also, updating post data structures such that new posts populate the GUID field with a true UUID (rather than the current post permalink) would prevent a lot of developer confusion as to what the field is and how it’s used. (Regular post IDs should remain integers since they’re used in the default link structure.)
Other objects in the database can be rekeyed as UUIDs as well, but my proposal is to start with user IDs and post GUIDs since changes there would solve specific problems that exist today.
Eric Mann 6:33 pm on March 19, 2013 Permalink
Just to clarify, I’m willing and capable of mentoring any of these projects. I’ve worked with data abstraction in the past, and I wrote the first patch approaches for the two linked tickets above. For anyone unfamiliar with me … I’m @ericmann on Twitter, WordPress.org, and just about everywhere else. I also speak at WordCamps, moderate the WP Stack Exchange, and geek out on WordPress projects for a living.
jltallon 1:21 pm on March 20, 2013 Permalink
Idea N+1: Plugin/Theme dependencies in core
Work can begin from Scribu’s plugin +improvements ( Debian-style version comparisons: >=, >>, <=, <<, =), there is a proposed patch out there.
Second step: Theme *code* dependencies: just like parent-child relationships are declared within the style.css (child themes), themes that need certain plugins to work properly (not enhacements, but hard dependencies) can declare so in a comment at the beginning of functions.php
RATIONALE: just like plugins can declare "Depends" and "Provides" within their meta information in the plugin's header comment, themes can depend on certain functionality from plugins.
BENEFIT: ability to "mix and match" code and allow for more modular code. Individual, granular updates to functionality via plugins, where all other components benefit from the upgrade without intervention.
BASIC FUNCTIONALITY:
(thisi is basically the functionality present in Scribu’s plugin right now)
I’m proposing this for a GSoC project since I guess it would need quite some more work over what we currently have, and It would need a close eye before it can go in core (where it belongs, IMHO)
petarpetrovic 9:22 pm on March 20, 2013 Permalink
IDEA: REWRITE WORDPRESS’ CODEBASE TO BE FULLY OBJECT-ORIENTED
I have been using WordPress for a long time, but, sadly, I’ve never contributed any code to it. The main reason for that is that WordPress’ codebase is not fully object – oriented. I know that someone will say “don’t fix what isn’t broken”, but I really think that rewriting the codebase would be extremely beneficial for everyone. It would make a much cleaner API for plugin developers and it would be easier to maintain the codebase. I’d like to work on this through my GSoC participation. For the beginning, we would have two API interfaces – the current one which will become deprecated after the rewrite has been done, and a new one which will allow all plugin developers to gradually switch to new API as the time progresses. Then, say, in WordPress 4 the deprecated API would disappear (or we can provide some sort of plugin for the deprecated API) and a new, OOP – way API will be in place. I know, rewriting the whole codebase can break many things, but no one said that the transition won’t hurt.
Jen Mylo 4:51 pm on March 21, 2013 Permalink
Rewriting the entire WordPress codebase is completely outside the scope of a GSoC project, which should be discrete, easily tested, reviewed, and launched.
Justin Shreve 1:17 pm on March 21, 2013 Permalink
I’m interested in mentoring this year!
For those of you who don’t know I’m Justin Shreve. I’m a former GSoC student (2009, 2010) and co-mentored Summer 2011(with Aaron as lead mentor) the HTML Emails project. I also work on social projects over @ Automattic.com
I’d be interested in mentoring any general projects but specifically: API projects (XML-RPC, REST/JSON API in Core, etc), Projects around things like Post Formats, Multi-site improvements, and any social projects (if there happens to be any plugin proposals, etc).
Website: http://justin.gs/
.org profile: http://profiles.wordpress.org/jshreve/
twitter: https://twitter.com/justinshreve/
Marko Heijnen 2:41 pm on March 21, 2013 Permalink
I would love to be a mentor on one of the projects. I’m can work on Media (no backbone yet), mobile projects and on the API. Maybe a RESTfull API. But any other related project is fine.
I’m @markoheijnen on Twitter, WordPress.org, and just about everywhere else. My site is http://www.markoheijnen.com and I speak at WordCamps and WordPress meetups.
Jen Mylo 6:03 pm on March 21, 2013 Permalink
Can you write up a couple of specific project ideas with short descriptions, as shown on the codex page from 2011? That would be a big help.
Prasath Nadarajah 3:52 am on March 22, 2013 Permalink
I am interested in mentoring this year!
My name is Prasath Nadarajah and i did GSoC with WordPress back in 2011 working on the new XMLRPC API. I work at Automattic as a code wrangler.