I dont like that the box "share data" is auto-checked. It's easily overlooked, especially if you just want to set up a quick test-wiki, for which you certainly dont want to share data.
Document persistent wiki id
- How it is generated
- How it is used
- What is the purpose of it
- How to reset it, and what the effects of doing so will be
Commit message for this feature
Table should cover everything now
Quoting Ori's commit message:
- Add option for sharing info about this MediaWiki install via pingback When $wgPingback is true, MediaWiki will periodically ping https://www.mediawiki.org/beacon with basic information about the local MediaWiki installation. This data includes, for example, the type of system, PHP version, and chosen database backend.
- The pingback is sent via a deferred (post-send) update whenever $wgVersion changes, using the updatelog table to ensure we don't send duplicate pingbacks. A database lock ensures only one thread attempts to send the pingback, and a cache key throttles attempts to no more than once per hour.
- $wgPingback is false by default. The web installer has a checkbox for controlling this option, and it is checked by default. This nudges new installs to turn on pingbacks, but does not sneak this decision past sysops of existing installs.
Do we need to incorporate this information in the page? How/where do we document the data we plan to collect (other than in the code)?
I added a table indicating what data would be collected, and some examples of what the data might be.
It should be more than just examples....I think it's crucial that we clearly document every piece of data that's included, and when we add a new piece of data it must be added here.
Thanks for bringing this up @^demon. On first read, I thought "it looks like @Legoktm has a really complete set of examples". However, it's possible to accidentally create a monster here. For example, the HTTP User-agent field has a mess of layered ad hoc information, and has been prone to years of engineering and analytics abuse. ^demon, when you emphasize "every piece of data", do you mean that each possible value for each field should be enumerated?
I don't think that's even possible. For example,
php_uname( 'r' ) on my system returns "4.6.6-300.fc24.x86_64", which changes on every kernel update.
Nah, not ever possibly value, just every type of data (with an example or two of possible values)....like Lego says, it's impossible to be exhaustive here. And yeah, it's up to date now, I was mainly making sure they're not forgotten in the future. See
OK, I think the current table should cover everything. Please edit the wiki page if something is missing :)
Rationale for data sent
Added rationales for everything.
I added a table indicating the data sent and why we wanted those data points. I couldn't come up with reasons for two of the fields, so it would be helpful if someone else could fill those in.
Location of and access to pinged back data
Added to wiki page
I guess the page should also state were the collected information is stored and if it is publicly accessible or not.
Updated the page with the basic info that I know of...hope that's helpful.
It indeed is. Thanks a lot!
Enabled this feature on one wiki a couple of weeks ago so there should already be some data available. :)