[andrewaylett]

Because the known system effect means that the more arbitrary developers engage with them, the more likely it is that at least some of them will drive corporate adoption and, by extension, sales.

Tailscale put it well: https://tailscale.com/blog/free-plan

> increased word-of-mouth from free plans sells the more valuable corporate plans

[ninkendo]

Why is it a given that GitHub slowing me down by making me engaged with the site more, will make me spread more word of mouth/etc? Everyone in this thread is just assuming a link here, but I don’t see it at all.

GH annoys the shit of me by making me click more shit to get my job done, it “increases engagement”, and then… what exactly? My annoyance is supposed to lead to me… thinking about GitHub more? And thus I’ll pressure my org to use it?

This makes no sense. I hate engagement-based metrics as much as the next person but I’m not sure MS is as brain dead as to intentionally make the UX worse, to make engagement higher, and assuming that will somehow increase sales. There’s no link here.

[berkes]

I think you misunderstand me.

I'm not saying MSFT is intentionally frustrating you to increase sales.

But that, where engagement drives sales, your frustrations are disregarded.

They are different links.

MSFT could easily build a toggle to disable PRs (default, enable PRs). They have these toggles for all other features already.

They don' build this, because, as many other commentors point out, the few people that would benefit from such a toggle, don't outweigh the amount of engagement, data, and usage it generates.

I merely take that a step further: there are quite certainly many features disregarded or not even conceived that would save a (small) group immense effort. Simply because MSFT has done the excel-thingies and knows that features that make people visit GitHub less often, are not positive to their sales.

[ninkendo]

> They don' build this, because, as many other commentors point out, the few people that would benefit from such a toggle, don't outweigh the amount of engagement, data, and usage it generates.

That makes no sense. Say I'm an open source project maintainer who doesn't want PR's in my repo. I have to continually log in to GitHub to check the PR tab and close all active PR's (or as others have pointed out, use a bot to do this, but that's beside the point: The discussion is about why this isn't a built-in feature.)

What value does Microsoft get out of the "data" generated by me having to continually log in and close PR's? "Yup, people who don't want PR's on github log in a lot to close them". Why is that valuable? We keep talking about engagement as a thing but nobody's explaining why it matters at all for MS. "Engaging" me by forcing me to open up the website to do mundane stuff doesn't move any of MS's needles. "Usage" goes up only because I have to keep doing this mundane shit.

Here's a VASTLY more likely reason why MS doesn't want to make it easy to disable PR's: Lock-in. Microsoft wants to encourage users to use GitHub for everything involved in software engineering, end-to-end. Because if you do so, leaving GitHub becomes a lot harder, because GitHub has your PR history, your issue history, and is hosting your wiki, etc etc. This is not the same thing as "engagement", it already has a term, and that term is "lock-in". (Apropos: I consider PR discussions to be indispensably valuable in finding out why some particular line of code looks like it does: Finding the PR that introduced it and looking at the discussion is a great way to find out the motivation of the original author.)

MS does not like users that purely use GitHub as a mirror and don't use any of the GH-specific features, because those users can trivially migrate their code to another hosting provider if MS ever decides to do something silly like charge them.

Engagement makes no sense whatsoever as a motivation to not let users disable PR's. Lock-in makes perfect sense.