Open Letter

I thought I'd form a sort of target page to direct the assorted maintainers that have been listed in the Dupes. Just to ping into all their respective queues in a polite manner.

As opposed to Various attempts to compare enumerate, tabulate and choose between available modules and features, I think we should be encouraging these developers to merge efforts or voluntarily retire their modules in favor of more consistant solutions.

I was going to wikify this (and may still) but thought I'd throw it up for discussion input first. (Why is wiki/forum an either/or choice?)

Any re-phrasing is welcome.
.dan.

Dear Maintainers :)

A proposal to consolidate.

Everyones modules scratched an itch at some time, and we can assume that most of them did their jobs quite well, but it's possible that the originators were not aware of all existing efforts, or that later projects did he same thing differently or became more popular or supported. Some modules even logically expanded to include features that overlap another, producing conflicts where before there were none.

This memo is not about seniority of modules or module develpers.

It is about

• Gathering support for good ideas and features.
• Improving code quality by getting more eyes on shared code.
• Learning from each other. Recognising innovation.
• Increasing the popularity of your work by allowing more users to download a more common codebase.
• Reducing everyones workload.
• Making it easier for users to choose the best solution.
• Reducing the number of redundant or unported modules. (And making the Drupal project stats look better).
• Getting things ported!

I ask from anyone who has a module that appears to be overlapped by another, to please consider any of the following options:

• Documenting on the project page what distinguishes it from others that it may be confused with. Both being 'simpler' and 'having more options' are regarded as benefits to different people!
• Cross-linking from the your project page directly to competing or comparative modules to assist downloaders to make an informed choice.
• Identifying cool features in other projects that you could merge into yours.
• Identifying UI or configuration options that make sense and could be copied.
• Finding hooks or code style solutions that you can learn from or hadn't thought of.
• Contacting other module issue queues with suggestions and feature requests along with sample code and "here's how I managed to do this".
• Offering to come on board and merge your own code with theirs.
• Offering to retire your own module and endorse another solution.

The latter options are preferred... making your module more like the others is just a step on the path towards replacing them if that's your preferred path.

This is to make your maintainership easier by reducing your support responsibilites and increasing your support team.
Many good programmers on d.o. are receptive to constructive criticism, and even more receptive to assistance from people with a track record who have worked on the same problems they faced!

As an example, we found that insert_block.module had been overtaken by reptag.module and with little fuss it is now deprecated and suggesting that as a more general-case solution. (it would appear that block_filter.module is now in need of the same treatment :-)

As ever, no-one is required to co-operate, and if your offer of alliance is rejected, it won't help to press the point. The duplicated lists compiled on g.d.o. are just references compiled by outside observers trying to make things easier for users. We don't want to have to write and maintain more module comparison charts to fill in the gaps.

Please take these suggestions in the spirit they are offered!