Today is the start of a double dose of sprint awesome at TCDrupal and Drupalaton. Here are some important sprint tasks to help get Drupal 8 done.

1. Beta blockers

   Our top goal for the sprints is to make significant progress on the three remaining beta blocker issues. These issues aren't the best place to jump in if you're not already following them, but plach, alexpott, effulgentsia, fago, and others are going to do what they can to get these issues done.

2. Beta deadline issues

   The next priority for the sprints are the beta deadline issues, which are non-critical issues that will have to be postponed to either Drupal 8.1.x or Drupal 9 if they are not done by the time the beta is ready. Many of these issues are related to the Entity Field API, so if you're interested in those systems, reach out to entity and field maintainers fago and swentel at Drupalaton to see if there's a beta deadline issue for you.

3. Twig autoescape followups and double-escaping bugs

   One of the beta-blocking issues that's already been resolved is enabling Twig's autoescape functionality, so that strings that have not already been sanitized by Drupal can be escaped automatically in the theme layer. There are a lot of important followups to this change, which can be grouped into two categories:

   • Double-escaping issues (#2297711)

     Since Drupal already does its own sanitization at many different points, there are a number of places where we are unintentionally escaping markup twice, resulting in double-escaping bugs like:<em>My double-escaped string</em>

     When code uses the appropriate sanitization functions or the theme and render systems so that the output can can be themed, escaped, and altered properly, double-escaping is not an issue. So, we need to fix these regressions, ideally by removing the markup from the code entirely and converting to a Twig template, or failing that, by using the inline templating render element. In some cases these issues might be simple to fix; in others they will require some refactoring.

   • Improper uses of SafeMarkup::set() (#2297703)

     In order to inform the theme layer about what markup Drupal has already sanitized, strings that have been processed by t(), String::checkPlain() or Xss::filter() are automatically marked safe, as are markup strings created from render arrays via drupal_render(). This list of sanitized strings is stored by the SafeMarkup class, which is intended for internal use only. However, the initial conversion patch added SafeMarkup::set() calls in many places as an interim fix. We now need to remove as many of these improper uses of SafeMarkup as possible, by converting or refactoring the code in the same way that we would to fix double-escaping bugs.

   We will be sprinting on these issues at TCDrupal. Talk to YesCT or mdrummond for help getting started.

4. Critical issue triage

   Once Drupal 8 is in beta, the next step will be to resolve the other critical issues that block a Drupal 8 release candidate. As a first step, we need to assess all of the critical issues to determine which are most important, which are no longer relevant, etc., as well as what the path to get each done is. In each critical, we should clearly identify:

   1. Why is it critical?
   2. What would be the implications of not fixing the issue?
   3. What would be the implications of fixing the issue between betas? (Code changed for modules, upgrade path, etc.)
   4. What would be the implications of fixing the issue after the first release candidate?
   5. What is the next step to make progress? What are the remaining tasks?

   Talk to xjm to help with this essential task.

If you're sprinting at TCDrupal, remember to put the TCDrupal 2014 issue tag on issues you work on at the sprint. Similarly, use the Drupalaton 2014 tag at Drupalaton. And whether you're sprinting in Minnesota, in Hungary, or remotely, join the #drupal-contribute IRC channel to coordinate with other sprinters.