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. The purpose of 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 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).
Since we have already traditionally had requirements around documentation, it made sense to start there. Jennifer Hodgdon and some other folks from the documentation team have put together the Documentation gate, which is available at http://drupal.org/node/1203498. What we need is a similar table for each of the other gate areas. If you'd like to help with this, please see one or more of the following posts:
Informal gates:
Thanks! :D
Comments
Internationalization gate
As someone may remember, during the "Drupal 8: how do we do it?" core conversation I asked Dries if he would consider an Internationalization gate. His answer seemed to be positive so I am iterating this request again.
As the other ones announced above, i18n is a trasversal matter that may span accross serveral core subsystems and functionalities. In the core versions before 8 we were not able to design and implement a system allowing developers to address i18n needs with little effort and in a unique, consistent, way. I believe the multilingual initiative has in this one of its main goals, thus we need to ensure that its work is not somehow blocked or made harder by the other initiatives.
If the MI succeeds, it should not be a great burden for the other teams to satisfy the i18n gate. Anyway some (or all) of the other initiatives might get in before the MI does, since we have many issues that somehow deal with (or depend on) configuration and context, just to make an example. Hence we must ensure that at very least the current standing best practices are respected, so that in our subsequent work we won't have to face new unpredicted challenges. IMO this would be needed even if a MI wasn't in place, the case of field label passed through t() is just an example of this: that code should never had been in core, many people had troubles when we fixed it in D7.2.
To sum up, I'm not saying that every initiative should ship we built-in i18n functionalities, but it should do its best not to add new challeges to the many ones we will already have to face. Ideally it should take i18n into account since the earliest design. I'm pretty sure we can come up with actionable guidelines, as planned for the other gates, that will make everyone's life easier.
GREAT idea!
I don't have authority to make i18n an "official" gate (I will definitely bring it up with Dries, though), but there's absolutely no harm in creating a similar checklist table thingy for i18n in the meantime. i18n is a perfect example of an area that only a few people understand well, and those folks spend a lot of time doing post-commit clean-up due to general ignorance about best practices.
I made a post over at http://groups.drupal.org/node/158924 and updated the thread.
Question
I've got a question. How does mobile or 'non PC devices' fit into the scope of this? A lot of the work we are looking at for D8MUX is fixing issues caused by changes that went into D7. The Seven theme, toolbar, and overlay.
If we could get some consideration for other devices in core we could start looking ahead at enhancing the experience for device instead of patching previous work.
Probably accessibility the best place for now
I'd recommend brainstorming a bit at http://groups.drupal.org/node/158759 with the accessibility team. It's possible the goals are too divergent for that to make sense, but there might be some overlap, so it's a good place to start.
It'd be nice to get your concerns covered under one of the existing gates, because we need to be careful not to add too many gates. Contributing to core already got more difficult in D7 with the automated testing requirement and more stringent documentation requirements. Now we're looking to add ~25 additional hoops for contributors to jump through (though granted, some were already there). If that barrier gets too high, people will flee to contrib (or other projects entirely).
Architecture
While I agree that the number of gates should be restricted, I suggest an "Architecture" gate. This would focus on issues such as the file hierarchy within a Drupal site; classes, objects and OOP in general; hooks; data access; AJAX; and the interaction between site components such as blocks, menus, content types, modules, themes, etc., etc. I have seen elsewhere that D8 has an effort to make website components work together more seamlessly, so perhaps such a "gate" already exists, although it may not be thought of as such. Or possibly I don't fully grasp the concept of a gate.
Thanks,
Shaun
That sounds like an
That sounds like an initiative on its own; not a gate. Gates are designed to provide a "checklist" of things that are done to patches before they're marked RTBC. What you describe sounds like a series of clean-up patches to make Drupal more framework-y.