japerry created an issue. See original summary.

japerry’s picture

Status: Active » Needs review
2.26 KB

Message is configured via the block admin.

drumm’s picture

Status: Needs review » Postponed (maintainer needs more info)
japerry’s picture

Issue summary: View changes
japerry’s picture

Issue summary: View changes
japerry’s picture

Issue summary: View changes
Status: Postponed (maintainer needs more info) » Needs review
2.56 KB

Updated. tis tired.

Also did some comment cleanup.

tim.plunkett’s picture

@drumm, this is for (the above link was a typo)

@webchick, @YesCT, @japerry, myself, and others are working on this at Drupalcon.

japerry’s picture

5.75 KB

Somewhat a rewrite based on webchick and drumm's suggestions. Its now in the downloads table and works for many different workflows for the issue queue. Happy testing!

tim.plunkett’s picture

+++ b/drupalorg_project/drupalorg_project.module
@@ -1619,6 +1623,109 @@ function drupalorg_project_form_views_exposed_form_alter(&$form, &$form_state) {
+          ->propertyCondition('title', $node->field_project_machine_name[$node->language][0]['value'], 'CONTAINS')

This could use "[" and "]", and switch to 'STARTS_WITH' for the operator, if we want. Though it won't really work if they don't follow the format.

drumm’s picture

Status: Needs review » Needs work

Yes and that would also:

  • Hit the node_title_type index and scan many fewer rows.
  • Not match entityreference when you are looking at entity.

And there are a few code style issues.

japerry’s picture

Status: Needs work » Needs review
5.86 KB
3.22 KB

Yup, -- CONTAINS isn't a great way to do the searching, but wanted to see it work. And when I started testing with file_entity, I started seeing some of the problems with that approach.

I've changed that, as well as the node id, which should be directing properly now.
To see a working example: (u/p: drupal/drupal)

And test against these other issues that exist in the dev site queue:

I am running into issues with project_release caching the existing status a bit too aggressively for testing. This may mean that statuses won't show up very quickly on the project pages, but then again this is already an issue for security messages.. so maybe it doesn't matter.

tim.plunkett’s picture

Why did this go back to being a yellow 'warning' instead of the blue 'help'?

japerry’s picture

The notice is based on my notes from drupalcon and the project review key on the contrib_tracker page.

Here is the key:

  1. Error (red) boxes: Issue Missing, Active, or Postponed
  2. Warning (yellow) boxes: Needs Work, Needs more info
  3. Message (green) boxes: RTBC and Needs review
  4. Info (blue) boxes: Included with D8 core, Renamed or Deprecated by another project

If this needs to be changed up, lets figure out what goes where.

drumm’s picture

Status: Needs review » Needs work
 * Implements hook_views_post_execute().
 * @param $view
 * Checks to see the status of Drupal 8 for the contributed module.

function drupalorg_project_views_post_execute(&$view) {

Doc comments should not have blank lines between them and the function.

    if (count($view->args)) {
      $node = node_load($view->args[0]);
    $project_type = explode('_', $node->type);

This makes it look like it will fail badly if $view->args[0] is not set. I think that will always be set and the if statement is not necessary.

explode('_', $node->type) is not something I've seen before. What about project_theme_engine?

    if (!empty($node->field_project_type) && $node->field_project_type[$node->language][0]['value'] === 'full') {

Can are replaced with

    if (!project_promote_project_is_sandbox($node)) {
japerry’s picture

Status: Needs work » Needs review
5.82 KB

So the top part was some copy/paste typos. While we -probably- don't need the arg check, I stuffed it into the main check anyway just for good measure. In its old spot, that check did nothing, and if it didn't pass the check the node wouldn't load and who knows what errors would have occurred later on!

Thanks for pointing out the extra underscore. simple regex replace fixes that.

And also that API call has been added.

It'd be great to get a review from webchick to make sure it functionally works as she is expecting, and after that make sure Dyannenova doesn't think the layout/placement is hideous.

webchick’s picture

Assigned: Unassigned » webchick

Reviewing now.

DyanneNova’s picture

Status: Needs review » Needs work

In addition to the type (warning, help, etc.) all of the status divs need the "messages" class to get the correct styles.

webchick’s picture

Here are screenshots of the various states, for ease of review:

No issue in contrib_tracker yet
No issue yet

No port started yet (active)
No release yet

In development (needs work)
Not usable yet

Usable / Ready to go (needs review / rtbc)

Pre-release version available

Stable release available (fixed / closed fixed)
No extra box

Moved to core (won't fix)
Moved to core


Old, crufty project without 6.x/7.x release
no table

What's remaining?


- Postponed, e.g. - currently shows as development not started, but basically means "blocked" so we need a separate message for that.
- Postponed (needs more info), e.g. - currently shows as "in development" but need a separate message for that.
- Projects without an alpha/beta/rc release of some kind won't get a box, e.g., which nevertheless has 1000+ installs.

Let the bikeshed begin!

Here's a Piratepad for sorting out the exact wording for each of these states:

japerry’s picture

Status: Needs work » Needs review
6.6 KB

Thanks for the review and screenshots! I think this patch tackles the questions and bugs webchick found in #18 -- as well as the suggestion from DyanneNova.

Remaining tasks:

  • Verify the wording is correct for each message.
  • Decide whether dev-only releases should have a message displayed.

And of course see if there are any other outstanding bugs ;)

japerry’s picture

7.81 KB

Another small update. This fixes the download table message cache that was causing statuses to not update very fast.. or at all.

japerry’s picture

Status: Needs review » Needs work

After talking to Drumm, it looks like we need to rework the cache clearing still. Specifically add a ^ in the regex to enforce the issue pattern. But also make sure the issue is attached to the contrib_tracker project.

webchick’s picture

Ok gave up on piratepad, moved to Google Docs.

This now contains the current versions of all the text, has screenshots/examples of each on the dev site, and contains a spot for both the original text and refined text. Hoping to sprint on some folks refining this further at BADCamp, but I don't see anything in any of the message that isn't "shippable" as-is.

japerry’s picture

Status: Needs work » Needs review
7.92 KB

After reviewing with Angie, and doing some further tests with the caches, I think we're good here. Hopefully can deploy for some in-person BADcamp reviews!

drumm’s picture

I deployed this on a fresh dev site at (We've moved to a new dev server.)

Kristen Pol’s picture

Great work! I've reviewed the text in the Google doc and had some minor feedback but it's looking great. :)

japerry’s picture

7.93 KB

Here is a quick fix for an api call per drumm.

  • drumm committed 730932e on 2573661-contrib-tracker authored by japerry
    Issue #2573661 by japerry: Show message linking users from project pages...
drumm’s picture

Expanding the first if condition in drupalorg_project_views_post_execute():

$view->name == 'project_release_download_table'
&& ($view->current_display == 'recommended' && !empty($view->result))
|| ($view->current_display == 'security' && !empty($view->result))
&& count($view->args)

Mixing && and || in the same nesting level is at best confusing, and could be a bug. Where should parenthesis be added?

  • drumm committed 2dc049f on
    Issue #2573661: Add type hints
  • drumm committed 9ca63fc on
    Issue #2573661: Replace path tricks with project_load()
  • drumm committed d6ab274 on
    Issue #2573661: Replace regular expression with...
  • drumm committed ef1ef18 on
    Issue #2573661: Comment cleanup
  • drumm committed f9146a2 on
    Issue #2573661: Code style cleanup
drumm’s picture

I committed some code cleanups and 3 real changes to the 2573661-contrib-tracker branch:

  • Replaced juggling the path to get the project from the short name with project_load()
  • Replaced parsing the node type with drupalorg_project_node_type_label() to get the human-readable project type.
  • Replaced project_release_query_releases() with a custom EntityFieldQuery to check for 6.x or 7.x releases. It looks like only the existence of a release was important. project_release_query_releases() actually node_load()s all of the releases and does get slow.

#29 needs an answer before deployment. I think I know where parenthesis would make sense, but don't want to mess it up.

Now a blocker, but should this message mention being D8-specific?

This !project has been renamed or deprecated by another !project. Please visit this !issue for more information.

drumm’s picture

Status: Needs review » Needs work

For #29.

webchick’s picture

Good catch, let's do " another !project in Drupal 8. ..."

I'm not familiar enough with the code to answer #29.

  • drumm committed bb56ea0 on 2573661-contrib-tracker authored by webchick
    Issue #2573661 by webchick: Mention D8 for duplicate state

  • drumm committed 4e472e7 on 2573661-contrib-tracker
    Issue #2573661: Clarify test for adding D8 contrib tracker message
drumm’s picture

Status: Needs work » Needs review

Done and I went ahead and committed my best guess at the intended logic:

$view->name === 'project_release_download_table'
&& ($view->current_display === 'recommended' || $view->current_display === 'security')
&& !empty($view->result)
&& count($view->args)

The View name and args are safe to assume as always needed; and I pulled the check for result out because I can remember that part of discrete mathematics.

This can be reviewed on pages like

japerry’s picture

Yes, Drumm that logic is correct. There is absolutely no reason why the view->result check needs to be done twice. I think I know how it got like that but doesn't matter ;)

Otherwise this is looking good!

  • drumm committed 2dc049f on 7.x-3.x, dev
    Issue #2573661: Add type hints
  • drumm committed 4e472e7 on 7.x-3.x, dev
    Issue #2573661: Clarify test for adding D8 contrib tracker message
  • drumm committed 730932e on 7.x-3.x, dev authored by japerry
    Issue #2573661 by japerry: Show message linking users from project pages...
  • drumm committed 9ca63fc on 7.x-3.x, dev
    Issue #2573661: Replace path tricks with project_load()
  • drumm committed bb56ea0 on 7.x-3.x, dev authored by webchick
    Issue #2573661 by webchick: Mention D8 for duplicate state
  • drumm committed d6ab274 on 7.x-3.x, dev
    Issue #2573661: Replace regular expression with...
  • drumm committed ef1ef18 on 7.x-3.x, dev
    Issue #2573661: Comment cleanup
  • drumm committed f9146a2 on 7.x-3.x, dev
    Issue #2573661: Code style cleanup
drumm’s picture

Status: Needs review » Fixed
Issue tags: +needs deployment

Ok, I think this is ready for deployment.

drumm’s picture

This has been deployed.

webchick’s picture

Awesome, thanks!!

One report from #2573659-32: [project_short_name] Project Human-Readable Name (Issue Template):

"I've got a rather nasty message on about how there isn't a Drupal 8 port, when there is actually a full Drupal 8 port."

It'd be nice if there was some kind of a softer message for this situation, like "This project has a Drupal 8 port started, but no central tracking issue in contrib tracker project. You can create one now." or whatever. Given we did not automate the creation of issues in contrib_tracker, the actual release table info should take precedence over the issue queue.

benjy’s picture

The UX for this is horrific, not only does it not detect when there are 8.x branches, the warning looks like a security style warning it's so severe. Red was a poor colour choice.

There are still many people building on Drupal 7 and now there is a big scary looking warning on the module page. I really think this should have an opt-out feature.

mradcliffe’s picture

drumm’s picture

Status: Fixed » Needs work

It'd be nice if there was some kind of a softer message for this situation, like "This project has a Drupal 8 port started, but no central tracking issue in contrib tracker project. You can create one now." or whatever. Given we did not automate the creation of issues in contrib_tracker, the actual release table info should take precedence over the issue queue.


mradcliffe’s picture

Here are some alternatives for projects with a Drupal 8 release or those that will continue to support Drupal 7 without needing a Drupal 8 release:

For contrib developers with Drupal 8 releases,

  <a href="">
    <img src="/files/project-images/d8-supported-module.png" alt="Don't Panic! This module supports Drupal 8 right now despite the misleading message below! Download the Drupal 8 supported release!" />

Don't Panic! This module supports Drupal 8 right now despite the misleading message below! Download the Drupal 8 supported release!

For contrib developers who maintain Drupal 7 supported modules and themes:

<img src="/files/d7-still-supported.png" alt="Don't Panic! This module is still supported despite the scary, red message below!" />

Don't Panic! This module is still supported despite the scary, red message below!

For contrib developers who maintain modules or themes that may not need a Drupal 8 release do to deprecation or merging:

<img src="/files/d8-not-needed.png" alt="Don't Panic! This module is still supported in Drupal 7, but not needed in Drupal 8." />

Don't Panic! This module is still supported in Drupal 7, but not needed in Drupal 8.

drumm’s picture

If there isn't updated code for correcting the "No Drupal 8 port information …" message by tomorrow morning, I'll comment it out to hide it until there is a patch for it. Please do not add workarounds for this to project page content.

webchick’s picture

I wonder if we can address a lot of the concern around these messages that's brewing over at #2573659: [project_short_name] Project Human-Readable Name (Issue Template) by simply changing all messages to an "info" box rather than warning/error. That seems to be alarming a lot of people, esp. with respect to D7 support, which is totally fine.

rcross’s picture

following on from #2573659 I would also support moving to a info box. Alternatively, would be excellent if there was some way for Module maintainers to have some level of control over the message. Often it is better to link to an issue in the project that is detailing the D8 progress, or some other information like that a D8 port is not planned or postponed based on some dependency or probably several other permutations of conditions that we are unlikely to cover all variants of.

In general, I also think this approach of forcibly imposing this on module maintainers is poor practice (especially without any prior email notification/consultation to maintains about it) and feels somewhat counter to Drupal community vibes.

  • drumm committed a66de8b on 7.x-3.x, dev
    Issue #2573661: Less heavy-handed messaging
drumm’s picture

Using the blue info box for all works for me, committed & deploying. (The harsh black border on the box is bluecheese not completely overriding core default styles with the box in an untested page region.)

This also comments out the "No Drupal 8 port information has been found …" message for now.

drumm’s picture

#49 is now in production.

rcross’s picture

Perhaps this was mentioned previously, but I've realised that this message is predicated on having a D7 X.0 release of a module (D6/D5 releases seem unaffected). So, modules that may have a mature beta or rc D7 for example (perhaps long standing) and have marked that release as a recommended release, aren't getting any notices/encouragement of D8 status. If we're going to be heavy handed and pushing people to indicate D8 status, it would seem we might as well put it on any project with a recommended release compatible with D7 (and probably D6 too, considering the decision around d6 migration)

webchick’s picture

All projects with a D7/D6 release of any kind had the messages previously. I think #49 shut the message off for any module without a pre-existing issue in contrib_tracker, which is going to be most of them at this point. Unfortunate, since it makes the UX for this message pretty random/unpredictable. :\

And on the idea of configuring messages to point to a different issue instead, negatory. The entire idea is to have a consistent way to get at the D8 porting status of various modules. You can't do that if some modules have an issue called "D8 port" another has one called "Port to Drupal 8" another has no central tracking issue and just issues set against their 8.0.x branch, yet another no issue at all but code happening at GitHub, etc. (All of these and more are the case currently, hence the need for this project.)

Fortunately, though, the template includes a section to link to those issues that already exist for those projects who have them, so you can still link there, in effect.

markcarver’s picture

These messages are intrusive and disruptive, regardless of what color they are.

@drumm in #2606808-5: Provide a way to opt-out of Drupal 8 Contrib Porting Tracker without creating issues:

Adding another thing being stored to this turns this thing into even more of a contraption. I re-opened #2573661 because it is penalizing module maintainers who have worked on updating their module for not doing paperwork they didn't know about.

I couldn't agree more with this. Bootstrap has it's own workflow/tracking for it's D8 port (mostly a google document shared between maintainers).

We have been slowly, but steadily, working on our D8 port for quite some time now.

Just because we don't have the 8.x-3.x-dev branch up on our project's release table means absolutely nothing.

The fact that we have to set our "status" on some other issue in some other project is rather clunky and doesn't allow for intuitive bi-directional communication. This whole thing is extremely... odd.

I get what this is trying to solve, but this is absolutely the wrong way to do it.

webchick’s picture

So, that's a great example. Let's use it to talk about why this separate project was started in the first place.

You, Mark Carver, and a handful of other people you work with on Bootstrap, happen to know that Bootstrap has a Google Doc somewhere where status is being tracked. You probably also happen to know the code is at location X and you have a tracking issue at issue Y that may or may not highlight the fact that a Google Doc and such code exists.

But what everyone else is going to do is one of the following.

If they are community-savvy, and have been around the major version upgrade block before, their workflow will be:

a) Install Upgrade Status. When it says that the Bootstrap theme they depend on is "red" for "no D8 code found yet" they are going to...
b) Go to the Bootstrap project page. When they see no 8.x branch there, they are going to...
c) Try 4 or 5 different search terms in the Bootstrap issue queue to attempt to find a central D8 tracking issue.
d) If they find one, they will update their internal spreadsheet to say "there is a D8 porting effort going on and it is X" (hopefully the place to find the code was mentioned there; if not...)
e) Repeat for every project, and based on the aggregate picture, estimate they can port to D8 in QX of 20XX.

Or, if they are not (this is 96% of people):

a) Go to the project page. If there's no D8 code found there, put off porting to D8 for at least 6 months to a year.

So this project is necessary because it allows us to have a central, consistent data store across all projects to explain what their relative porting status is, and to give evaluators a realistic picture of where D8 is actually at readiness-wise. It's designed to be minimally intrusive for module maintainers. These issues each only have to be a) created by someone (not necessarily the module maintainer), b) moved a maximum of 5 times from active -> needs work -> needs review -> RTBC -> fixed (often only 1-2 of those states, and again, not necessarily by the module maintainer).

And then you as a module maintainer can work wherever you are most comfortable: GitHub, Google Docs, emailing patches back and forth, whatever. But the entire community gets visibility into what you know and can base their choices around D8 adoption based on that information. (These issues are also a great place to highlight fundraising opportunities, etc. to help accelerate porting since by definition the people who are reading these want these projects done.)

So I respectfully disagree with your assessment that this is the absolutely the wrong way to do it. I've had to lead point on "port all the contribs" for 5 major releases now. Trust me; this approach is by far the most holistic and thought-through approach we've ever done, and it has tons of support from people who are more than willing to do data entry in order for the wider community to have transparency on D8's actual readiness, so you can stay focused on porting your stuff.

Kazanir’s picture

I'll take a little heat here too -- lots of people at DrupalCon, including me, thought this would be a great idea. Drupal 8 is now at a point where we need lots of community involvement and communication to facilitate a major version upgrade in the contrib space. (I called this "climbing contrib mountain" at the D8 retrospective session.) What we tried to come up with here is a way to track this information while supporting maintainers using their own workflows.

The goal is to meet the community's needs without creating an undue burden on project maintainers. No one is trying to penalize or harass module maintainers or bog them down in paperwork for no reason. Thankfully, there is a lot of volunteer effort in getting tracking issues entered for lots of modules without needing to involve the maintainers just to fill out paperwork. :)

markcarver’s picture

You misunderstand. I'm not saying that "tracking" this data isn't necessary or unimportant.

However, just arbitrarily using some separate project and its issue queue to do it IS. It's prone to error (e.g. user input) and ultimately just some custom code to get it all "connected". This means it will be custom code that has to be fixed when d.o is ported to 8.x in the future.

Why do we insist on creating new "projects" and then just using their issue queues to supplement features that d.o should have natively?

This is data that should be collected and managed on the project itself. We need to have a more permanent "solution". This isn't a unique problem; it's one we have every time there is a major release.


Also, before anyone says "time" or "money", might I remind you that this is getting to be a really old excuse. May it be relevant, sure, but I'm getting really tired of the lack of UX/UI quality in "features" being added to d.o in spite of this. We all deserve cohesive experiences.

Again, this is yet another example of the lack of UX/UI design when it comes to d.o. I have asked over and over to be added to some group/list/whatever so that I can give feedback on stuff like this before it's just "deployed".

markcarver’s picture

24.29 KB

Placing the "port state" of a project inside a separate issue is subject to it being updated on a regular basis, manually. This means that a project's current "port state" could potentially be stale/outdated until some individual, despite good intentions, has the time to do it.

edit: it also means that project maintains must constantly be aware of this external issue and remember to "change it" once there has been a milestone achievement (aka tag/release).

In reality, the messages that are added to the top of a project's release table (i.e. "port state") can be completely automated based of a repository's branches and tags, despite if there is an official "release" node or not. There is no need to physically involve "data entry" for this.

edit: we have all the data we need in the repositories themselves. the association with these "port state" issue statuses are in direct correlation to whether or not a specific branch/tag in the repository exists.

Once the data is stored on the project itself then lists, blocks or even "overview" page(s) could be created for people to find this "comprehensive" information.

Really, the only thing that's actually humanly needed is directing people to a specific issue (if there is one) where an overview of the porting efforts is taking place (which is often in the project issue queue itself, not some other project).

Using the stored automated "port" data, we can append a "issue" creation/link to a referenced issue once it's associated on the project itself with something like the following:

This keeps all the data/association nice and neat without having to involve some arbitrary "third party" project.

webchick’s picture

That approach:

- Requires module developers themselves to manage this data (contrib_tracker is accessible/editable by anyone, so requires no direct action by contrib maintainers)
- Requires code to be on D.o (while my vast preference, at least 30-40% of contrib atm is happening on GitHub, so contrib_tracker allows us to deal with this reality)
- Assumes such an issue exists for each project (that's more like only 10-15% of projects, at best)
- Loses the consistency between/among projects that the template / third-party project provides since no one/everyone "owns" those issues

So overall, does not feel like a better approach. Especially given that module developers can still create a central tracking issue in their project (if they choose), can still link to it prominently from their project page (if they so choose), but also with the benefit of being able to use whatever tools/processes work for them, ignoring contrib_tracker altogether if they so wish (and let "project manager" type people maintain that queue).

markcarver’s picture

  1. Not true, it would be mostly automated using the repository information. The only time it isn't is when a maintainer must answer the very basic "yes/no" question of whether or not the project will be ported to begin with. Only a maintainer can answer that and if it's abandoned, then there are processes in place for someone to take over to become a maintainer and then they can answer it.
  2. When did d.o start actively supporting GitHub? Last I heard about this topic, the consensus was "Nope, all on d.o". So, unless that has changed (despite the "reality") this is rather a moot argument. It will eventually all have to come over to d.o.
  3. No it doesn't assume an issue exists. It's based on repository references initially. The only time an issue would come into play is if/when there is uncertainty about a port. If there isn't one, there should be a link that would allow an issue to be created in the project's issue queue (using the same kind of "status" association). If one does exist, it just links the existing issue. Nothing is "assuming" this exists. It just provides the option to create the entity reference once a maintain has "officially" answered yes/no about a port... then it's all handled automatically. The link that allows people to "create" the port issue could also include something that would allow the entity reference to automatically be associated with the project.
  4. Templates on d.o is a joke to begin with and really an entirely separate issue all together. I have said this time and time again while trying to get it out of Dreditor. See #1393226: Encourage use of issue summary template. This issue alone needs attention because it's very clear we need something on d.o to handle templates. Whether it's basic issue summaries, beta/rc evaluations or now suddenly this.

I'm not trying to be "difficult" here. I'm just pointing out the obvious: sure, while there may have been some brain storming on this, it certainly didn't involve much UX/UI discussion from individuals (like me) that specialize in this area.

I've come up with half a dozen different "solutions" (mostly in my head) just today since discovering this issue. I wasn't emailed, notified or invited. Nor do I actively watch the drupalorg/infra issue queues.

Why is it that UX/UI people are always the absolute LAST to know about "improvements" like this?

Why are we not allowed ample opportunity to work with the community instead of having to resort to complaining after the fact?

This kind of "development" workflow really puts a bad taste in everyone's mouth.

webchick’s picture

I can't speak to the deployment process for improvements and what their communication strategy is and who they do / do not personally involve. I can speak to the rest, however.

1) No, this can't be automated, because there is literally no standardization at all across projects. Trust me. I've been around this block before, multiple times, but even a cursory glance will show you this.

1b) A maintainer can still answer the question of whether the module will be ported to D8 by filing a contrib_tracker issue that's either "won't fix" (moved to core) or "duplicate" (use some other project instead). This will then be reflected on the project page accordingly.

2) Whether officially supports GitHub or not is completely irrelevant. What's relevant is the adoption of Drupal 8 is going to be severely hampered until there is transparency as to where D8 readiness actually is, and right now that picture will be horrifically skewed if it centers only on code found on

Contrib Tracker simply acts as a "single source of truth" for how ready D8 is. It is not opinionated about what tools maintainers use, only that the information is coalesced in a central place, and done so consistently so we can utilize the information in tools like Upgrade Status and provide a central "burndown" chart on the getting involved page like we had for D8 core criticals. (both in progress)

3) I can't derive from repository metadata such as -alpha12 that the module is actually usable, or is undergoing active development and completely unsafe to use, or stable enough for production and simply has a hesitant maintainer. That requires human intervention. That is the goal of contrib_tracker, to add this "metadata" around what "alpha" actually means in the case of your specific project, since this also is widely variable all over contrib.

4) People seem to be able to get by fine atm just using the clone issue functionality, so not sure about this one.

I get that this was deployed with some problems, but I'd really appreciate some benefit of the doubt and a lack of demonizing here. This wasn't some half-baked idea; there was a group of people including project managers, module maintainers, community folks, etc. who really spent quite some time thinking this through. Please read the project page, which attempts to answer a lot of the questions/concerns that are being brought up here.

japerry’s picture

Just for some clarity on Association vs community work: This started as a community issue, not a Drupal Association issue... and it still is. In fact both drumm and I have been working on this issue in our non-work hours (its lunch time!). The design and implementation was totally community driven and reviewed.

Regarding being more involved: I'd suggest subscribing to the drupalorg customizations issue queue if you want to participate before features are deployed.

markcarver’s picture


I'm not "demonizing", I was voicing valid concerns as I often do when it pertains to UX/UI (and as a top 5 contrib maintainer). That is my area of expertise and, to be quite honest, it is becoming rather insulting that I'm dismissed when I do so. I did read the project page (that was also rather insulting btw, I'm not some n00b user) and no, I don't feel that it answered my concerns about using an entirely separate project for the sake of an "issue queue" (that we seem to abuse quite too frequently IMO).


This started as a community issue, not a Drupal Association issue... and it still is.

That's also part of the problem. Just because this is something that started/is community driven, doesn't mean that it should "just get deployed". There should be gates, just like core has btw, for something that affects the entire community.

Regarding being more involved: I'd suggest subscribing to the drupalorg customizations issue queue if you want to participate before features are deployed.

I do: D.o+UX, Needs usability review. However, as you can see here, this issue isn't tagged with anything at all.

mradcliffe’s picture

1b) A maintainer can still answer the question of whether the module will be ported to D8 by filing a contrib_tracker issue that's either "won't fix" (moved to core) or "duplicate" (use some other project instead). This will then be reflected on the project page accordingly.

  1. I should not have to do anything for each project so that I don't have misleading message on my project page.
  2. D8 contrib tracker or should look at, as @markcarver hinted at as well,
    1. Whether a Drupal project supports releases;
    2. If there is a Drupal 8 supported release;
    3. If there is a Drupal 8 development release;
    4. What the Drupal project maintenance and development status are;

    and if any of those are true, don't display a message.

  3. I tried out contribkanban and I find it really hard and slow to use, and I probably won't use it to track or evaluate when to migrate a Drupal 8 web site.

I have noticed that active contrib maintainers have been doing a great job explaining where Drupal 8 development is happening for their projects already (whether on Github or The issue probably originates more for non-active contrib maintainers, and I think that we have processes in place as @markcarver mentioned that do this already.

This would all be smoother if D8 Contrib Tracker and used the already established releases on, and if a project is not using releases, then an "check the project page" would suffice as a status. Aggregator module has its uses :-)

webchick’s picture

Except that we do actually want a message pointing to contrib_tracker, even on projects with D8 releases, because of #61.3.

Your feedback seems like it's from before #49 though; since then the message will not appear on project pages with no corresponding contrib_tracker issue. Or if not, pointing to specific projects that have confusing messaging would be helpful.

drumm’s picture

The harsh black border on the box is bluecheese not completely overriding core default styles with the box in an untested page region.

I was wrong about this, it is actually the messages and help classes not being meant to be combined.

drumm’s picture

I pushed a commit to remove messages to the dev branch, that will get deployed next time there is a drupalorg module deployment.

  • drumm committed c1c90ef on
    Issue #2573661: Remove messages class
drumm’s picture

Status: Needs work » Fixed

This has been sitting untouched for quite awhile. Going to call this fixed. Any followups should go in separate issues.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.