Last call for GSoC mentors! Making the IRC schedule now for GSoC mentor chats/q&a, and want to be sure I have everyone. Here’s who is listed on the Codex (per @nacin): Aaron Campbell, Jorbin, Viper007Bond, Nacin, Skeltoac, Filosofo, Chris Jean, Scribu, Dan Roundhill, Koop, Ocean90, Eric Mann, Mitcho, Jtrip, Duck_, Justin, Nikolay, Pete Mall, Westi, and Thorsten. I know we are missing a couple of people who offered to mentor and/or backup mentor. Note: being on this list does not mean you will definitely wind up mentoring a student. It will depend on how many slots we get, what kind of projects there are, and your own interest. If there’s not a student/project you want to work with, you are not required to choose one. I just want to get anyone who’s a potential mentor in the pool now so they can review applications and participate in the chats. If you’re one of the missed people, please leave a comment on this post so we can add you. @otto42? Boone, still interested?

Also: I’ll be getting some help moving forward with the admin side of GSoC from Andrea Middleton. You may see her posting here about GSoC on occasion.

Dev chat summary 3/30/2011

3.2 check in:

• Westi working on http://core.trac.wordpress.org/ticket/16827
• Rboren pushed 3.1.1 this week, shifting to 3.2 now
• Azaozz working on full-screen editing for Visual mode. Mini version of TinyMCE has no buttons or toolbars, but keyboard shortcuts work. Possible hidden/floating toolbar up top for some buttons. Will put out as plugin soon to begin testing/refining.
• Pete Mall tending to multisite tickets that got pushed to 3.2.
• Sivel and dd32 working on HTTP API. Got http://core.trac.wordpress.org/ticket/16236 in, have another dozen or so tickets active, anticipates “fairly large reworkings of the HTTP API in 3.2, mainly because we have been finding a lot of bugs and limitations”
• duck_ pushed WordPress importer 0.4 yesterday, will be moving to 3.2 stuff soon (has a kses performance patch in the pipeline)
• No one else had anything to report on 3.2 progress

Quick and dirty flyer for GSoC. Print and post anywhere you think smart college student developers will see it in your city. Got a late start on recruiting students, so if everyone can help publicize, that would be great. Post to your PHP mailing lists, meetup groups, etc. Thanks!

Deadline for Open Source Bridge proposals is tomorrow. I went last year and there was no WordPress on the schedule, though a ton of attendees were WordPress users. It’s in Portland in June, Viper007Bond is in town, and you could visit locations from Portlandia to boot. Maybe a few people here will decide to submit proposals to OS Bridge? If there’s a contingent attending, we could maybe plan a little WordPress drinks thing or something.

GSoC Students: No one is going to steal your idea!

There have been a number of potential GSoC students asking potential WordPress mentors to look over their applications privately before they are submitted, as the students are afraid someone will steal their idea.

1. This is not the way to approach applying; please use the requested forms of contact at this time — wp-hackers for feedback on your general idea and/or popping into #wordpress-gsoc on irc.freenode.net to talk to a live person. We are in the process of scheduling a handful of IRC chats for later this week and next with specific mentors, where students will be able to ask more questions directly. In the meantime, please stick to the above methods of contact rather than bombarding individual mentors with email.
2. This is open source. There’s no such thing as idea theft — the whole point is to continually build on and improve each others’ ideas. Put your ideas out there. The application template asks you to link to where you’ve posted your idea on your blog and/or in a wp-hackers thread, so you pretty much HAVE to put it out there to be considered by us, and if you think someone stole your idea, you can clearly point to where you posted it first. However, this has NEVER been an issue before, and I’m not sure why it’s suddenly such a concern this year. If you don’t like the idea of discussing ideas in the open, then why apply to work with open source? We like to see applications where students have gotten lots of feedback on their idea, and if relevant, have incorporated suggestions into the final proposal, as we don’t develop in a vacuum.

But! Students!

Have you looked at our application template yet? We care about the idea, yes, but even more we care about proof that you know what you’re doing with WordPress, specifically via submitting a core patch or two, which is listed in the application template with sample tickets. Patches are basically being used as litmus tests to judge your skill and style, as applications can be written to sound great by people who can’t deliver. If you submit an application without ever having attempted any of the requested patches, your application will automatically be ranked lower than applications from students who did submit patches.

So, here is the absolute best advice for getting accepted with WordPress for GSoC this year:

1. Know PHP and the WordPress codebase.
2. Attempt the test patches referenced in the application template, post patches to the trac ticket(s).
3. Post your idea on a WordPress-powered blog, and link to the proposal in a post to the wp-hackers mailing list, asking for feedback.
4. Follow things happening on trac and in #wordpress-dev to better understand what’s happening with current WordPress development.
5. Ask questions in #wordpress-gsoc; watch for the posted public chat times coming up this week and attend when a mentor you’re interested in working with is scheduled to be there.
6. Revise your plan as needed, fill in application before the deadline gets too close.
7. Keep track of your application page, as mentors may ask you follow-up questions or request more information that we need to have before we are willing to consider your application. Respons to questions promptly.
8. Make sure all information is complete before the deadline.
9. If you have been talking with any particular mentor(s) in IRC, let them know when your application has been submitted.

Note: When writing your proposal, please be aware that we like to have the project functional by midterm, with the second half of gsoc spent polishing, testing, integrating (moving from plugin to core patch, etc), and revising. Please plan accordingly.

Good luck!

GSoC Mentors: sorry for the delay. The new melange UI is freaking me out and I can’t find anything. It went from about 50 navigation links to 5, and I’ll be spending the morning trying to figure out where the heck things moved. In the meantime, let’s set up some open IRC chats like last year where students can ask questions etc. Can all mentors post with some days/times this week that work for them (or if you’re mostly open, post any days/times when you are not available)? Thanks.

The student application period opens on Monday. For the record, here is the GSoC timeline between now and the end of the program:

March 28, 19:00 UTC
Student application period opens.

April 8, 19:00 UTC
Student application deadline.

Interim Period:
Mentoring organizations review and rank student proposals; where necessary, mentoring organizations may request further proposal detail from the student applicant.

April 22
All mentors must be signed up and all student proposals matched with a mentor – 07:00 UTC

Student ranking/scoring deadline. Please do not add private comments with a nonzero score or mark students as ineligible (unless doing so as part of resolving duplicate accepted students) after this deadline – 17:00 UTC

IRC meeting to resolve any outstanding duplicate accepted students – 19:00 UTC #gsoc

April 25, 19:00 UTC
Accepted student proposals announced on the Google Summer of Code 2011 site.

Community Bonding Period:
Students get to know mentors, read documentation, get up to speed to begin working on their projects. Generally, this is when any questions over code approach are decided, and general architecture is figured out, so that when the coding period opens, you’re ready to go. Student should already be familiar with the WordPress codebase, and should not plan to use this period to learn it.

May 23:
Students officially begin coding for their GSoC projects. In reality, most of students begin coding during the community bonding period.

July 11, 19:00 UTC
Mentors and students can begin submitting mid-term evaluations.

July 15, 19:00 UTC
Mid-term evaluations deadline;

August 15:
Suggested ‘pencils down’ date. Take a week to scrub code, write tests, improve documentation, etc.

August 22:

19:00 UTC

Firm ‘pencils down’ date. Mentors, students and organization administrators can begin submitting final evaluations to Google.

August 26, 19:00 UTC
Final evaluation deadline

Will be contacting the confirmed mentors tomorrow to set up irc chats, walk through guidelines, etc. If you don’t hear from me tomorrow, but thought you were going to be a mentor, ping me over the weekend or on Monday.

Code refactoring should not be done just because we can. There are a number of “refactoring” tickets that seem to be missing the mark. Meanwhile, plenty of tasks are far more worthy of effort. Here are some suggested guidelines on what these tickets need in order to get any review:

• Unit tests, even if the code was not previously covered. We can’t afford regressions, and this will improve our test coverage.
• Performance benchmarks, before and after. We can’t afford regressions.
• Proper justification and clear rationale of changes are both necessary. Too often it is impossible to determine the purpose, objective, or focus of these patches. Code should not be rewritten under the cloaks of readability, narrow personal opinion, or general subjectiveness.

When none of this is followed, the end result is that reviewers and committers are distracted, which drains important attention and focus that should be spent elsewhere.

There’s a document on contributing to the Linux kernel with a section on pitfalls when handling coding standards. I believe this can apply to the wider picture of refactoring as well (emphasis mine):

The kernel has long had a standard coding style, described in Documentation/CodingStyle. For much of that time, the policies described in that file were taken as being, at most, advisory. As a result, there is a substantial amount of code in the kernel which does not meet the coding style guidelines. The presence of that code leads to two independent hazards for kernel developers.

The first of these is to believe that the kernel coding standards do not matter and are not enforced. … The other trap is to assume that code which is already in the kernel is urgently in need of coding style fixes.

I’m going to start linking to this post in various tickets.

Bug gardeners, there is now a 3.2 milestone in core.trac. Tickets assigned to this milestone should relate to the 3.2 plan. There are currently 312 tickets marked as 3.2 early. Only a fraction of these should end up on the 3.2 milestone.

Re GSoC mentors:

We have temporarily disabled the creation of new requests and invites
in preparation of the launch of the new UI for Melange later this
week. This means that no new mentors can be invited until then. The
new UI will be deployed before the student application period starts
though, so hopefully this will not be too much of a problem.

Since we all had so many issues with melange in the past, hopefully this will be good news! In light of this, I won’t bother with the adding-mentors process until the site is back up, so don’t freak out about not being invited to be a mentor through google yet. In meantime, just engage with potential students on hackers list and #wordpress-gsoc.