Improvements to core

Some of you may have heard that I wanted to organize an API docs cleanup sprint... Well, here it is:

(issue) http://drupal.org/node/1310084

The idea is to have a sprint over the next couple of weeks, and get the Drupal Core API documentation to conform better to our documentation standards. All the instructions are on the issue... please feel free to post general questions here, but otherwise, discussions about specific documentation, standards, etc. are better off on the issue queue.

Let's get this done!

I know what it feels like to have your hard work critiqued, piles of issues to solve and to deal with some of the hardest discussions and posts we can have. I know the many hours spent, sacrificing time with our loved ones, time without sleep or the so many other things we give up to do our part.

I'm following this up a bit from effulgentsia's post in this group about Acquia's influence, as well as some of the burnout discussions.

I'm mainly interested in core and the largest contrib projects here. However if I missed something feel free to expand scope a bit - I might edit stuff in if I miss it.

Here is a short summary of what we discussed at the Drupalcon London.

There has been a core conversation talk by Peter Wolanin and me, of which you can find the video here and the slides here.

Roadmap

The further roadmap is to:

• define the API + do a test entity type
• port a core entity
• do performance testing
• implement revisions + port node and other entity types
• refactor field storage

Performance testing basically should be repeated after every step.

Status

• There is a first patch that moves the entity API in its own module, which we need to get in first.
  http://drupal.org/node/1018602 -> Needs review.
• There is an issue for implementing basic CRUD and porting a first entity type: comment
  http://drupal.org/node/1184944 - work in progress
• We've worked on defining the basics of the API at the Drupalcon codesprint (see below).

Back at DrupalCon Chicago, Dries outlined a strategy for Drupal 8 involving a series of "gates" that would help ensure core code quality in a number of different categories: Documentation, Performance, Accessibility, Usability, and Testing. Patches to Drupal 8 would be required to pass these in order to be accepted (as well as pass standard human reviews).

The idea behind the gates is to define essentially a set of "checkboxes" which outline the most important aspects to each category, and does so in a way that is both not overwhelming to core developers (list of hoops to jump through is kept as small/focused as possible) and also creates very little additional burden on the team in question (contains ample links to documentation/resources so developers/reviewers can help themselves).

The documentation, accessibility, performance, usability, and testing teams have been hard at work on defining their gates over the past month, with a focus on trying to identify the highest-impact items and help raise the collective IQ of the development community by educating them on how to ensure their patches pass. While these gates (apart from documentation) are NOT quite finalized yet, several teams have asked for additional community feedback. The goal is to get these finalized within the next 2 weeks in order to formally announce them at DrupalCon London, where lots of sprinting on D8 is sure to be happening.

Items that need review:

• Are the gates clear in what they're asking for?
• Is it also clear when a gate would apply to one of your patches, or to a patch you're reviewing?
• Are there ample resources to help you pass the gate?
• Any other comments?

So, without further ado, the gates!

Note: If you have bandwidth to help the teams push these through the finish line (helping to identify/write missing documentation, helping with wordsmithing on the actual gate text to make them more clear, etc.), this would be greatly appreciated. :)

As we attempt to rewrite more and more pieces of Drupal (dbtng, t(), ..) in OOP code, we also see singletons being used or suggested.
Trying to not hijack other discussions and d.o. issues, I start a new discussion about this here.

I'm giving your group this little rant because, well, I got some replies to my first post here. At least I know someone is actually reading them.

Back in D5 or D6, we introduced a rule of "string freeze", meaning we would not change/add any strings in a stable release of Drupal that was not clearly a bug fix (and a critical bug fix, at that, iirc) lest poor, hapless end users do a minor update of core and be slapped in the face with English in their French/German/Swahili site.

I wanted to open this up for discussion up again now that we're in the age of localize.drupal.org. Is this formally hard-and-fast rule something we can look at loosening a bit? It would certainly put a lot more options on the table in terms of incrementally improving D7's UX, and also in terms of backporting non-backwards-compatibility breaking features (which is on the table for the first time in D7, thanks to the testing framework).

Here are a few specific examples that have come up recently: