Skip to main content

Views Data Export: Sprint 1 Summary

Views Data Export
An article from ComputerMinds - Building with Drupal in the UK since 2005
20th Dec 2024

Steven Jones

Senior Developer
Steven Jones
Hey, you seem to look at this article a lot! Why not Bookmark this article so you can find it easily in the future?

As explained in the previous article in the series I've started working on maintaining Views Data Export again.

I've decided to document my work in 2 week 'sprints'. And so this article is about what I did in Sprint 1.

Sprint progress

At the start of the sprint there in the Drupal.org issue queue there were:

  • 204 open bugs
  • 276 other open issues.

So that's a total of 480 open issues.

By the end it looked like this:

  • 91 open bugs
  • 17 fixed issues.
  • 81 other open issues

So that's a total of 189 open issues, a 60% reduction from before!

Key goals

In this sprint I wanted to:

  • Tame the issue queues on Drupal.org and get a handle on what the common frustrations and missing features were.
  • Read and understand all of the code in the Drupal 8.x-1.x branch.

 

Taming the issue queue

As mentioned in a previous article I decided to close down pretty much all the tickets for the Drupal 7 version of the module. This is the codebase that I'm most familiar with, but it's causing a lot of noise in the issue queue, so getting rid of that is a great first step, and pretty easy.

https://www.drupal.org/project/views_data_export/issues/3492246 was my ticket where I detailed what I was going to do, and then I went about doing that.

This felt immensely good! I went through each Drupal 7 ticket and gave it a quick scan and then pasted-in my prepared closing statement. It took just over an hour, and was like taking a trip down memory lane: seeing all those old issues come up and remembering when I triaged some of them originally.

After this initial round of work, I've also been working in the 8.x-1.x queue to close out duplicate and solved issues. I've been focussing on support requests which are usually super quick to evaluate and close out. However, this means that I've not really had a chance to look through all the feature requests and bugs, so I still don't really have a handle on what's needed/broken with the module.

Understanding the code

I had a good old read of the code. There's some really great stuff in there, and there's some obvious room for improvement.

But, at least I know what the code does now, and can see some obvious problems/issues. But also, the codebase is small, and there some automated tests, so we've got a great platform to get going with.

Giving direction

There were a few tickets for 8.x-1.x where there were contributors making great contributions and I was able to provide some guidance of how to implement a feature or resolve a bug. I feel like the issue queue has been lacking any kind of technical leadership and so many tickets are collections of patches where developers are fixing the problem they have in quite a specific way. I'm really looking forward to giving some direction to these contributions and then at some point committing and releasing the great work!

Future roadmap/goals

I'm not committing myself to doing these exactly, or any particular order, but this is my high-level list of hopes/dreams/desires, I'll copy and paste this to the next sprint summary article as I go and adjust as required.

  • Get the project page updated with information relevant to Drupal 8.x-1.x version of the module
  • Update the documentation on Drupal.org
  • Not have any duplicate issues on Drupal.org

Hi, thanks for reading

ComputerMinds are the UK’s Drupal specialists with offices in Bristol and Coventry. We offer a range of Drupal services including Consultancy, Development, Training and Support. Whatever your Drupal problem, we can help.