I'd strongly prefer not to have Phacility user tracking in the upstream.

This kind of change runs counter to principles that I'd like to uphold in the upstream, and which I believe (but can not prove) give us an advantage in the long term, and which are also personally important to me. I can spend some time trying to articulate these principles better if you aren't sure why I feel this way and you'd like to understand where I'm coming from, but they are probably something like this:

• "Phabricator is by and for engineeers": To me, seeing marketing tracking in the README erodes the claim that this is an engineering project.
• "You can take your data and run Phabricator yourself": I think blurring the line between Phabricator/Phacility in the codebase erodes this claim. Although this specific change doesn't meaningfully harm anyone's ability to run Phabricator on their own, I think it does blur the line, and I'd like to avoid blurring the line even when those changes are harmless. I'm somewhat uncomfortable with even changes like D16861, per my joke in the title.
• "Engineering is king": We make changes because they have strong product and technical justifications and solve real problems.

This line-blurring is both an external issue (it erodes our claims about Phabricator being standalone) and an internal issue (it erodes my confidence that the company is one that I'll be happy to work at in the future).

Imagine it's a few years from now, and I'm the VP of Engineering. The VP of Marketing comes to me and asks for a change in the upstream to add some tracking or do something else which does not benefit (and perhaps slightly harms) end users -- suppose we're going to make the upstream phone home on its own and make the feature opt-out, so it's on by default.

I want her to face a very, very high barrier to upstream changes. If our future VP of Engineering is beholden to our future VP of Marketing, it's not a position I want, and I think this kind of change puts us on a pathway where Engineering is subservient to Marketing: it begins to establish a precedent that we'll make upstream changes with no engineering justification.

It's possible that there are only two possible futures for Phacility: one where the company dies, and one where marketing is king. That is, it is possible that staying on a path where engineering is king will kill the company.

However, I don't want to lead engineering at a company where marketing is king, so the two (death and becoming a marketing company) are equivalent to me, and I would feel like I had failed in either case. I am only interested in holding an engineering position at a future Phacility where engineering is still king.

If this kind of change isn't important to you -- you're OK with either marketing or engineering leading, and just want the company to not die -- we should talk separately about how we can change things so that our goals are in better alignment.

Here, can you convince me that these sources are really valuable for us to track? What kind of decision would we make based on this data? How might not having this data lead us down a blind alley to a bad decision? If you can, is this the only thing we could track to make that good decision, or avoid the bad one?

Offhand:

• I can't really come up with any ways this data is useful in informing decisions.
• If there is some way that it's useful, it seems like we might be able to track referral traffic from GitHub instead of this? It seems like that's probably a better signal?

Basically, I'd like you to describe a root problem, even a hypothetical one, that this tracking solves or could solve.