Big news! The annual Google Code-In contest kicked off Monday, November 18th. The contest's purpose for pre-university students (ages 13 - 17) is learning how to contribute to open-source software projects and offers them a chance to win a once in a life time grand prize of an all expense paid trip to Google HQ in California. The bigger news...Drupal was chosen as one of the ten participating organizations to create tasks for the students to complete during the 2013 contest! This is a huge honor for Drupal and gives us an amazing opportunity to grow our community.

1. Find a relevant-looking project on github. If the name includes Symfony, all the better. It doesn't need to be the main Symfony project. The characters S-y-m-f-o-n-y causes everyone responsible for core to lose all sanity.
2. Shovel your code into the project.
3. Submit for core inclusion. Do not forget the "Proudly found elsewhere" and the "Symfony" tags.

Especially with Drupal 8 requiring PHP 5.4, closures (my brief intro) are going to much be much more useful and widespread. I would like to point out one advantage which already exists: array_walk($a, function (&$value, $key) {// some code here}) do not have any lingering after affects because both $value and $key are only visible in the scope of the closure. But foreach ($a as $key => &$value) { // same code here } leaves $value a reference to the last item and it's guaranteed to give you some nasty, nasty surprises down the line. More, the behavior of foreach itself might change compared to the non reference using foreach ($a as $key => $value), read how foreach actually works for much more (and a bonus headache).

berdir unified the DatabaseStorageController and the DatabaseStorageController classes. I have been working on migrate, this reports is at https://groups.drupal.org/node/357993

WHAT: Import API in Drupal 8, based on the Migrate project. Drupal 6 and 7 import using this API based on the Drupal-to-Drupal data migration project. Read and comment on Mike Ryan's thoughts at http://goo.gl/WnTOB0.
WHERE: The first big sprint is planned at BADcamp. PNWDS will likely host some informal discussions, perhaps a BoF. There is a sandbox (only some experiments right now) and a discussion group.
WHEN: PNWDS is Oct 5-6 and BADcamp is October 24-27.
WHO: Mike Ryan, chx, Melissa Anderson and YOU. Get in contact with chx if you want to help. Please add yourself to the sprint attendance spreadsheet if you are coming to the sprint at BADcamp.
WHY: So that Drupal 6 sites can move directly to Drupal 8. (And because the current upgrade path is unmaintainable.)
HOW: The battle plan is that once the interfaces are in place and agreed upon, the sources and the destinations can be written in parallel. By BADcamp, hopefully we will have a tasklist up and Melissa will coordinate the tasks and the contributors.

I have been frustrated with Drupal 8 before (and I am often still is). I wanted to fork Drupal. Let me start with a few insurmountable problems, regardless of the specifics of the fork:

"80% of people use only 20% of the features" -- but they often use a different 20%. And Drupal contrib covers them all. One of the strengths of Drupal is every problem having a contrib module to answer it, big or small. It's near hopeless reaching this diversity in a fork.

Second, two words: Security team.

Drupal 8 is daunting. I am sure everyone trying to port a module will have a lot of questions. Put them on Drupal Answers and tag them simply 8. There are many people on this site who already helps and I have the RSS feed for this in my RSS Live Links so I will see them and I pledge to spend up to an hour daily answering them. And if I don't know an answer? Well, that's an opportunity to learn something about Drupal 8 and I like learning about Drupal and sharing it. Let's learn Drupal 8 together, shall we?

Somewhat augmenting Dries' Why the big architectural changes in Drupal 8 most excellent blog post, let me explain two architecture decisions: annotations and YAML. Both were chosen as the least bad. The decisions are obviously debatable and believe me they were (and still are) but I think it'd be helpful to give some background on the decisions. Also note there might be arguments I have forgotten.

preg_filter() is identical to preg_replace() except it only returns the (possibly transformed) subjects where there was a match. This is most useful with an array as the subject: previously you'd need to use preg_grep and preg_replace with the same regular expression to achieve this. It's obviously much faster to do a single command. Very handy!

The biggest news (literally) is the entity storage patch finally nearing completion -- after yched and me have worked on this a lot, now is carrying the half megabyte monster home. The reason for this size is fields no longer will be shareable between entity types (but they still be shareable between bundles). Meanwhile, berdir is finishing the Entity NG conversion (go berdir!) and moves baseFieldDefinitions from storage to entity classes. The smaller the storage classes the better for us, quite obviously.