Announcing the Drupal 8 Contrib Porting Tracker Project on Drupal.org

October 1, 2015
9
2

The Problem

I have a theory. My theory is that every single person / organization who is considering building a site on Drupal 8 has created some variation of the exact same spreadsheet. The spreadsheet tracks rows with information, such as which contributed projects the site needs, what URL those projects live at, who the maintainers are, what the project's current porting status is, etc. To figure this out, you go to each of the respective project pages and look for an 8.x version. If that comes up empty, you attempt to search the issue queue for variations of "Drupal 8," "D8 port," etc. Worst-case, falling back to good ol' Google. Repeat every few weeks. Man months have probably been spent on this duplication of effort so far. To further build on that theory, I'm guessing that these spreadsheets do not always jive with current reality. Because you might have missed the update that contributor X gave on Twitter one time about her predicted module's release date. Or you might not have been sitting next to contributor Y at dinner during DrupalCon and found out that her module's actually being ported on GitHub or BitBucket, only being moved to Drupal.org when it's complete. Or you didn't get the chance to actually install the project yet to determine that even though this one has just a -dev release, it's actually quite stable, and even though that one has a beta release, it's changing APIs every 6 minutes. Or whatever.

The Solution

Enter the Drupal 8 Contrib Porting Tracker! This is a "meta" project that holds issues that represent the porting status of various projects, and allows us to work as a unified Drupal community to combine our collective observational super powers into one data set that can be used by anyone considering building on Drupal 8.

Screenshot of issue listing

How does it work?

Issues within the project move through an issue status workflow of:

  • Not started a.k.a "Active:" No port has been started yet.
  • In development a.k.a. "Needs work:" D8 development has started but is not yet usable.
  • Usable a.k.a "Needs review:" Project has Alpha or Beta D8 releases available for testing.
  • Stable a.k.a. "Reviewed & tested by the community:" Project has a Release Candidate (RC) D8 release.
  • Complete
  • a.k.a. "Fixed:" Project has a stable D8 release.

(There are also a couple of special statuses that fall outside the general workflow.) The goal is to get 100% of the projects in the list to "Fixed," as quickly as possible, to help enable widespread adoption of Drupal 8. Each issue follows a standard template, which includes information such as who's porting the module, where to find the code, and what help is needed by the maintainers to expedite porting. Project page for Drupal Commerce.

Why do we need this project?

Back when I first started at Acquia in May 2011, Drupal 7 had just recently come out and one of my first tasks was to facilitate a community-wide effort to get the big projects ported. This took the form of a standardized issue tag used in each of the projects' Drupal 7 tracking issues, and an external site to track status, which was more-or-less a public version of the Upgrade Status module with an opinionated list of projects. However, this approach ran into a few problems:

  • Issue tags are easy to misspell/misplace, and require 'insider' knowledge to learn/remember the names.
  • Searching for the status of a module you cared about was difficult, because that status might be spread over multiple issues, or the module maintainer might not have gotten around to making a tracking issue yet.
  • Promoting an external, non-D.o site was difficult, as was performing those updates to the information that had to be done manually.

So I'm really excited about this project, since it eliminates all of these issues. It creates a single, canonical, searchable source for info, on Drupal.org in an "official" capacity, and with the ability to consistently track additional metadata such as estimated release timeline and how to help. I'm also excited that it enables people like project managers, folks at sprints without a lot of prior D8 experience, etc. to make meaningful contributions to Drupal 8.

Thanks!

The Drupal 8 Contrib Porting Tracker is a joint effort bootstrapped by many people before and during DrupalCon, including:

Kanban view of modules So, bottom line, regardless if you're the module maintainer or not, "if you see something, say something" — please share whatever knowledge you have about various modules' porting status and/or places to help, so we can get all of these to green as quickly as possible, and Drupal 8 can achieve world domination! :D

Sign-up for our Developer Blog Newsletter

Thanks!

Add comment

By submitting this form, you accept the Mollom privacy policy.

Yay mglaman!

Huge thanks to Matt Glaman for building Contrib Kanban! It's great seeing the community find these great uses for it.

Encourage d.o

Can we encourage "where's the code" pointing to somewhere on d.o. I've come across many issues with "port to d8" with links to multiple unrelated github repos and when I asked a maintainer they pointed to a completely different github repo. Github's decentralized model is amazing for fast development but makes tracking large canonical work hard without close communications.

RE: Agreed, it's a mess. :(

That was one of the other primary motivators of this project is that at least 50% of the modules we looked at have code not in the main project repo; in patches hanging out in the queue, d.o sandboxes, GitHub, BitBucket, etc.

I plan to make a follow-up blog post called something like "Project page or it didn't happen" that attempts to explain the pitfalls of this approach. While I don't want to dictate tools that people use to port modules (yay, you're porting modules!), without visibility of these efforts on the "mothership" it's going to be a significant blocker to D8 adoption.

That's a really good idea,

That's a really good idea, thanks!

This reduces duplication, or

This reduces duplication, or does it just move the duplication to a different place? It seems like the "Upgrade to D8" issue in each project will continually get out of sync with the porting tracker.

RE: Reducing duplication

The goal here is for these issues to only track status, not planning of a port or the details of the work. Meta-issues in each individual project often contain planning (and the intent is to link to those issues from their Contrib Tracker issue) if they exist. But because every project's model is different and some aren't even using Drupal.org for their issue tracking, this is a good way to track everything in a unified way.

Since anyone can update these issues and there are only a few progress steps (i.e. "no code" -> "some code" -> "alpha to beta" -> "done!") keeping the issues in sync shouldn't be very hard if people are using the tool regularly. I think there's also a potential plan to link the issue to the project's Drupal.org page but I don't know if that is confirmed yet.

RE: IMO these are tracking two different things...

The "Port to D8" issue in a given issue tracker is going to generally be a detailed list of things left to do, what their current status is, etc. Here's a random example from inline_entity_form: https://www.drupal.org/node/2577203 That's not what this project is for (though it should definitely link to those issues under the "D8 Roadmap" heading).

This project is more for tracking "meta" data around that port (such as the fact that the Rules team is trying to raise money http://d8rules.org/ to expedite porting) and to be useful in explaining to a relative "outsider" to a given project whether that big list of issues left to do means the module's actually usable or not (this is actually extremely hard to tell without an innate understanding of all the issues).

And while it's true that there will be some duplication of effort (a module maintainer makes a beta release and indicates the API is now stable, someone needs to update the Contrib Tracker ticket to move it from "needs work" to "needs review"), the module maintainer themselves doesn't need to do this; it can literally be done by anyone following along with a project's status, and from talking to people at DrupalCon, there are many who would be thrilled to play this role of "project shepherder." :)

I like!!! +1000. Great idea

I like!!! +1000. Great idea @webchick et al.

orgs that have that spreadsheet

Hah! We have that spreadsheet exactly! Can't wait to look at this.