Hacker News Re-Imagined

We lost 54k GitHub stars

  • 1883 points
  • 2 months ago

  • @todsacerdoti
  • Created a post

We lost 54k GitHub stars


@HeavyStorm 2 months

Replying to @todsacerdoti 🎙

Did I just read a pages-long whining, blaming the tool for the mistake?

Sure, github could help Httpie, but that would be unexpected. More than killing your repo because you're not paying attention.

Reply


@werdnapk 2 months

This reminds me of an app of mine that was a top 20 paid app 8+ years ago in the Apple app store. To try and gain more users, I decided I'd try a little test and make the app free for a short amount of time. What I did not realize was that changing the app from paid to free would completely remove my app from the top 20 charts and the free app ended up at the bottom of the free charts.

The app gained positions pretty fast in the free charts, but it never got close to what it was before. Biggest mistake I could have made in hindsight and there was nothing I could do about it. This was my first app in the app store, so I hand no experience with how things worked.

Reply


@carvking 2 months

Github should really just do the right thing.

Reply


@actually_a_dog 2 months

Meta: why is the word "how" omitted from the title? I've seen this a couple of times recently and I don't understand why people are omitting words like "how" and "why." The only thing I see in the guidelines is about omitting "gratuitous" numbers and adjectives, neither of which "how" and "why" are.

Reply


@jzer0cool 2 months

I sympathize with you. I think it is best policy they do not give you back the stars, because I can see a wave of potential misuse which could also open up vulnerabilities exploiting this practice. Does anyone use "stars" as some form of credibility to the project in terms of security?

Given your reputation, I find you will get back your stars again and maybe even higher than before. Or, at least, it shouldn't be that hard :).

With that said, I am glad to have come across this site. Sure seems to beat postman :)

Reply


@adenozine 2 months

Are y’all out here really stressing over GitHub stars?

What in the world…

Write some unit tests, put a benchmark together, show me example commands to get started, ANYTHING substantial will mean much more to potential new users than seeing how many GitHub stars you have.

Just my two cents, I think this is WAY off the mark.

Reply


@auggierose 2 months

The real problem is: Why are GitHub stars so important if httpie is so great?

Because people cannot judge for themselves if something is great or not, they always need proxies. It would be cool if we could somehow fix THAT.

Reply


@vladsanchez 2 months

I just starred HTTPIE again.

I feel their pain and while I don't claim to be perfect, this was was self-inflicted as it was clearly stated in Github dialog warning:

"You will permanently loose all stars and watchers of this repository"

Please don't blame Github for EndUser fault. People are click-happy and don't read. I'm happy they're able to restore their reputation and followers, not because of pity but because their product value and reputation.

Congrats HTTPIE!

Reply


@caymanjim 2 months

On the bright side, I had no idea this existed, and now I'm going to use it quite a bit. And evangelize it to coworkers, who probably also don't know it exists, or one of them would have used it during a pairing session. I doubt they'll get back to 54k stars (and really, who cares about stars?), but this will probably lead to a lot more new users.

Reply


@WesolyKubeczek 2 months

Okay. I just went in and double checked.

600+ comments bashing Github for not having prevented this action. Meanwhile, Github:

1) has this action in the "danger zone", literally the only UI element using RED COLOR; 2) has a warning banner on the dialog box that pops up when you click that button; 3) requires you to type in the name of the repository (which everyone copies and pastes anyway because they don’t get the point of this exercise)

So when you have all those things in place and still fly past all the defenses on an autopilot, you're not that bright to begin with and you should only blame yourself.

Meanwhile, there are 600 comments bashing Github for not putting in undo, or somesuch. The problem is, though, that this kind of carelessness that led to the repository losing its social stats doesn't stay with computers. It may very well carry over to other aspects of life, because an attitude is something ingrained way deeper than just using one computer program.

And then we have Youtube brimming with compilations of how cars don't stand a chance with trains. You would think that: 0) unambiguous warning road signs 1) red blinking lights 2) ringing bells 3) the train itself honking its horn for a couple miles before even approaching the crossing should be enough warning for the driver to move his/her ass off the track, and yet here we are.

So, yep, we may need to have better systems here and there, but being careful where it says "danger" should be a part of basic fucking competence at whatever it is you do. There are, shockingly, areas in life where an undo button doesn't exist. No, the fact that the other side didn't put safeguards in is not an excuse.

Reply


@jrockway 2 months

I think there are two types of destructive actions; destructive actions you do as a part of completing some other task, and destructive actions you do for compliance reasons.

I think the problem arises when product designers aren't sure which case their data deletion function is for.

If you dumped a bunch of social security numbers in your non-confidential data history and batch job system, you'd want to be able to permanently delete it as part of the incident response, to reduce the number of people that are exposed to data they shouldn't have access to.

But if you delete some lines of code from your text editor, they can just pop back into existence with the press of a key because you were probably just moving them around, or trying some buggy function without a piece of code you thought might be unnecessary to isolating the defect, etc. Editors clearly understand that you don't kill text out of an Emacs buffer to solve a compliance issue, so they keep it around even though you technically asked for it to be deleted. (Imagine how crazy it would be if deleting text in your editor deleted it from memory, the clipboard, version control, and your upstream VC server!)

In the case of this Github issue, there was clearly a fundamental misunderstanding. Github probably imagined the feature as a compliance type thing; get this stuff off the Internet as fast as possible at any cost necessary. Delete the list of people that even knew this thing existed! I could see why someone might want that. But what the user thought was that this was something they needed to do along the way to some other goal.

I have a feeling that people pick the compliance route more often than the "experimentation" route more often than not, not because they expect users to have actual compliance-type issues, but simply because it's easier. The net result is that users are trained to fear computers and fear experimentation, and that's a bad state we've put society in. This article is yet another victim of "if they said they were sure they wanted to delete it, we can just delete it". But it's actually pretty rare that people are sure.

Reply


@lmc 2 months

Sorry but losing stars by going from public to private is a small price to pay compared to going from private to public - what would you suggest be the guiding hand to prevent that kind of situation?

Reply


@julianlam 2 months

I sometimes wish those developers who have a lapse in sanity (left-pad, faker.js, etc.) would just do this to their most popular repos instead of poisoning the software supply chain.

Reply


@floor_ 2 months

I'm imagining this dev 'rm -rf / --no-preserve-root'ing and then blaming Linus.

Reply


@brentis 2 months

Came here to hopefully see GitHub came to the rescue through a friend of a friend on HN..

Unfortunately....not

Reply


@mattigames 2 months

Imagine this in any other profession, oh I put gold in the trash but the trash bin did not inform me that I was pouring such important thing there, or why the disposal vehicle not stopped me after detecting such valuable content?

Reply


@brian_herman 2 months

I gave them a star to help them out.

Reply


@varajelle 2 months

They already have more than 10k star now. So this mistake sure gave them some publicity.

Reply


@xyst 2 months

Seems a bit too extra for me. You are literally typing in the fully qualified repo name you want to make private:

Please type httpie/.github to confirm.

vs

Please type httpie/httpie to confirm.

At some point, we are going to have to stop coddling the users.

Reply


@NorwegianDude 2 months

"the biggest accidental community loss in open source history"

This was very much drama for very little.

Sure, some might follow the project to know about updates, but if people care that much if they are using the latest version of a CLI tool then they will certainly check it out again later.

Very very few people of those who followed the project cares, and close to nobody cares what percentile the project ranks as by number of stars on github. Heck, even the author cares so little that he let himself mess around mindlessly while ignoring warnings and forgetting what the project was called.

Github warned about the action, and even required written confirmation to make sure it was the correct repo. The author also makes a point about naming being different for orgs and private, but if the github repo had any meaning then the author must have been very aware of what the name of it was.

Sure, github can add even more roadblocks and confirmations for those who are very careless despite all the warnings, but I don't want that personally. It's a tradeoff, and I think github has the right balance.

But sure, the situation is mildly annoying for those few who actually care.

But the dumbest part: The complaint about github not using time to restore backups to correct the mistakes of the author. Sure, they probably could, but how will they decide if a user should get special treatment? If they start bringing out backups for some users then there will be a lot of others expecting and asking for the same thing, and more.

Some might say that it won't be a problem, but considering that the author is already expecting github to restore their backups for him because github restored their own backups only proves the problem.

Reply


@mcs_ 2 months

Hi team,

You got my star back. Good luck.

Reply


@redocecin 2 months

Good lessons learned, thanks for sharing!

Reply


@HigherPlain 2 months

I think people here are underestimating how difficult it is to implement is_deleted in a production system. Literally EVERY query has to be rewritten to reflect the new database schema. If it's not been implemented from the start then you have a considerable re-write, and usually this type of project will not be revenue generating.

Reply


@capdeck 2 months

Well, it is at the top of Hacker News. If everyone just goes to https://github.com/httpie/httpie and stars it again - we'll fix it in a jiffy!

Reply


@polote 2 months

That's crazy that a manual error by someone, for whatever reason, end up being an article blaming Github for all sort of reasons. And never accepting that the thing that really failed here is the user who performed the action.

Reply


@drewda 2 months

We use a nice SaaS service for time-tracking and invoicing called Harvest. I'm thinking of it, as when you go to delete an existing invoice, it has a similar prompt to this GitHub prompt. But instead of having you type in the org and repo name, you have to type in "YOLO" (as in, "you only live once" :)

Reply


@forty 2 months

What can you purchase with GitHub stars?

More seriously, why do they matter? Is it a prestige thing only or are there practical consequences to losing the stars?

Reply


@israrkhan 2 months

This hackernews post and other media coverage is getting the job done. Yesterday I saw they were at 3.2K stars, and right now they are 8.7 stars. I suspect this event will get them more users and will turn out better for them in the long run.

Reply


@kelnos 2 months

I agree that it would be more clear if the visibility-change dialog included some stats about the repo so you can confirm at a glance that it's the right one, but... it asks you to type the full name of the repo before it will allow you to proceed.

If you do a copy-paste of what it tells you to type, that's on you. The entire point of that box is to get you to think about what you are doing, and explicitly type out the name of the thing you want to change.

Perhaps I've interacted with GitHub's UX enough to be familiar, but when OP put up a side-by-side screenshot and asked, "A 54k-star question: Which one of these two dialogs is safe to confirm and which one deletes a 10-year-old community?" ... I looked at the two boxes, saw the repo it was asking to modify in both cases, and immediately knew the correct answer!

I get that the ideal is that every person who takes any kind of action knows what they are doing and never makes a mistake. I don't know if it's realistic to expect that outcome, but certainly that's the ideal. But how far should UX designers bend over backwards to cater to people who perform destructive actions without paying attention to what they're doing?

Reply


@mc4ndr3 2 months

What are some of the benefits of HTTPie over classic wget and cURL?

Does HTTPie support WebSockets?

Reply


@kelahcim 2 months

I feel your pain. I have dropped from 250 to zero for exact same reason ;) The order of magnitude is for sure different, but still, hitting the ground without any warning was a surprise.

A workaround here is to:

- leave the repo public - move it somewhere else (to private repo) - reinit original repo with empty content - once ready, bring back the old repo to previous remote

This way your stars are preserved.

Reply


@sefrost 2 months

It does strike me as unfair that GitHub themselves made the exact same mistake but were able to fix it with database backups.

Reply


@maxpert 2 months

Goes to show how "red buttons" won't make a difference when it comes down to screwing up.

Reply


@tomphoolery 2 months

This happened to me as well. It's sad that GitHub doesn't retain that data.

Reply


@salmo 2 months

I agree with the UI stuff and soft deletes. It was a lesson I learned about 7 years ago when I had users make some tragic mistakes in a system I made. “Are you sure?” doesn’t do anything more than a hand wave CYA. Showing the consequences does.

But then this starts sounding like a guy who went to the same bank for 30 years, knows the tellers, and doesn’t understand why they won’t give him a small business loan.

If you started a company, rely on GitHub for core infrastructure, why would you not pay for it? And if you did this, why would you expect them to do support outside of self-service? Open Source doesn’t mean charity-worthy anymore. Most “successful” projects are either spun out of or spearheaded by a business these days. And it’s not like GitHub is rolling in profit. Their enterprise offering is just starting to get traction under MS.

I think the complaints would be more valid if they were outside of the norms in this space. GitHub + MS is still 1000x less shady than Sourceforge. I don’t think you’d see different behavior from GitLab et al.

To the real politik-like view: this experience won’t make you (or many others) move elsewhere or pay for the service. So it’s ultimately a 0 consequence situation outside of a blog post and some community discussion.

I’m general, I don’t love pieces of software or companies. I’ll wear free t-shirts to mow the lawn, not with pride. I don’t love GitHub, but I dislike it less than the alternatives, partly because it’s just the easiest. I think most are in that camp. Oktocat lost his street cred long ago.

Reply


@RangerScience 2 months

Heavily reminds me of this RubyConf talk: https://rc-temp000-videos.s3.us-west-1.amazonaws.com/Laura-M...

One of the core bits of the talk is about the sort of messages our automated systems give us, and whether they're sufficient, or woefully lacking - which is what the linked article is also talking about, when it talks about how the "warning: about to burn down a house" doesn't tell if anyone's in that house.

Reply


@vaishnavsm 2 months

I really like this post.

While the author clearly feels bad about the fact that they've lost his community and that GitHub didn't restore it (which is honestly what any of us would've felt under similar circumstances), they're also focusing towards the future and using their personal experience as a parable all of us can learn from.

Lesson 1 on UI design I think is really important. I often think scary popup boxes are enough to get people to think about what they're doing, but this example clearly demonstrates that what's important is to use design not to scare (alone?), but to convey the information which makes a dangerous action dangerous as well. I also really like the fact that when the action isn't dangerous, the distractions ("Type this repo's name", etc) just go away. It's super intuitive, and (for a newbie designer like me) really helps build an intuition for various design principles put in action.

Lesson 2, which was to use soft deletes, is something I have more thoughts about. I assume that the cascading done on GitHub would be done on a FK constraint, but I'm not really sure how you'd do a "cascading soft delete" without making some kind of manual cascading logic? If anyone's aware of a standard way to accomplish this, please do let me know. Of course, the best way may just be to simplify the model so they aren't needed at all haha.

As designers and developers we've been given a chance to sharpen our toolkit. Thanks, HTTPie! You've gained a new star :)

Edit: Changed GitHub couldn't restore to GitHub didn't restore, as pointed out by @ncmncm (https://news.ycombinator.com/item?id=31033758#31034195)

Reply


@nosefrog 2 months

Additional context: a GitHub employee addresses why they didn't do a backup restore in this tweet:

> Yup, all watchers go when you go private and a bunch of notification settings etc. We've tried re-staring projects in the past etc but that ends up breaking lots of peoples notification settings. It's something we should make more reversible but hard for reasons <waveshand>

> It's the reason we display this when you try to do it. But a better fix would be for us to make it more easily reversible in the future.

https://twitter.com/martinwoodward/status/149333649025189478...

Reply


@tester756 2 months

Why do they even delete those stars?

Reply


@throwaway0x7E6 2 months

>There’s a confirmation box. It’s designed to stop users in a situation like mine from doing something stupid. It tells you that “You will permanently lose all stars and watchers of this repository.” That’s pretty scary.

>The problem is that the box looks exactly the same for repos with no commits and stars and for repos with a decade-long history and 55k stargazers and watchers. And it says “Warning: this is a potentially destructive action.”

>To paraphrase, the box tells you “You’re about to demolish a house. If there are any people inside, they will all die”.

>But it doesn’t include anything specific to break you out of your auto-pilot mode if you’ve confused the address and think you’re looking at an empty house.

just admit that you fucked up and don't look for someone else to blame. people would respect you more for it

Reply


@sorokod 2 months

None of the "Lessons learned" are of personal nature - unbelievable.

Reply


@al2o3cr 2 months

Alternate title: "How I deliberately messed up and why it's definitely everyone else's fault"

Reply


@pbhjpbhj 2 months

>"The same goes for stars. If you’re one of those 54K people who’ve starred the repo any time in the past decade, the repo is no longer among your starred projects." //

This seems like bad design from a UX perspective. Projects I star are a characteristic of my account. If a project is made private, I still want to have the star in my account list; it feels almost like gaslighting to just remove a star.

Reply


@yowlingcat 2 months

What an astonishingly poor design decision by GitHub. The intelligent design decision to making a repository private is to have private be a flag, and to have that privacy setting propagate down to the watcher level. Then, when a repository is made public again, all the watchers etc return.

Want to give users a way to remove all watchers? Great, make that /a separate action/ -- in no world and in no other application is it an intuitive UI/UX pattern to have make something private mean it gets deleted. That's absurd. Make private means "hidden for the indefinite future, but available to be made unhidden when I as a user see fit." That is the only reasonable definition I have ever seen (Instagram for example).

Whether you want to show a user that they watched a repository which is no longer public or simply have it disappear is up to the user, but I cannot understand why anyone thought that the straightforward solution was to /simply delete the data/. Between this and the now common downtime, I'm increasingly worried that GitHub is simply asleep at the wheel.

Reply


@paxys 2 months

"It's their fault, they only showed 5 warning banners. A 6th one would have totally stopped me from doing this."

If a "type your repository name to confirm" box still doesn't make you double check that you picked the right repository, what else can they even do?

Reply


@bradgessler 2 months

I see a lot of folks talking about better warnings, etc.

Something else to consider for situations like this (or maybe for your apps) is to use the element of time to prevent mistakes.

For example, when a user wants to permanently delete an account or do any action that’s destructive, irreversible, or catastrophic… queue up a job for 10 minutes, an hour, or maybe a day, that gives the user time to cancel it if they made a mistake.

Out-of-band could be another way to prevent mistakes. “Want to delete your account? We’ll send you a link for you to continue via email”. This would also be cancelable.

There’s a lot of ways to deal with potentially irreversible actions outside of “better error messages” or checking the equiv of an “are you sure?” Checkbox.

Reply


@HL33tibCe7 2 months

I notice there are a lot of people in this comment section who either haven’t read the article at all, or haven’t read it in full. Worth reading the full post before commenting

Reply


@forgotpwd16 2 months

I've a feeling the author blames GitHub for this. It makes sense to be angry about it but don't see how it's GitHub's problem that you autopilot destructive actions. Although agree that the UI could be improved.

Reply


@jamesmishra 2 months

This is a well-written blog post describing a real issue with GitHub's privacy mechanism.

But it is also a little silly for the blog post to show graphs extrapolating the hypothetical number of GitHub stars several years into the future. Their graphs' X-axis goes up to 2028.

Reply


@thayne 2 months

This isn't the only case where Github deletes more than one would hope. If you require 2fa for an organization, instead of simply locking out users that don't have 2fa enabled until they enable it, it removes them from the organization, and you have to re-invite them to add them back. Fortunately, it does seem to remember the groups and permissions they had when you add them back ... sometimes.

Reply


@jonenst 2 months

I would have had more sympathy for the author if they explained why they care so much about github stars. It's just internet points after all. At the very end, they say "What started as a side project has recently become a company" so if it's all about business, maybe they could have made that more prominent. EDIT: sorry, not meant to be harsh. Hopefully you get what you want and thank you for writing open source software

Reply


@anm89 2 months

Just went and starred the repo. Looks like they are back up to around 5% of their original star count. Not good but probably not a catastrophe for the project.

It seems the loss of watchers is still an issue though.

Reply


@jfmc 2 months

In a few years you'll be able to buy GitHub stars as NFT.

Reply


@bsuvc 2 months

Sure, the author should be responsible.

Yes, GitHub should have a better UX around this action.

But...

There is another thing to consider:

Is it really necessary that a repo that is accidentally made private and then made public should lose its stars anyway?

Is that really what the repo owner or the people who starred the repo even want to happen?

Reply


@catsarebetter 2 months

Starred and watched again, it's a great project, hopefully the whole audience comes back soon

Reply


@krick 2 months

> The tone of our decade-long mutually-beneficial relationship is set by GitHub’s Terms of Service. Thinking there was more to it was naive.

I really want to support that kind of sentiment. In fact, I want to support it every time I get a chance. That's just how I am. I enjoy people hating on Microsoft and such. I may even provoke it when it's not entirely justified.

But to be fair, making a twitter post about "some random project we host fucked up a bit, let's help them to get followers back" does seem to qualify as something "more to it". I'm pretty sure they weren't legally obliged to do that as well. And I'm pretty sure ads on github's official twitter aren't cheap either.

(But I do find that "not legally obliged" tone extremely insulting in any kind of relationships too. I myself also tend to get all "oh, so that's how you want to talk?" over that. I guess, I hate lawyers as much as I hate Microsoft. After all, they are essentially the same thing.)

Reply


@mproud 2 months

I dunno. You made a mistake, that’s on you. It’s so easy to say you want more hand-holding, and sure, maybe that’s not a bad idea in a sense, but you still made the mistake.

I do appreciate they aren’t yelling and complaining about it, however.

Reply


@williamsmj 2 months

https://rachelbythebay.com/w/2020/10/26/num/ makes a similar point. I don't remember us saying people only have themselves to blame when that article was posted (https://news.ycombinator.com/item?id=24904204). Not sure why we're doing it on this post, which makes a number of completely reasonable and specific suggestions for improvement.

Reply


@steve_adams_86 2 months

Apart from it being clear that the UI and the user using it could have been better, I don’t agree with criticism like “GitHub should obviously do x” or “this would be easily resolved if the action didn’t caused cascading deletes” and so on.

GitHub is a large and complex set of applications, and making changes like that is probably not trivial. It’s probably not a high priority either. This is the first time I’ve heard of this in the existence of GitHub, and while that doesn’t mean it has only happened once, I suspect it’s rarely a meaningful issue.

Solving problems like this at GitHub’s scale is often hard both due to the need to do things that matter more, and due to how entrenched database schemas and application architectures tend to be. I’m sure their migrations are plenty scary to manage, and doing it to alter behaviour when toggling privacy on a repository understandably wouldn’t be high on their list of reasons to perform one.

Aside from those concerns, I bet there are a lot of lines of code which assume stars exist for specific reasons. Once they can exist for another reason, you have to rewrite logic around that, rewrite tests for that logic, etc. It could easily be way more work than it seems at a glance.

Reply


@wilg 2 months

Do people use GitHub stars for something? Sometimes I star things but I have no idea what it does or why I do it.

Reply


@lexx 2 months

On the plus side. 54k know and use this project not because they have it starred. So it will regain the stars rapidly, and it will again hit all the trending metrics, so new people will discover it also. No biggie

Reply


@ghoomketu 2 months

That comparison spot the difference pic is really scary. I had to check it 2 times myself before I could spot that the last line is different.

Now that you're on the HN's frontpage, hopefully somebody from Github upper management will see this and all will be good soon thanks to gold old HN (especially when they did the same thing themselves and restored it).

Wish you the best.

Reply


@throwawayHN378 2 months

Ugh that sucks

Reply


@whoisthemachine 2 months

I agree with the author on most of their points, but I wonder if this is an argument for self-hosting your repository(ies) once your project reaches a critical-mass?

Reply


@johnwheeler 2 months

rm -rf /

gives no such warnings, and maybe it should, or maybe people should be _very_ careful when typing rm -rf in front of anything.

Reply


@GettoiBoise 2 months

This is giving me a really great idea for a tool that saves past states and allows for clean reversals of said mistakes.

Reply


@ev0xmusic 2 months


@prmoustache 2 months

The real lesson I make of it is that we shouldn't use a cloud product or SaaS if vendor do not allow customer to request recovery or prevent the customer to manage its own backups. I know git is decentralized and no code is ever lost but github is so much more than git.

Backups aren't mean to recover from outages. They are also, and I would even dare saying mostly, used to recover from human mistakes. If the vendor terms and conditions don't allow this, github is not a production ready solution.

Reply


@lucideer 2 months

There's so much focus on the UX here to alert you to a destructive action, but I haven't seen anyone mention this: why does Github even delete stars, and why on earth is it permanent?

It seems like a temporary UX hack put in place because some tricky implementation detail handling stars on private repos. Like they said "we'll fix that later" and then the warning message stayed.

In a well designed system, making a repo public/private would be a switch where full state is retained back and forth.

I mean, it's kinda hypothetical but stars aren't even completely useless in a private repo (for a sufficiently large set of users with access).

I'd go further and say that even the UX around the destructive act of deleting a repo shouldn't be necessary: that seems undo-able. Overwriting would still need a warning (creating a repo in a namespace that previously contained data) as would anything involving losing access (deleting an org, freeing it up to the community at large), but not needing it for repo deletion-a relatively common action-would go a long way toward reducing "autopilot".

Reply


@pluc 2 months

You didn't lose anything, you asked for it to be removed by setting your repository private, albeit mistakenly. Something that is public (stars) cannot coexist with something that is private (your repo), otherwise unexpected things start to happen or you need to write a bunch of pointless edge cases. It makes sense. So does this article, but it should be a "lesson learned" and not a "GitHub fucked us" angle cause it pretty clearly tells you what you're about to do.

Reply


@edem 2 months

> But it doesn’t include anything specific to break you out of your auto-pilot mode if you’ve confused the address and think you’re looking at an empty house.

Destruction is destruction. I think a huge red notice should be enough to stop you from dozing off. I understand your pain, but I don't think that any of this is GitHub's fault. They can't read your mind, and they can't tell if you're feed up with OSS or just irresponsible.

Reply


@bearbin 2 months

Why care? Stars don't mean anything, save for the few people who organise the software they use by starring it.

Certainly it's not a community owned by the maintainers. I don't own a connection with the people that upvoted this post, and stars mean exactly the same (effectively nothing).

Reply


@C4stor 2 months

Is focusing on github stars specially meaningful ? Is there any functional difference for the repo between having 6k stars (as of today) and 54k ? I don't think so honestly. Github stars are just not something useful to monitor closely. I had a look at my starred repos on github, 95% of those I have no idea what it is anymore anyway.

So yeah, github didn't do any extra effort to restore what's imo essentially a vanity metric. Makes sense to me ?

Reply


@pmarreck 2 months

I like the tool, somehow I'd never heard of it until now

Reply


@pizza234 2 months

The post is omitting that the user must type the name of the repository in full; in this case, they typed `httpie/httpie`. If one is in such a deep autopilot state, no amount of warnings will work.

Reply


@hitovst 2 months

Yikes. Can this be turned into a multi-sig 2fa, or 1 hour waiting period before confirmation?

Reply


@dogdot 2 months

I liked the post. Then I got interested on their upcoming desktop tool. Then I decided to keep up with them but didn’t manage to find a rss of their blog…

Is rss dying?

Reply


@jakelazaroff 2 months

GitHub made a cardinal UX design sin here: never use a warning when you mean undo [1]. If they had given even a five minute grace period before starting the irreversible process of removing all the watchers, this wouldn’t have happened.

https://alistapart.com/article/neveruseawarning/

Reply


@WhyNotHugo 2 months

This sounds like a great opportunity to move onto an open source platform to host this very popular open source tool.

Their current hosts have even just proved that they don't care about them much -- only first party projects get special treatment.

Reply


@mekster 2 months

This is laziness on GitHub.

If your client asks you for work and you get lazy because it needs some internal modification that could take a day instead of an hour, you just respond it's impossible.

Generally that's quite unacceptable especially when they already know about the situation from previous incidents and obviously human errors could happen again and the fact they did restore for their own project doesn't make it look any better.

Reply


@yellowapple 2 months

30 minutes seems like a weirdly long time to delete 54,000 rows; doing something in SQLite like

    CREATE TABLE stars (id INTEGER PRIMARY KEY, user TEXT, repo TEXT);
    INSERT INTO stars SELECT
        value AS id,
        'User ' || value AS user,
        'foo' AS repo
    FROM generate_series(0,53999);
    SELECT * FROM stars;
    DELETE FROM stars WHERE repo = 'foo';
is just about instantaneous. I'm sure GitHub's schema is more complicated than that, but it can't be that much more complicated, right? Are there a bunch of tables referencing the actual GitHub stars themselves as foreign key constraints or something? Or a bunch of triggers on update/delete?

It also seems weird that it would be necessary to delete those rows at all; yeah, having stars for private repos is kinda pointless, but other than taking up space it doesn't seem like it'd do much harm, either. If the space taken up is really that much of a concern, then a periodic cleanup job along the lines of

    DELETE stars FROM stars JOIN repos ON
        stars.repo_id = repos.id
    WHERE
        repos.visibility = 'private';
seems more sensible than just immediately deleting everything (and insisting on that deletion having finished before allowing another visibility change).

Reply


@bawolff 2 months

Github stars are such a weird metric/thing. There are a lot of reasons i write open source code, but randoms on the internet who might not have even have used your project "liking" it, is not one of them.

That's not to say recognition isn't a motivator, it is. Github stars just seem like a really poor proxy for recognition.

Reply


@pingsl 2 months

This is horrible -_-!!! But I wonder what would happen to GitHub Discussions in this situation?

I now 100% feel necessary to build a Discord channel for OSS projects.

Reply


@michaelterryio 2 months

GitHub should restore it and they should do it to cause themselves pain so they address the the improvement they can make to the Uc.

Reply


@soorya3 2 months

This is definitely a lesson for you as a customer and github service provider.

As customer if you are getting something for free you have to assume all risks. Here would be nice if public repos are also paid for open source projects so that you can pay for basic backup and recovery.

As a service provider github think about the product - "how do I design a more reliable system?" Deleting data immediately is never a best practice better alternative is to delay the destruction.

Reply


@bilkow 2 months

I find it ironic that some people are blaming the author so bad given that Github has made the same mistake in the past and had to restore it from the backup, making it clear that the UX could be better.

I get it, we should all be very cautious when doing destructive actions, but it's also specially easy to be confused by github's repository naming conventions and you're not seeing the actual repository you're making private, just it's name.

Reply


@mlatu 2 months

i mean, if they hadnt taken their repo private on accident, i probably wouldnt ever have heard of them.. i never really was interested in what the most watched or starred repos were, but something better than curl? yes please, may i have another?

Reply


@roxaaaane 2 months

I really like this post.

It shows how we gamify everything including open-source.

Reply


@jdorfman 2 months

DevRel 101. If a project had 54k stars and they obviously made a mistake why take the chance of them writing a blog post and having it hit the front page on HN?

If Nat was still CEO this wouldn't have been a thing.

Reply


@a-dub 2 months

eh, github kinda sucks.

they should fix this, or at least pull username lists for stars/follows and give them to the user for followup.

if the user self hosted, they'd pull from their own backups. instead they trusted a third party and helped contribute to that third party's success. now it's that very success that the user contributed to that stands in the way of help resolving the user's problem.

shrugging and saying sorry is kinda pathetic.

Reply


@pm90 2 months

This kind of shit (accidentally doing something that in retrospect feels dumb and stupid but made sense if you were in a certain brain space) happens all the time and it’s nice the author wrote about it. I could easily see myself doing this.

It should be possible for GitHub to restore. If not now, then in the future.

Reply


@OJFord 2 months

Oof. Nice write-up, and it'll probably work. I.e. I'd wager that 'no we won't do for you (even in exchange for cash) what we previously did for ourselves' decision is going to get reversed.

Reply


@wly_cdgr 2 months

The author shows admirable restraint in characterizing Microsoft's response

Reply


@dom96 2 months

Surprising amount of people blaming the user here. I agree completely with the author, the UX should be different for clearly "big" repos.

Reply


@HellsMaddy 2 months

In America, we blame individuals when systems fail. We don't have to, we can actually design systems to be better. Design isn't just about making things look pretty. Good design reduces entropy.

https://www.youtube.com/watch?v=Ra_0DgnJ1uQ

https://en.wikipedia.org/wiki/Human_factors_and_ergonomics

Reply


@kgeist 2 months

Reminds me of our own quest to stop users from deleting their entire projects by accident in our product.

1st iteration: delete button with a confirmation box (standard stuff). Users click through the box in autopilot mode and still delete their entire projects.

2nd iteration: someone came up with an idea: confirmation box + an additional checkbox (if it isn't checked, the delete button is disabled). Users still manage to delete projects by accident. When we asked them how that happened (we've set up so many hurdles!), the user says, just like in the article, that they thought they were deleting a different (test) project.

3rd iteration: I suggested showing the number of objects in the project (just like suggested in the article) so that the user knew they aren't deleting a test project.

I moved on to a different project since, but the saga probably continues.

Reply


@NoboruWataya 2 months

> The problem is that the box looks exactly the same for repos with no commits and stars and for repos with a decade-long history and 55k stargazers and watchers. And it says “Warning: this is a potentially destructive action.”

It seems a bit much to expect the website to show you a warning of different levels of severity depending on the stars a repos has, particularly when the standard message is pretty severe and explicit. It even makes you type the name of the repo you want to make private before proceeding - I don't see how that wouldn't make anyone snap out of autopilot. I sympathise with the author's misfortune but it is pretty hard to look at that warning dialog and conclude that he was not sufficiently warned of the consequences or given a chance to reflect.

I find it disappointing that all of the lessons supposedly learned from this ordeal are lessons for other people, not the author. Surely lesson #1 should have been "check what repo you're in before taking destructive actions".

Reply


@IYasha 2 months

GitHub became more a social platform rather than just a code repository and it let you build up a community - I can't argue with that. But it's a large commercial company that doesn't really care about you. Now, when it's microsoft, more so than ever. I'd never trust my data to a company like that. Last time I trusted Google I lost all (decade worth of) email. I worked in a company that WOULD sometimes make devs manually scrap user data from the database when it was our fault or users were somewhat important, but that's more like exception to the rule.

Reply


@CreepGin 2 months

Murphy's law strikes again. Really appreciate the writeup. Making the best of the situation is a valuable lesson in itself. Hope you can get the stars back one way or another! =)

Reply


@wly_cdgr 2 months

Sounds like Microsoft recruits from the same pool as Atlassian for its Customer Success team :)

Reply


@yu-carm-kror 2 months

I’ll admit I didn’t read the whole thing but this sound like hyperbole

> And GitHub cascade-deleted our community that took 10 years to build.

How does losing stars equate to losing the community? Won’t actual fans be right back using and contributing?

If you remove a contributor of a private github repo it deletes their remote fork and all of their remote branches. To me that’s real loss.

Reply


@einpoklum 2 months

Something which annoys me with GitHub is that I don't have the option of setting up a mailing list which people viewing my repository page can opt into, as easily as they can star or opt-in to notifications. I often want to ask my users things, and I simply have no mechanism of doing that.

(doesn't have to be a mailing list, that's just the simplest feedback-request mechanism I can think of.)

Reply


@kizer 2 months

Restore their stars! Restore their stars!

Reply


@davedx 2 months

Contrarian opinion here.

While things can always be better the Github UX is good enough here. I am reminded of an old phrase:

“A bad workman always blames his tools.”

At some point you just need to accept responsibility for your actions and stop blaming others.

Reply


@mihaifm 2 months

> We even offered GitHub financial compensation for any resources required

What? Can anyone explain this? Are people so desperate about github stars these days that they’re willing to pay Microsoft for them?

Reply


@prtkgpt 2 months

I would love to help rebuild the community.

Reply


About Us

site design / logo © 2022 Box Piper