Do we really need 3(+) meta tag modules?

[LeeteqXV]

How does the SEO meta module compare to the Metatag and Base_meta modules? Any reason they should not be combined?

• https://backdropcms.org/project/seo_meta
• https://backdropcms.org/project/metatag
• https://backdropcms.org/project/base_meta

[klonos]

There's far more for drupal: https://groups.drupal.org/node/18941

My guess is differences in implementation.

[findlabnet]

This module is replacement of discontinued module Base Meta Tags. Module Metatag is partially ported from Drupal, and have too many unresolved (yet, I hope) dependencies, mostly related to i18n. So, I use this my module as workaround, maybe a little dirty, but exists here and now.

[LeeteqXV]

@klonos - maybe I should rephrase the title; implying that we would like to avoid an unnecessary amount of similar modules and encourage maintainers for more collaboration as much as we can.

[findlabnet]

Hey @LeeteqXV , you seems an expert on this field, so maybe you can clarify to me: "an unnecessary amount" - how much it is? And who is a person which should to define (or decide) - which one from this amount is "necessary only" and only one is right for all of us?

[LeeteqXV]

@findlabnet - having been part of the Drupal community since its first month in 2001, I hope I am allowed to assume that the maintainers can find out that "amount" among themselves contextually for each case.

That is (by collective community experience...) IF they actually talk to each other, hopefully in time "before" each one has invested so much time into his own project so that it negatively affects the willingness to negotiate a merge...

Sometimes (very many times in the history of Drupal) we have to urge people to communicate, in order to avoid what in my experience indeed often results in an unnecessary amount of competitive projects. I dont have an opinion where to draw the line. I leave that to the developers.

My involvement here contains such a "reminder".

Right now the BD community is in the relatively early and "deciding" stages of reaching maturity and on the verge of leaping to a new level of attention. That metatag functionality is both particularly challenging, and equally important. Marketing-wise a strategic element at this stage for BD.

In addition to that; if you have noticed the crazy history of the metatag module(s) over at Drupal.org, the complexity, the never-ending discussions, etc., then you know that:

a) yes, there are (unfortunately) good reasons why it is very tempting to avoid the war and create new, smaller (short-term focused) competitor projects, YET:

b) all the more reason why it is an extra important challenge (for the community as a hole) to make sure to help the maintainers maintain a long-term, strategic focus, because THIS (SEO/metatag) area is not a trivial one. Most projects need this, and it affects so many other modules we use (complex and easy to underestimate various implications, especially for less experienced developers (I have no idea who that may be here, so not implying anything or anyone)), that we - IMO - should try as hard as possible to unite forces towards the most mature project (Metatag) that aready are receiving a good deal of resources and attention over at Drupal.org, perhaps helping to split it into (more?) sub-modules that can be disabled and avoided whenever they have serious, long-lasting bugs or "issues".

(Perhaps it is naive of me to have the wish to see that BackdropCMS becomes (much) better in avoiding "too many" similar modules than what we actually did in the Drupal community. IMHO we should have urged and urged and urged many more developers at much earlier stages and much more frequently so that we could have avoided a LOT more of that. So many opportunities have been lost these past 15+ years and so much time has been "unnecessarily(!?!) wasted" due to not having a stronger focus on this.)

[klonos]

@LeeteqXV you have a perfectly valid point in that we should not be repeating the mistakes we (should have) learned from from d.org and the fact that too many modules accomplishing the same or similar goals is bad practice and can lead to user confusion and user base bleed. You need to remember thought that building a Backdrop site from scratch is not the only valid use case. Some people might be upgrading from D7, in which case, they will most likely need any/most contrib modules they are using to have been ported to Backdrop. That's where "too many" Backdrop projects might become a thing: when they are ports from the respective projects in d.org. Now, if we are to be creating new, Backdrop-only projects, then yes, I agree that we should be first making an attempt to merge with existing ones.

[findlabnet]

@LeeteqXV, thank you for your opinion. I think people join to projects like Backdrop firstly because finding them appropriate to do something for fun or necessity for themselves. Maybe because of the lack of suitable things or disagreement with the approach to the implementation of existing ones. Someone happy with mainstream, someone need a functionality itself, but not all bells and whistles included with. A lot of things depends from experience and qualification of developer - not everyone, who wants to do something, knows how to do it well, especially in an unmanaged team. But IMHO everyone should have an options of choose, not only follow someone's general and the only true line.

[LeeteqXV]

@klonos - yes, but hopefully we will advance into "Migration waters" so that we do not have to port all these modules anymore...

I think that even if it is technically "not difficult" and even short-sightedly "economical" (read: easy) to do "upgrades", AFAIK the "recommended practise" in moving sites from D7-to-D8, WP-to-D7 and WP-to-BD(?) is to build a new site from scratch and migrate (edit: not "port") the content instead of "upgrading" it - so for long-term perspectives sake, perhaps we should recommend that practise also between D7 and BD?

[LeeteqXV]

@findlabnet - sure, I am not advocating to remove anybody's freedom of choice. And especially in the case of less experienced developers, they should indeed have the maximum easy point of entry just to get them in here.

However, I think that we should try as much as possible to merge any projects where the developers agrees it makes sense. We should continue to remind any/all projects that they ought to EITHER talk together (if they have the necessary background to do that successfully...) about these things at their earliest "convenience", or get touch with some experienced developers for advice on such processes.

Perhaps we could even make it a ToDo list item in a "getting started best practise" policy/documentation page AND even maintain a volunteer list of experienced developers that can provide such initial advice and experienced points of view?

Disclaimer: I do not know if something like that is already in place - I just mention it here in case it isnt. I have little or no insights into how developers are welcomed into the BD community (yet).

I am aware of the following resources: https://api.backdropcms.org/contribute https://api.backdropcms.org/converting-modules-from-drupal

The latter has a section called "Communicating: Let everyone know you are working on the module" - maybe we can add something like this there.

(Related: What is the policy for existing developers when they welcome newcomers at https://github.com/backdrop-ops/contrib/issues in respect to this topic?) @jenlampton

[jenlampton]

I don't think we have any kind of policy around duplicate modules, we're in the same boat as Drupal in that regard. What I find helpful are those "module comparison" tables that list features each project provides in a handy table so you can see them all side-by-side. Maybe we need a place to build those?

[jenlampton]

(oops, closing unintentional)

[LeeteqXV]

@jenlampton Module comparison charts are great. Also a good way to initially find out how overlapping two given modules are, for the initial considerations which may be suitable for merge talks. Maybe we could make it a "policy" that all similar modules on BD are "strongly advised" to maintain such a chart (with an equally "strong" invitation to anyone else - not only the maintainers - to help establish and maintain them)?

[jenlampton]

Yes, great idea @LeeteqXV. Also @findlabnet I would love to have you as a maintainer on the metatag module if you are interested in helping with translation! :)

[findlabnet]

Sorry for the late reply, very busy timeline. Thank you for invitation @jenlampton, I'll think about it.