The configuration variable that controls this behavior ($wgPingback) will default to false (that is: don't share data). The web installer will display a checkbox for toggling this feature on and off, and it will be checked by default (that is: *do* share data). This ensures (I hope) that no one feels surprised or violated.
Sounds sane, as long as the installer makes it quite clear what it is going to be doing.
- The chosen database backend (e.g., "mysql", "sqlite")
Would love to have DB version information as well (getServerVersion)
Lua version?
Please chime in if you have any thoughts about this. :)
Many of the wikis I install are on intranets behind heavy firewalls. I'd be happy to submit this data however if there were an optional method to do so.
Since we have a running debate about services -vs- all-in-one installs -vs- requiring binary modules, it would be nice to include data points reflective of these three different hosting scenarios (multiple server, single server, shared host w/ no ability to install new modules). To start the discussion, I might suggest returning a boolean yes/no whether parsoid is configured (as a proxy for "can services be installed"), a boolean yes/no for whether mysql is on the same server as php (as a proxy for "multiple server install"), and a boolean for whether the lua sandbox extension is installed (as an imperfect proxy for whether binary modules can be installed), and perhaps a variable reflecting the tidy configuration (enabled? if enabled, using the tidy extension or standalone tidy?) as another insight on binary modules (weakened because i think the tidy extension is bundled by default with PHP 5). --scott
On Fri, Jul 22, 2016 at 10:29 AM, Greg Sabino Mullane greg@endpoint.com wrote:
The configuration variable that controls this behavior ($wgPingback) will default to false (that is: don't share data). The web installer will display a checkbox for toggling this feature on and off, and it will be checked by default (that is: *do* share data). This ensures (I hope) that no one feels surprised or violated.
Sounds sane, as long as the installer makes it quite clear what it is going to be doing.
- The chosen database backend (e.g., "mysql", "sqlite")
Would love to have DB version information as well (getServerVersion)
Lua version?
Please chime in if you have any thoughts about this. :)
Many of the wikis I install are on intranets behind heavy firewalls. I'd be happy to submit this data however if there were an optional method to do so.
-- Greg Sabino Mullane greg@endpoint.com End Point Corporation PGP Key: 0x14964AC8
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I went ahead and wrote a bare minimum page for the setting:
https://www.mediawiki.org/wiki/Manual:$wgPingback
We should greatly expand this. Namely, it needs to list *what* we collect, *why* we collect it, *who* gets to see the data, etc. The talkpage seems like the best place to collect suggestions for new items to add to the pingback.
This page needs to be kept up to date *any* time a new metric is added to the collection. It's going to be one of the first places people check when they see the variable so it needs to be descriptive :)
-Chad
On Fri, Jul 22, 2016 at 9:31 AM C. Scott Ananian cananian@wikimedia.org wrote:
Since we have a running debate about services -vs- all-in-one installs -vs- requiring binary modules, it would be nice to include data points reflective of these three different hosting scenarios (multiple server, single server, shared host w/ no ability to install new modules). To start the discussion, I might suggest returning a boolean yes/no whether parsoid is configured (as a proxy for "can services be installed"), a boolean yes/no for whether mysql is on the same server as php (as a proxy for "multiple server install"), and a boolean for whether the lua sandbox extension is installed (as an imperfect proxy for whether binary modules can be installed), and perhaps a variable reflecting the tidy configuration (enabled? if enabled, using the tidy extension or standalone tidy?) as another insight on binary modules (weakened because i think the tidy extension is bundled by default with PHP 5). --scott
On Fri, Jul 22, 2016 at 10:29 AM, Greg Sabino Mullane greg@endpoint.com wrote:
The configuration variable that controls this behavior ($wgPingback)
will
default to false (that is: don't share data). The web installer will display a checkbox for toggling this feature on and off, and it will be checked by default (that is: *do* share data). This ensures (I hope)
that
no one feels surprised or violated.
Sounds sane, as long as the installer makes it quite clear what it is
going
to be doing.
- The chosen database backend (e.g., "mysql", "sqlite")
Would love to have DB version information as well (getServerVersion)
Lua version?
Please chime in if you have any thoughts about this. :)
Many of the wikis I install are on intranets behind heavy firewalls. I'd be happy to submit this data however if there were an optional method to do so.
-- Greg Sabino Mullane greg@endpoint.com End Point Corporation PGP Key: 0x14964AC8
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- (http://cscott.net) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi,
On 07/22/2016 10:05 AM, Chad wrote:
I went ahead and wrote a bare minimum page for the setting:
https://www.mediawiki.org/wiki/Manual:$wgPingback
We should greatly expand this. Namely, it needs to list *what* we collect, *why* we collect it, *who* gets to see the data, etc. The talkpage seems like the best place to collect suggestions for new items to add to the pingback.
This page needs to be kept up to date *any* time a new metric is added to the collection. It's going to be one of the first places people check when they see the variable so it needs to be descriptive :)
Going along with this, I wrote https://gerrit.wikimedia.org/r/#/c/300661/ which shows the exact data that MediaWiki will send during the install process.
-- Legoktm
Le 22/07/2016 à 23:34, Legoktm a écrit :
Going along with this, I wrote https://gerrit.wikimedia.org/r/#/c/300661/ which shows the exact data that MediaWiki will send during the install process.
-- Legoktm
I was going to suggest it and I am not surprised you already came up with a patch for it :-}
That is similar to sending back a stacktrace when an Android App crash or on Mac OS. Maybe later we will have a stacktrace beacon! :}
On Fri, Jul 22, 2016 at 2:35 PM Legoktm legoktm.wikipedia@gmail.com wrote:
Hi,
On 07/22/2016 10:05 AM, Chad wrote:
I went ahead and wrote a bare minimum page for the setting:
https://www.mediawiki.org/wiki/Manual:$wgPingback
We should greatly expand this. Namely, it needs to list *what* we
collect,
*why* we collect it, *who* gets to see the data, etc. The talkpage seems like the best place to collect suggestions for new items to add to the pingback.
This page needs to be kept up to date *any* time a new metric is added to the collection. It's going to be one of the first places people check when they see the variable so it needs to be descriptive :)
Going along with this, I wrote https://gerrit.wikimedia.org/r/#/c/300661/ which shows the exact data that MediaWiki will send during the install process.
Reviewed and merged. Great addition to this!
-Chad
wikitech-l@lists.wikimedia.org