This is similar to #1273344: Establish heuristics for core feature evaluation, but for contrib modules too - not just core...

Problem/Motivation

Each time there's a debate over which setting for a certain feature of a module should be on/off by default and maintainers need to decide, we usually have pointless/endless debates of what *seems* more appropriate and guesses of what most users prefer.

Such examples are:

A nice way to make everyone happy when it comes to default settings is to have the last settings be remembered (#1370498: Remember last selected filter in "Available updates" page. for example), but that is not always applicable. This method also fails each time a new installation is set up: there's no way for Drupal to "know" what you want based on previous installations.

Sure, we have Features & Drush Make + installation profiles, but I'll argue that these are definitely not targeted towards the average user.

Another way to make a relatively sane decision is to have a poll over such matters (#42232: Help Maintainers Manage Issue Priority by Encouraging Voting / #682254: Allow multi-dimensional rating of issue comments), but that assumes that most users are regularly following what happens in d.o and/or their most-used projects' issue queues. In other words, it assumes that:

a) people would know that there's a poll going on
b) they care enough to bother voting

By methodically taking a look at the usage stats of various projects in d.o (a habit I developed) I can say that it's safe to conclude that that is not the case. I believe that the majority of users is involved to a level where they simply download and use a stable version off a module and if it causes them no issues, they stick with it and never upgrade unless they have to upgrade their sites to a next major release of Drupal.

Proposed resolution

How about we provided the means for project maintainers to collect anonymous stats of their modules' settings? This would help them eventually tweak their modules' default settings to provide a less-clicking-around, works-out-of-the-box UX.

Remaining tasks

...

User interface changes

...

API changes

???

Comments

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
CreditAttribution: klonos commented

...related issues:

#1036780: Drupal.org should collect stats on enabled sub-modules and core modules
#1274766: Collect stats on enabled sub-modules, not just projects
#1273344: Establish heuristics for core feature evaluation

dww’s picture

dww
we/he/they
CreditAttribution: dww commented
Version: 7.x-2.x-dev » 6.x-1.x-dev

-1 to this. Even just getting #1036780: Drupal.org should collect stats on enabled sub-modules and core modules working is going to be a bit tricky while keeping the updates.d.o site performant. That site gets about 350 million hits every month, for a total of about 5 TB of data transfer monthly. #1036780 is going to make that bandwidth significantly worse. Doing something like this where we're trying to send arbitrary data about all kinds of settings and the like is going to make it even worse. Plus, I can't think of any generic way to do this. There'd have to be some funky new hook in core where modules can advertise themselves to whatever is sending the data back to d.o. This seems like a huge mess for questionable value.

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
CreditAttribution: klonos commented

Well, I do understand the performance/traffic concern in this, but the other alternative to getting some useful, non-biased feedback on what "most users" do would be to provide polls for such things. If we went that way, then how do we make sure that users are aware of these polls and that they'll bother to participate? Relying on results from people that simply happened to notice that there was poll going on or from only those that bothered to participate cannot count as a reliable survey of what most people actually prefer. If we don't do either, then we'll just keep debating pointlessly over such matters each time they come up.

Besides, the two examples provided in the issue's summary (Overlay & WYSIWYG) and the debates going on over them alone prove that this would not be of "questionable value" at all IMO. Do a search with the terms "should be by default" in the issue queue as a test ;)

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
CreditAttribution: klonos commented

...now that I think of it, I like the irony of the fact that we don't provide a setting for this so we could actually collect data on how many people opt-in for it. Count that as an example too ;)

wizonesolutions’s picture

wizonesolutions
he/him
Primary language English
Location Norway
CreditAttribution: wizonesolutions commented

I'm interested in this too. In my case, I'm considering adding Options Element integration. I would love to see how many turn on Fill PDF and Options Element together, for example, so I could decide if I wanted to make a hard dependency out of it.

Info on other settings would be great too.

I don't think drupal.org necessarily has to host this. If there was at least an API module to do this, perhaps in core (integrate my module with it) and something to install server-side...kind of a recipe...that could be a start.

If it worked well in the wild, perhaps that would provide justification for d.o to adopt it formally. I would be willing to help test such a solution and integrate it into one of my modules.

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
CreditAttribution: klonos commented

Though providing an option to host the stat gathering to 3rd party servers would indeed take the traffic burden off of d.o, it would OTOH introduce implications such as trusting these 3rd party servers and presenting (perhaps intimidating) respective privacy policies to end users. Besides, how would then these stats be aggregated back to d.o in order for things such as #1627676: Display stats on enabled components (e.g. modules included in a project) to happen?

sreynen’s picture

sreynen CreditAttribution: sreynen commented

For me, having a data-driven feedback loop available on Drupal.org would significantly increase the value of hosting projects here. I would love to be able to collect more specific usage data for my projects, to make more informed decisions about how to improve them. I'm already thinking about splitting out different pieces of functionality into separate modules so I can get more data out of #1274766: Collect stats on enabled sub-modules, not just projects. But that can only go so far before it becomes more annoying than helpful to end users.

That doesn't really help with the bandwidth concern, but hopefully it makes the potential value clearer.

Robin Millette’s picture

Robin Millette CreditAttribution: Robin Millette commented

I would also like to see dev/prod stats. Is my module used by 1000 sites, but 800 are just dev sites?

See also #1537198: Add a Production/Development Toggle To Core

apaderno’s picture

apaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
CreditAttribution: apaderno commented
Status: Active » Closed (outdated)

I am closing this feature request, as Drupal 6 is no longer supported. Please re-open it if you would want the feature implemented in the Drupal 7 version of the module.