We need to communicate to Drupal site owners that it is in their best interest to turn on the statistics collection feature in the drupal.module. Once we have statistics we can focus resources on the most enabled modules, ...etc.

So, here is a patch to urge the user to turn this feature on.

This is for new sites only, and therefore we need to have a front page item on this new feature, as well as a blurp on it in the 4.7.2 release as well, so existing sites may enable it.

CommentFileSizeAuthor
#19 drupal-module-welcome.patch1.05 KBnedjo
#18 drupal-statistics.patch636 bytesdries
drupal.module_3.patch1.28 KBkbahey

Comments

dries’s picture

dries commented

I'd be happy to commit this, if some people could proof-read this.

Maybe we should spifically mention that we'll use the data to rate Drupal themes and modules on the Drupal website? It fixes a problem many people care about. Being explicit about it, might help.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

Khalid's text makes sense to me when I compare it to the admin/settings/drupal page. Mentioning that the default xmlrpc server setting might be helpful, but maybe it's unnecessary.

I think that very few people actually read that initial page. A place to advertise this that people look at more frequently is on admin/modules page.

From admin/modules description of the "drupal" module:
"Lets you register your site with a central server and improve ranking of Drupal projects by posting information on your installed modules and themes; also enables users to log in using a Drupal ID."

That text seems a little rough given that it really is just "providing feedback about the installed modules and themes" and not just "improving ranking". Also, that text ignores the sharing of personal and site specific information (nodes, users, slogan, mission, email) which may be a concern.

How about:
"Lets you register your site with a central server to provide usage information from your site which will help improve the Drupal project; also enables users to log in using a Drupal ID".

That way the explanation of specific bits that are sent back is left to the settings page and the concept of "help improve the Drupal project" is generalized since really the data will be used in a variety of ways.

If people agree on the text a patch seems trivial.

dries’s picture

dries commented

If we can sneak in a short blurb on the modules page, that would be cool too. Keep it coming! :)

robert castelo’s picture

robert castelo commented

Is this feature available only on sites that also allow "users log in using a Drupal ID"?

That might put a lot of admins off.

dries’s picture

dries commented

It's not.

Crell’s picture

Crell commented

That should be better stated, then. I had to go and enable the module and check its settings page to be sure, because just from the description on the module page it makes it sound like the distributed login thing is on by default, or has to be on.

I'm fine with my Drupal phoning home to report statistics on modules. I do not want to use Drupal.org login accounts. It needs to be made very clear that those two features are separate from each other, and that we're only really pushing for the former.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

Crell - you want that to be clear on the welcome page or the admin/modules page or both?

Do you have a suggested blurb to do it?

Wordsmithing is hard -especially in such confined areas. Your input is definitely appreciated.

pwolanin’s picture

pwolanin commented

After seeing the initial post in this discussion I went to enable the drupal module on our site. The point where I was concerned was at /admin/modules. From the description there is seemd that enabling the module would allow remote logins.

RayZ’s picture

RayZ commented

Maybe "provides options for ..." as opposed to "enables ...", to make it clear that turning on the module is not the same as turning on distributed login stuff (which I also mistakenly assumed)?

dries’s picture

dries commented

Now that's team work here. ;) Maybe someone should try to wrap up the current suggestions, make a patch, and share a screenshot or two? That would help us move in the proper direction.

robert castelo’s picture

robert castelo commented

Module description:

OLD

Lets you register your site with a central server and improve ranking of Drupal projects by posting information on your installed modules and themes; also enables users to log in using a Drupal ID.

SUGGESTED

Provides options: 1. Send your site statistics to drupal.org (used to rate popularity of modules and themes). 2. Enable users to log in using a Drupal ID.

Crell’s picture

Crell commented

My suggestion for the module text would be:

Allows your site to send [anonymous] statistics to Drupal.org to help rate the popularity of modules and themes, and optionally permit users to log in with a Drupal.org user account.

(I don't now if the stats are actually anonymous. Include that word or not as appropriate.)

Of course, we could also just break it out into two modules, thus solving the problem. :-)

kbahey’s picture

kbahey commented

I like Crell's text above this comment.

The statistics are not anonymous though. We send email address and other info.

Best approach is to use a modification of Crell's text that has a hyperlink to a big honking Drupal.org page that describe exactly what is collected and how it is used, what the benefits are to the users, and what the privacy implications are. We can then link the same page from the initial front page of a new Drupal site as well.

pwolanin’s picture

pwolanin commented

I think users from any other similarly enable Drupal site could log in (right?). So I like the gist of the above suggestion, but it should probably say:

Allows your site to send statistics to Drupal.org to help rate the popularity of modules and themes, and optionally permit users to log in using their usernames from other Drupal-powered sites.

kbahey’s picture

kbahey commented

Regarding the anonymity/privacy thing.

We can make it such as sites are not identifiable at all. If we do not collect email addresses, do not log IP addresses, and send a "site ID" that is just an md5sum of the site's $base_url, then there are no privacy implications, since the sites are not individually identifiable. We can filter out all the sites that have md5('http://localhost') of course.

In this case, we may even think of turning on this feature by default (has its drawbacks), or by a simple Yes/No question when the user first visits /admin/settings.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Humungous, flaming, blinking, neon orange -1 to having this enabled by default regardless of how private we make the data.

a) because the last thing we want to be known for is an open source software that comes bundled with opt-out spyware :P
b) the opt-in imho gives more useful statistics because the results aren't skewed by all the localhost/dev installs out there (you pointed out a workaround for the former though)
c) finally, it's giving us data about sites whose administrators enable it because they make the conscious decision to try and help Drupal. When it comes time to use these statistics to shape Drupal's future direction, those are the people I'm most interested in catering to.

kbahey’s picture

kbahey commented

My eyes are hurting from that mental image ... I have sinned your grace ...

Seriously ...

How about this:

- Create a Select Box with a Select-One/Yes/No option in /admin/settings

- Make it a required setting, with NO DEFAULT (of course it is off, until the admin visits /admin/settings, which is something that is guaranteed to be done, unless this is a test site or so)

- Answering Yes enables the drupal module with the module data and statistics info only (not the authentication of course)

- This way, the admin has to make a decision, and there is nothing defaulted

- We have a link to the Drupal.org URL link (or help text with link to that) that explains this feature under that Yes/No

The value of this feature is so great. Not only will we know which modules are used, but it can give us an answer to the eternal mystery of "how many sites run Drupal". By defaulting to not enabling it, we lose much of that value.

My approach gives the site admin the means of making an informed decision, and we get an explicit yes or no that way.

dries’s picture

dries commented
StatusFileSize
new drupal-statistics.patch636 bytes

Here is a first patch based on the suggestions. It isn't a huge improvement compared to the old description. We should extend this patch.

* Maybe we should try to make its importance more clear on the settings page?

* Maybe we should add a block to the download pages at drupal.org, encouraging people to enable this features?

nedjo’s picture

nedjo
he/him/his
Primary language English
commented
StatusFileSize
new drupal-module-welcome.patch1.05 KB

This issue is related, http://drupal.org/node/66013, a patch to enable browsing of projects based on the data we receive at drupal.org.

Your suggestion Dries is an improvement. We might want to consider something brief in the welcome message. Here's a draft.

dries’s picture

dries commented

Nedjo, thanks. Unfortunately, your patch doesn't apply. Maybe you can merge both patches? I think they are good to go. We can refine them later on.

drumm’s picture

drumm
he/him
Location NY, US
commented
Status: Needs review » Needs work
catch’s picture

catch
he/him
Primary language English
commented
Version: x.y.z » 6.x-dev
Status: Needs work » Closed (won't fix)

Marking as won't fix given update status in core.