Normally we don’t start talking about the next release until the current one is out the door, or at least in betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process./RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta)., so this post jumps the gun a bit, but for a good reason: the GSoC deadline. There are two approaches we could take toward our participation in GSoC this year, and one of them is tied closely to 3.5.

Historically

• Good GSoC mentoring takes time. Time is hard to come by at the best of times, even harder for many during the summer.
• Many of our previous GSoC mentors have held the position for several years and could use a break from trying to mentor while simultaneously working on features for a regular release.
• Almost none of our GSoC projects have actually made it into coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. A few because they were plugins, but most because once GSoC is over there hasn’t been a concerted effort to follow up on these projects.
• We often run late on dev cycles.

Since 3.4

• We have ramped up several core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org. to more responsible/trusted roles as a result of the 3.4 process experiment (teams, cycles, updates, etc). This could mean more mentors.
• We are running late in our dev cycle, and with SXSW about to eat a week, I’m thinking we’re about to get even more behind. My guess is we’re looking at a May launch, not April.
• The stated intention of having all feature dev for the cycle tied to a central goal of making it easier to customize your site didn’t really happen. There were at least 3 teams working on features that had nothing to do with this, and another couple that were related, but not smack in the middle of it. Good features all, but we failed in sticking to that goal as a unifying concept.

Proposal

What if for 3.5, instead of it being a “regular” cycle, we made it a mentoring cycle tied to the GSoC schedule (shorter than normal)? If we assume 3.4 will launch sometime at the end of April or early May (and if it does happen earlier, awesome), that would � put us in a position to start working on 3.5 right when the GSoC accepted students are announced.

If we chose a “release concept” (like customizing your theme, but something different) and outlined every feature/enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature./bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. that’s related, we could make those things be the potential GSoC projects. We could work in teams like in 3.4, but in this case each team would have a student or two working on things with them closely. Since these would be the only features being worked on (additional bug-fixing always ongoing, obviously),

• Students would be guaranteed mentor attention and working with core
• We would be more likely to do the work necessary to get student work to commit-worthy status
• We would target a launch for late August to coincide with the end of GSoC (so we could do one more small release before end of year)
• We could do additional outreach to include new contributors who do not qualify for GSoC (too young, too old, not in college, etc), improve our mentoring skills and processes
• At the end of this mentorship-focused summer, we would not only have the features developed by mentees, but we would have an ideal pool of people to help us create documentation to help new contributors.

I’m thinking that what might make sense would be for there to be a team or two that doesn’t mentor or work on a feature for 3.5, but begins working on one of the more complex things we keep putting off, so that it could be the first thing into 3.6 (like gallery management or something similar).

Deciding on a release concept that could be done in a 2.5-3 month cycle would be important. I’m thinking maybe it could be the feedback loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. — improving comments and communication with readers via htmlHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. emails, forms, etc on the front end and a UIUI User interface facelift of the comments/related screens on the back end, putting something cool into Twenty Twelve around this (or just support for something in core related to same), etc. There are a number of projects around this that have been done in the past that could be looked to for inspiration and/or what not to do, it’s needed attention for some time, and it’s not as complicated as something like media or multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site.

Thoughts? Specifically, thoughts on:

• Doing a mentorship-focused release timed to GSoC
• Potential areas of focus for 3.5 if we were to do this
• Mentoring in teams like 3.4
• Wanting to mentor in this case
• How many students you think we could take on if we used teams like in 3.4

Comment here today, and tomorrow I’l round up the core team to see what people think based on the conversation so we can make a decision and I can update our application before the application deadline if needed. If we don’t do something like this, then I’m planning on reducing our GSoC student allotment to 5-6 students (we’ve asked for up to 15 in the past) to ensure enough mentors and adequate attention/follow-up on projects.

Thanks for your input!

#3-4, #3-5, #gsoc, #mentorship