Drupal 7 development process retrospective summary

I spent a couple of hours recently summarizing all of the comments on my Drupal 7 development process retrospective post. Thanks for all the feedback;

it was very useful. I organized the responses into two groups related to the Drupal 7 development cycle: improvements we made during development that people think we should keep, and problems observed during development that people think we should address.

I have been thinking about a number of solutions, or experiments, that I would like to try during the Drupal 8 development cycle. However, I’m not ready yet to talk about them publicly. I’m still in listening mode, and will soon begin discussing my thoughts in #drupal on IRC, in the issue queues, and in the comments of related blog posts. I'd like to make a first set of decisions by DrupalCon Chicago.

In the mean time, below is my summary of the most notable items.

Improvements made in the Drupal 7 development cycle (compared to Drupal 6 development cycle)

  • The long release cycle was beneficial for many customers;
  • Providing regular development snapshots helped in organizing the work;
  • Continuously innovating and adding cutting edge technology is something we need to continue to do;
  • It was very effective having a core committer available in IRC for discussions frequently and in real-time;
  • Automated testing integrated in the drupal.org issue queues workflow was a huge win;
  • We appreciated the availability of a usability team to provide support;
  • We also appreciated the availability of an accessibility team to provide support;
  • The semi-official and unplanned API clean-up phase during code freeze will make development saner;
  • We liked the introduction of the ‘major’ priority as people were abusing the ‘critical’ priority;
  • The D7CX initiative to get contributed modules upgraded (although it didn’t necessarily meet expectations) was good;
  • Having issue summaries for long issues helped to focus our plans and goals;
  • The visibility of domain experts was evident by reworking and updating MAINTAINERS.txt;
  • The exceptions during the code freeze provided focus;
  • The fact that we added tests for the upgrade path prevented regressions and helped to get the release out;
  • Issue tags provided a major workflow improvement;
  • The fact that some larger initiatives where successfully organized outside of the issue queue was a plus;
  • Starting to update developer and API documentation along with code changes kept our activities in order and helped everyone to understand what had been accomplished along the way;
  • It’s a good idea that we plan to try to backport some changes from Drupal 8 to Drupal 7; and
  • The fact that we are doing an official post-mortem makes this all even better. :)

Problems and difficulties observed during the Drupal 7 development cycle

  • We should provide more attention to contributed module upgrades;
  • It would be useful to make the release cycle shorter for developers and customers;
  • The uncertain length of the release cycle makes it difficult to plan;
  • Breaking backwards compatibility becomes increasingly costly;
  • Lack of head-to-head upgrade path badly delayed the code freeze;
  • It would be good to better enforce the code freeze; especially for the string and UI freeze;
  • The original freeze deadlines may have been unrealistic (i.e., too bunched together, not enough time to actually polish the UI, and then respond to it by changing help text strings);
  • Not all documentation (and almost no end-user documentation) was updated as part of the developer workflow;
  • “Commit + Needs work” pattern for tests and documentation led to an unresolved backlog;
  • There were unclear responsibilities and authority for sub-system maintainers;
  • We need better priorities and maybe even a road map;
  • There was too much emphasis on MAINTAINERS.txt;
  • There needs to be more usability testing and usability data.
  • The critical issue count was allowed to become too large, leading to a delayed releases;
  • There is too much variability in reviewing and committing patches; some patches were committed within hours (not giving enough time for others to review), while others waited for weeks or months; and
  • Performance is often an after-thought which led to performance regressions.

If there are points missing, or if some of them could be summarized better, please let me know and I’ll update this post. I think I have a good sense of the primary problems experienced. However, if many of you think it would be useful, I could also conduct a quick survey to help prioritize these points.

Comments

Dries:

It's feedback that I collected from other people, so it isn't my own. However, that person wrote that there is a danger to adding too much structure to MAINTAINERS.txt roles and responsibilities; people come and go, some maintainers contribute a lot while other maintainers don't. Having a MAINTAINERS.txt could stop new people from contributing as they might believe that no help is needed.

sun (not verified):

We discussed and tried to address that (hypothetical, not verified) issue by at least adding a clear and concise intro text to MAINTAINERS.txt:

Drupal core is maintained by the community. To participate, go to https://drupal.org/contribute
The people listed here have agreed to do more quality assurance work for particular areas of Drupal. All of them are subject to change.

I think this particular concern that was raised against the perception of MAINTAINERS.txt is different and needs to be separated from the other and often repeated demand to increase responsibility, delegation, and trust for subsystem/component maintainers.

dalin (not verified):

It seems like the testframework is the only big item in the D7 improvements list. To attack the difficulties list it seems like we'll need a lot more big changes for the D8 cycle.

EE (not verified):

Hoping it has a new upgrade strategy for jQuery.