It's great when we get newly injected energy into usability efforts in Drupal, as happened with the Drupal Usability Study at Google last week. However, these patches always run aground of various "freezes" we put in place in the stable release of Drupal:
- API freeze
- Don't commit patches that break backwards API compatibility within a stable release, for the benefit of contributed module and theme authors.
- String freeze
- Don't change any user-facing text (e.g. anything in a t() function), for the benefit of translation teams.
- UI freeze
- Don't commit patches that affect the user interface, for the benefit of the documentation team, as well as to not invalidate tutorials, screencasts, books, etc.
- Feature freeze
- Don't commit patches that add new features; stick only to bug fixes. Additional functionality gets added in contrib.
As far as I can tell, these guidelines are not actually written down anywhere, but simply passed down word-of-mouth from core generation to core generation. I want to do two things in this thread:
1) Create documentation around these guidelines.
2) Propose that we change these guidelines to make them looser and allow more classes of patches to be backported, particularly minor UI tweaks and string improvements.
Here's a proposal (co-developed by Dries, Moshe, Alex, and I), with the items in bold being ones that we propose to change, the rest being documented to the best of my current understanding. My hope is that this can both help is iterate faster on the core product, and also provide additional incentive for people helping with Drupal 8 core development, as there'd be a chance of them seeing their changes in a version of Drupal sooner than 18+ months away.
|Type of change||Description||Proposed guidelines|
|Data change||Anything that would break the "we break your code, not your data" rule. TODO: Can't think of a good example, but basically something that would require manual data migration somehow.||Critical issue only|
|API change||Changing return values of a function/hook, adding new required parameter to function/hook. Would force contributed modules to change because something in core changed.||Critical issue only|
|API addition||Optional parameters on a function/hook, new hooks/helper functions. Would provide new capabilities which contributed modules could choose to rely on.||Release notes mention|
|Data structure change||Moving page elements to different fieldsets/containers, adding additional form elements, etc. Affects modules that do heavy altering of forms/pages.|
|Markup change||Changing output of theme functions, template files to remove wrapper markup, add . Requires changes to themes in order to stay in sync with core.||Critical issue only|
|Markup addition||Additional classes or attributes exposed to template files. TODO: Other examples? Themes could make use of them if desired, but would not be required to.||Release notes mention|
|String change (admin-facing)||Any changes or additions to any admin-facing string (string wrapped in t() or st()). Forces translators to translate new/changed strings, and multilingual sites see English strings until this is done.||Release notes mention|
|String change (user-facing)||Any changes or additions to any user-facing string (string wrapped in t() or st()); for example comments or the log in form. Forces translators to translate new/changed strings, and multilingual sites see English strings until this is done.||Major/Critical string problem only. (e.g. typo, string is saying completely wrong information)|
|String change (error message)||Any changes or additions to any error messages (string wrapped in t() or st()); for example form validation errors or error messages coming from exceptions. Forces translators to translate new/changed strings, and multilingual sites see English strings until this is done.||Major/Critical string problem only. (e.g. typo, string is saying completely wrong information)|
|UI change||Any changes or additions to the user interface, such as new administrative pages, re-ordering of fields, etc.||Release notes mention, as long as the "conceptual" things for users to know remain the to grapple with, and the change is not systemic (e.g. switching the order of all form buttons).|
|Feature addition||Any changes or additions to the user interface, such as new administrative pages, additional options on an administrative page, new permissions, etc.||Release notes mention, as long as they are "opt-in." For example, a new checkbox that could optionally be checked, a new theme or module which could be enabled or not.|
Whew! I think that's everything. What do you think?