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.