> What’s your work email address? I will set up a filter which forwards each unwanted email to you. I will prepare a web page where you can unsubscribe to them 25 issues at a time.
This is akin to getting mad at the McDonalds cashier for informing you of some corporate McDonald policy.
Anger directed at the customer support, who generally doesn't have the authority to make changes (especially at the scale desired), is misplaced and doesn't help anyone.
The whole situation is frustrating, but lashing out at some random customer support agent that happened to get your ticket makes me hope, in a similarly petty way, that they don't resolve this issue until you manually unsubscribe from all the notifications.
This is a joke made in an attempt to engender some much needed empathy from the team on the issue. Naturally the tech can refrain from sharing.
GitHub is supposedly a tech company, and supposedly works for developers. I would expect better from them than from McDonald's. You can expect better from me, that's for sure.
>I would expect better from them than from McDonald's.
You must have entirely missed my point because my point has nothing to do with /your/ expectations of /x/ company.
My point is that you should not berate and threaten the customer service representative for issues they both didn't cause and do not have the authority to fix. They are simply doing their job which is: See ticket, attempt to resolve, escalate if they can't.
Did you think this particular representative was the person who coded the entire notification system and is the sole person deciding whether or not your proposed solution is implemented? If not, why are you threatening (sorry, "joking")them as if they were?
You can be angry with GitHub without taking it out on the person who is simply trying to do their job as a front-line customer service representative. If I had to guess, you must not have ever had to work in a low-level customer-facing position.
You and I seem to have different standards for "taking it out" on or "berating" someone. Even if the "threat" is taken at face value, the possibility of receiving a few unwanted emails per week is hardly a harrowing scenario. If you feel otherwise, then consider that is exactly what GitHub is doing to me.
It was a joke. Tamper it down a bit. I get that you've suffered in a customer-facing position before, but this is not a measured response.
> Even if the "threat" is taken at face value, the possibility of receiving a few unwanted emails per week is hardly a harrowing scenario. If you feel otherwise, then consider that is exactly what GitHub is doing to me.
You literally say that you would inflict on a single person within a huge organization what you wrote a whole blog post and multiple emails to avoid personally. I get it was a joke, but I'm guessing you can see the irony in that.
Suggesting to somebody else that you’ll inflict something on them that you did not appreciate having been done to you is basically a textbook violation of the golden rule.
If you think what is happening to you is bad, the suggestion that you’ll inflict the behavior on another is also bad. If you don’t think it’s bad to do this to the support rep, the blog post is a bit of an odd move.
Sure, but it also makes the point where you perhaps should not send that, right?
If you think something is harmful or bad then perhaps don't say you're going to do it to others. Especially when the person is a individual that often does not have control of the policies that they have to represent professionally in their work.
I don't understand your argument. The joke is meant to be illustrative of the problem, to inspire empathy in an otherwise unempathetic party. This requires an understanding of the unpleasantness of the situation. If I did not communicate that unpleasantness, then the desired effect is not achieved.
We're getting into some philosophical areas here (and these are very deep waters for me, so forgive me if I misstep), but it sounds to me like you think the only way to get empathy is to put the other party to get into the same theoretical situation. I think there are other ways to get others to understand you and get empathy. I don't think you need to make someone else experience the unpleasantness to make them feel empathy, you can communicate unpleasantness without (in this case jokingly) threatening to inflict it.
In this case the person you are talking to is probably not at all responsible for the original problem, so I think the need to consider both the human and the company you are talking to is larger than when dealing with a single person.
You assume the support team lacks empathy. More likely they simply lack the power to do anything more than they already have. I doubt that the support folks have raw access to the database tables for your account and the swaywm repos, for example. In light of that, I agree with the other commenters who say that your "joke" was abusive toward the support rep.
> I would expect better from them than from McDonald's.
I would expect better from McDonald's. They empower just about anyone in a restaurant to do just about anything to resolve a problem, short of giving you a refund greater than 100% of what you paid.
Couldn't you write a script to manually go through the pages and click the 'unsubscribe' button? It might be less time/effort on the author's part then attempting to negotiate with a multi-national conglomerate who will take minimum 1 quarter to ship a 'Unsubscribe All' button.
There's a long tail in many products where non-happy-path flows are undoubtedly terrible. But if product teams prioritized addressing that long tail, what would happen to the delayed mainstream features? How would the userbase, in aggregate, feel about such a prioritization? It's disappointing when they say to expect no reply, but it seems like both a practical and efficient outcome. They're an autonomous organization and you can't step in and say "put this at the top of the backlog".
The problem with this approach is that it risks one's account being hit by some black box algorithm for detecting abuse, and then spending another few weeks trying to explain to another customer service rep that a) your account hasn't been hacked, b) you are not abusing their service in spirit, even if in action, c) you do not want your account settings reverted because these changes were made by you and then d) no, please do not ban me from the service permanently.
All that apart from the fact that it shouldn't be necessary!
Selenium is really cool for that kind of thing, if the webapp is so backwards and broken that you really just need to get into the "click button on webpage" level.
Mostly though, I strongly suspect this could have been easily solved with using dev tools and inspecting network requests and a bit of grep/sed/awk/curl/while read line loops. Easier to write a snarky blog post, I suppose.
My reading of this is that the only reason OP can't unsubscribe in bulk is because there's currently a bug that affects the two repositories in question.
Yeah, that sucks, and I'm not surprised the customer support agent can't do a bulk unsubscribe either; sharing the same API is normally a good thing.
I'm not sure expecting a 13 day turnaround on a bug is that reasonable.
Can't OP just set up an email filter to handle this for a few weeks until it's fixed?
If they said they'd work on it, and asked me to wait patiently, then yes, I would definitely do that. Instead, they mischaracterized the problem, offered wrong advice and conclusions, and ultimately they gave this:
> We have forwarded your ticket to the Product team who reads and evaluates all feedback, however we cannot guarantee a response to every submission.
Are they working on it? Who knows. Will they maintain the line of communication? Probably not. Will I still get these emails for some unknown amount of time? Yes.
That's a fairly routine response for consumer support, unless you have a big expensive support contract I'm not sure why you would expect more than "We're tracking it, thanks for the report".
As to your problem:
Why not mute the repositories and use a custom filter on your GitHub notification inbox which you can review every few days to see direct mentions in those repos only?
I think it's reasonable to expect a better response. This is a matter of their system behaving incorrectly - not of, say, some conspicuously absent feature which I would like to have. It is their responsibility to ensure that their email is not sending unwanted spam to someone else. As the founder of a company which deals with similar problems, I find it entirely reasonable to impose upon myself a responsibility to expediently address problems my software creates for others, and to maintain a clear line of communication with the affected party while the issue is addressed. If GitHub doesn't want to do that, then fine, that's their perogative, but I think their reputation deserves a hit for making that choice.
As for the problem itself, I'm sure I can think up any number of workarounds, and I'm likely to apply one at some point. But that doesn't change the fact that I should not have to.
I had a very similar issue when I left my previous job. For some reason I was subscribed to all their repositories (even private ones) and I still kept getting notifications. Luckily it wasn't more than 20 pages, but I had to write some code to automate navigating through these pages and unsubscribing from everything.
This is akin to getting mad at the McDonalds cashier for informing you of some corporate McDonald policy.
Anger directed at the customer support, who generally doesn't have the authority to make changes (especially at the scale desired), is misplaced and doesn't help anyone.
The whole situation is frustrating, but lashing out at some random customer support agent that happened to get your ticket makes me hope, in a similarly petty way, that they don't resolve this issue until you manually unsubscribe from all the notifications.