[HN Gopher] We lost 54k GitHub stars
___________________________________________________________________
We lost 54k GitHub stars
Author : todsacerdoti
Score : 1750 points
Date : 2022-04-14 21:51 UTC (1 days ago)
(HTM) web link (httpie.io)
(TXT) w3m dump (httpie.io)
| HeavyStorm wrote:
| 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.
| werdnapk wrote:
| 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.
| carvking wrote:
| Github should really just do the right thing.
| actually_a_dog wrote:
| 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.
| hollerith wrote:
| The server automatically removes "how" and "why" at the start
| of a title. Numbers or at least 10 are also autoremoved.
| jzer0cool wrote:
| 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 :)
| adenozine wrote:
| 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.
| danielyaa5 wrote:
| It resets watchers also and people subscribed to issues. That
| negatively impacts the project
| adenozine wrote:
| Ah, I didn't know that.
|
| Well! I'm the fool, it seems. That actually sounds terrible
| and rather substantial. You'd think there'd be an Undo for
| that.
| auggierose wrote:
| 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.
| ranguna wrote:
| Any recommendations?
| system2 wrote:
| He said "somehow". I think he also believes there isn't an
| alternative.
| auggierose wrote:
| Not really. Money seems to be a universal proxy. I guess we
| need to acknowledge that 54k GitHub stars has some sort of
| monetary value (Web3 anyone?), and then it would be obvious
| that you couldn't just delete it, because who would want to
| just delete money?
| caymanjim wrote:
| 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.
| DryLabRebel wrote:
| Same!
| WesolyKubeczek wrote:
| 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.
| a99c43f2d565504 wrote:
| I'd recommend reading the actual post carefully before claiming
| to having double checked anything and then going on judging
| using harsh language. You completely missed the 54k stars
| question presented and the context in which it was presented to
| the op.
| detaro wrote:
| Where did you find those SS600+ comments bashing Github for not
| having prevented this action"?
| WesolyKubeczek wrote:
| Of the 600+ comments here, the vast vast majority is
| contemplating how github could improve it's UI and UX so that
| nobody loses a star ever again.
| jrockway wrote:
| 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.
| lmc wrote:
| 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?
| julianlam wrote:
| 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.
| floor_ wrote:
| I'm imagining this dev 'rm -rf / --no-preserve-root'ing and then
| blaming Linus.
| brentis wrote:
| Came here to hopefully see GitHub came to the rescue through a
| friend of a friend on HN..
|
| Unfortunately....not
| mattigames wrote:
| 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?
| brian_herman wrote:
| I gave them a star to help them out.
| xyst wrote:
| 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.
| NorwegianDude wrote:
| "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.
| [deleted]
| chikipowpow wrote:
| Wow, the tone alone leaves much to be desired. You must have a
| very unempathetic culture where you live. Best of luck to you
| dude, all the warmth and kindness and good vibes!
| alecbz wrote:
| Wow, you must be a miserable, wretched, shell of a person to
| possibly write something like this. It's really sad no one
| ever taught you manners. Hopefully one day you learn to be
| happy and a better person like me.
|
| ^ this is not much better tone-wise
| chikipowpow wrote:
| Hi stranger, good vibes to you too. Looks like you need
| them!
| chikipowpow wrote:
| ascar wrote:
| Your point was valid. The way you framed it wasn't. You
| could take from that to better provide constructive
| rather condescending criticism.
| mrmuagi wrote:
| I am going to reply to you genuinely... but not like you
| will read it :/
|
| You have lots of snark in your original reply you may
| have missed. I'm talking mother in law (MIL) levels of
| passive aggressiveness. The sort of bullying done by
| being positive, like hiding a knife in a cake.
|
| You may have not intended for it to come off that way,
| but that's the wonder of the internet, context is lost
| and pitchforks are primed.
|
| The OP seems to be just invested in the stance that the
| system exists and status quo is okay dokay -- Even I
| disagree with that viewpoint and feel like this can boxed
| up as ezpz PR by helping the repo recover stars and
| "thank" them for testing the grey areas in the UX. Or OP
| just really doesn't disagree with systems where, yes you
| can shoot yourself in the foot, but hey, just push the
| responsibility on the user and wash your hands clean
| (Lady Macbeth should have done this). Arguing this opens
| a pandora box of other requests might be from his
| experience, so I can't really pew pew that since it might
| have increased his workload previously, but certain
| people get priority/hidden privileges more than others
| everyone on social meda (e.g. famous people are verified
| faster) and it's not really out of the ordinary.
|
| He is norwegian anyway, and I am previously familiar with
| them in their natural habitat[0] and can empathize with
| them on this viewpoint. Regardless, it's a pretty popular
| mindsent among the programmer crowd, that systems must be
| respected and learned and its heresy otherwise, victim
| blaming is commonplace. RTFM and PEBKAC. But honestly you
| can't always 'git push --force' your problems away, and
| at the end of the day here, you will be penalized with
| downvotes for this sometimes going against the grain --
| but whenever there is a zeitgeist of common sense (e.g.
| Amazon warehouse threads or other PIP dog pilling) people
| realize this and turn the dial back, but ultimately
| holding a moral position of kindness/goodwill needs a lot
| more wordcraft to avoid getting downvoted in the field.
|
| [0] https://www.youtube.com/watch?v=GmIoZxdwLTY
| [deleted]
| yesenadam wrote:
| I'm not sure why the drive-by, off-topic, gratuitous dig
| at vegans, as if you've decided they're a fair target,
| even in a comment instructing about kindness. I downvoted
| and flagged your comment for that. The HN guidelines
| apply regardless of your subject.
| mrmuagi wrote:
| Sorry, and thanks for correcting my guideline breaking. I
| am a stranger in strange lands...
|
| I brought it up because its an easy way to bring a moral
| rightousness example on hckernews. Perhaps more merit to
| the idea one should think of how ones word are received
| without context. To me as a casual reader here its like
| the space and tab holy war, except actually real. I don't
| dislike vegans per say as eat 80% vegetarian for health
| reasons.
|
| Is it presumptuous to assume you are vegan and took
| offense? If so, could you share some viewpoints on your
| decision if you are?
| NorwegianDude wrote:
| It might have been slightly harsh.
|
| Github did tweet to ask people to support the project, to
| witch the project starts comparing it to a situation
| where github restored their own data, as if that was
| unfair.
|
| The post also seems to wildly overestimate the importance
| of the project and the effect on github and Microsoft. It
| also seems to be written just to pressure github into
| giving the project special treatment.
|
| The post even states: "After all, GitHub has a history of
| taking controversial actions that go against the spirit
| of open source and community and then reverting them only
| based on public outrage."
|
| So the post seems to be made overly dramatic on purpose.
|
| As for the opinion about the UI, I do prefer it as is, if
| that wasn't clear. There needs to be a balance between
| usability and protection, and I think github has done a
| great job. It would of course be nice if it didn't get
| deleted and instead just stopped sending events.
| dmitryminkovsky wrote:
| Stars on GitHub are huge in open source. 54,000 stars is a big
| deal and puts your project into a super-elite category.
| mattgreenrocks wrote:
| If it's such a big deal then why is GitHub not intervening to
| help a "super-elite" tier of project?
|
| Devs retconned the concept of a like onto a star. That
| doesn't mean they are the same thing.
| dmitryminkovsky wrote:
| > If it's such a big deal then why is GitHub not
| intervening to help a "super-elite" tier of project?
|
| That's why this is a #1 post.
|
| > Devs retconned the concept of a like onto a star. That
| doesn't mean they are the same thing.
|
| Yes, the semantics are ill-defined.
| munchler wrote:
| What concrete benefits does a project get from having lots of
| stars? I'm not disagreeing with you, I'm just wondering what
| the stakes are, since I don't have a lot of open source
| background myself.
| dmitryminkovsky wrote:
| I'm not sure if there is a fixed universal set of concrete
| benefits. It probably varies from project to project and
| the people involved.
| bobbylarrybobby wrote:
| You missed the nuance in the criticism of GitHub's UI. The
| issue is not the presence of a roadblock, but that the same
| roadblock is put up regardless of how "actually" destructive
| the action to be taken is. The same roadblock should not be
| used to guard against both benign and severe consequences, else
| you have no real way of telling what lies on the other side of
| the roadblock you're plowing through.
| NorwegianDude wrote:
| I didn't miss it, I just don't agree with it. With the name
| being different I'd say the roadblock is different, but you
| might not agree, and that's fine.
|
| I really don't care about the number of stars my project has
| if I'm going to make something private. It's not like most
| important projects sticks out by a very significant amount of
| stars. What percentile would? And what percentile of these
| occurances are on this scale? (basically none according to
| the article)
|
| I'd care more about the number of active contributors who
| will loose access, if I did care for a message like that.
| ttty wrote:
| [deleted]
| cyphar wrote:
| While the article focuses on lost stars, they also lost a
| lot of repository watchers.
|
| This is pretty significant because lots of downstream users
| and distribution maintainers use the watching feature to
| get release and security advisory notifications. If this
| had happened secretly it's possible that a security release
| would be delayed because they didn't see the announcement
| early enough. (In fact, in the article they mention they
| had a security advisory recently -- so it's possible the
| above scenario has already happened.)
| KennyBlanken wrote:
| There's no nuance.
|
| The UI warns you something serious is going to happen with
| bold text on a separate line.
|
| It makes you type the full path of the affected object.
|
| His explanation for what he was doing in the first place
| (making a README file private) doesn't make the slightest bit
| of sense.
|
| It's a PR stunt for a startup company.
| alasdair_ wrote:
| > Github warned about the action, and even required written
| confirmation to make sure it was the correct repo.
|
| Sure, but the written warning was the same one for a completely
| safe action.
| KennyBlanken wrote:
| You mean the one that requires you to write the full path of
| the affected object?
| mcs_ wrote:
| Hi team,
|
| You got my star back. Good luck.
| redocecin wrote:
| Good lessons learned, thanks for sharing!
| HigherPlain wrote:
| 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.
| akie wrote:
| Not necessarily. In some ORMs you can have scopes that can be
| used to append common sub-queries or conditions, such as "WHERE
| is_deleted=0", and some allow you to specify default scopes
| that should be appended to every database query (unless
| explicitly switched off).
|
| I'm just saying: It doesn't _need_ to be a considerable
| rewrite, it really depends on how your ORM or data layer is
| implemented.
| capdeck wrote:
| 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!
| ncmncm wrote:
| As the article noted, that absolutely would not fix the
| underlying problem at all.
| polote wrote:
| 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.
| wly_cdgr wrote:
| Github UX team has a responsibility to its customers to make
| this error MUCH harder to make than it is
| mekster wrote:
| I suppose you never take a backup because everything should be
| in ideal conditions. If you consider manual errors as non
| existent, you need to rethink your design.
| enlyth wrote:
| They do raise a good point about the UI though, explicitly
| showing "you're about to nuke 55k people, are you sure?" would
| make the user pause.
| spiderice wrote:
| I have no dog in the fight here, and no affiliation to HTTPie,
| but this definitely seems like a Github issue to me. You can't
| just give users ways to easily and accidentally shoot
| themselves in the foot, and then blame the user for shooting
| themselves in the foot.
| pizza234 wrote:
| It's not so easy to make this accident - one needs to type
| the full name of the repository. AWS does the same, for
| example, when deleting RDS instances, and I find it
| effective.
| HL33tibCe7 wrote:
| This is explicitly addressed in the article, and a
| compelling case is made for why that safety measure was
| ineffective in this case, I encourage you to read the
| article
| nkozyra wrote:
| Yeah. I'm not sure what else you can do with warnings other
| than make the person effectively recite back the thing
| they're doing.
| ncmncm wrote:
| There was an explicit suggestion _right there in the
| article_ what else they could do, so you don 't even have
| to guess.
|
| Typing in the number of objects that would be deleted in
| addition to the name is something else.
|
| Or, they could just keep all of them in place, but
| hidden, and "restore" them all automatically if you made
| it public again.
|
| There are lots and lots of things they could do better,
| if they cared. But paraphrasing Eunice, of course they
| don't care, they're Microsoft.
| nkozyra wrote:
| > There was an explicit suggestion right there in the
| article what else they could do, so you don't even have
| to guess.
|
| I read it, but I disagree.
|
| Honestly I don't think it would have prevented this. If
| you're muscle memorying past warning signs the text on
| the warning sign isn't going to matter much.
|
| My point was purely about UX, obviously there are
| technical solutions to this problem.
| tentacleuno wrote:
| > If you're muscle memorying past warning signs the text
| on the warning sign isn't going to matter much.
|
| Do you have any concrete evidence for this? A lot of
| people keep saying this but don't provide anything
| factual in the way of UX studies, etc.
| nkozyra wrote:
| Well it's exactly what happened in this case. The user
| got a sort of warning fatigue with the UX and familiarity
| with it made it easy to do without much internal debate.
|
| But I think some other UI flaws contribute to that in
| this case.
|
| Comfort with a UI means eventually you want it to get out
| of your way and your brain will do what it needs to
| streamline the process. At which point those elements
| intended to break the flow of the app no longer do.
|
| A Firefox use case w study and their approach.
|
| https://medium.com/firefox-ux/designing-better-security-
| warn...
|
| Good discussion of the problem:
|
| https://ux.stackexchange.com/questions/44609/how-do-i-
| avoid-...
|
| My takeaways are as follows:
|
| The best thing to do is provide undo. Then you can reduce
| the hoops people have to jump through because the
| consequences are less severe.
|
| Simplify the modal so the text about what will happen
| stands independently enough to be parsec on first glance.
|
| Show quantified data on what could happen. Instead of
| "you will lose all followers" which is true for any app,
| display "you will lose all 54,318 followers"
| akerl_ wrote:
| Who got shot in the foot here? The article keeps talking
| about killing 55 thousand people. I'm trying to grok why
| "unstarring the repo" is such an earthshattering thing. It's
| annoying if you wanted it starred / wanted notifications,
| because you have to notice and redo it... but there's no
| irreparable harm, no data loss.
|
| This reads like somebody was placing way too much personal
| mental value on "the repo for my project has a large number
| of stars"
| that_guy_iain wrote:
| So all those people got notifications and then some of them
| looked further at the notifications and then engaged. Now
| those people won't get those notifications and won't
| engage. Most of these people won't notice they don't get
| these notifications. They won't resubscribe. They're lost
| forever. This is kind of like losing your email list.
|
| Your comment reads like you don't understand how a
| community works.
| akerl_ wrote:
| If the measure of community is "people who get my emails,
| and wouldn't notice if they stopped getting my emails",
| then yea, I guess we just disagree about what a community
| is.
|
| I'm on an email list for marketing message for a hotel I
| stayed at last year. TIL that I'm part of their
| community.
| that_guy_iain wrote:
| Yea, over simplify it, that's always great.
|
| If you focus solely on the getting notifications part.
| But the core part of any community is the ability to
| broadcast news to them. If you remove the ability to
| broadcast news and falicate communication between members
| then the community fades. Especially, if it's remove.
|
| Not all members of a community are extremely active, some
| aren't that active at all if you remove the ability to
| let the less active people know stuff that may be of
| interest to them then obivously it'll damage a community.
| nkozyra wrote:
| To be fair, people very active in a project will probably
| realize relatively quickly.
|
| Those most likely lost to the wind forever are the ones
| that star a repo and forget about it.
|
| I think the problem self corrects but agree there's a
| short term slowdown possibility in the wake.
| MatthiasPortzel wrote:
| You don't get notifications after starring a repo,
| they're only a measure of how popular the repo is. The
| repo did legitimately lose its Watchers, but the author
| seems a lot more concerned about losing (and getting
| back) the stars.
| nkozyra wrote:
| It's very much a matter of reputation. Losing the star as a
| user is a pretty small inconvenience, tantamount to losing
| a bookmark.
| pessimizer wrote:
| > there's no irreparable harm, no data loss.
|
| There's a repo-user join table that is gone. That's literal
| data loss. If I delete your contacts, is that data loss? I
| mean, you still have your phone and all your ex-contacts
| still have phone numbers.
| lalopalota wrote:
| I've never considered data I deleted to be lost.
|
| "Do you want to delete this?"
|
| "Yes"
|
| "Are you sure?"
|
| "Yes."
|
| ....
|
| "OMG it's all gone!?!?"
| delaaxe wrote:
| Have you been living under a rock? Everyone judges repos by
| their amount of stars. Why do you think every social media
| network has the concept of likes?
| munk-a wrote:
| Can you just clarify if that statement was sarcastic or
| not?
|
| I've had a very different experience around stars -
| they're just a bit of fluff and pretty unimportant
| compared to watches.
| BHSPitMonkey wrote:
| HTTPie's watches were irreversibly deleted, too.
| robonerd wrote:
| > _Irreversible_
|
| If the watchers still care to watch, they can choose to
| watch again.
| pessimizer wrote:
| That's not a reversal. If I burned your diary, you could
| write a new one, but nobody would call that a reversal.
| robonerd wrote:
| They didn't burn a diary. They burnt the list of people
| who subscribed to updates to a diary. If those people
| still care about the diary, they can resubscribe to those
| updates.
| spiderice wrote:
| It's crazy to me how quickly this conversation has
| devolved. If Pewdiepie had all his Youtube subscribers
| deleted should he just say "oh well, the ones that like
| me will come back". No. Because that's an absurd
| attitude. Obviously that would forever hurt his
| viewership. Github is no different with stars. They
| matter. Period. Maybe not to you. But they matter.
| robonerd wrote:
| Pewdiepie's compensation is intrinsically related to his
| subscriber count, no? That gives him a reason to care. Is
| your compensation similarly related to your github star
| count? I sure hope not..
|
| If I unstar your repo, I have not taken anything from you
| because you never owned my star in the first place.
| Github presents this number to you as though it were
| important, to give you a dopamine hit when the number
| goes up. Their motivation for doing this is obvious. If
| you fall for this trick, that's on you. You have the
| choice to stop caring.
|
| _And even if_ the premise of these metrics being
| important were accepted, the fact remains that the
| removal of people from the watchers list is not
| irreversible. No irreplaceable documents were destroyed.
| No diaries were burned. If the repository had been
| deleted, commit history erased, _that_ would be
| comparable to a diary burning. But that 's not what
| happened (and would probably _still_ be reversible.)
| forgotpwd16 wrote:
| >If the repository had been deleted
|
| For which to happen you've to do the same thing: type out
| its name. So I wonder if people ask for privatize to be
| presented with number of stars, should when deleting a
| repo GitHub present you with number of commits, issues,
| releases, etc as well?
| robonerd wrote:
| Assuming you're not being sarcastic: a company providing
| a metric and telling you to care about it does not oblige
| you to actually give a shit.
| Rapzid wrote:
| I feel like a parallel universe has suddenly intersected
| our own.
| shrimpx wrote:
| It's true that this is "PEBKAC" but it's also true that this is
| a UX/system design failure on GitHub's part.
| Dylan16807 wrote:
| It is a big failure by github that making a repo private
| immediately and irrevocably destroys all the stars.
|
| That's a much bigger failure than clicking the wrong button.
| mattcwilson wrote:
| What could the author have done with this post that would take
| it from being "blaming" into "giving feedback in an earnest
| intent to save others future pain"?
| pwdisswordfish9 wrote:
| Drop passive aggressive comments like the one about how
| they're going to stop wearing their GitHub T-Shirt because of
| how GitHub subjected them to the same treatment that lesser
| and more unworthy projects would have received.
|
| Even using words like "future pain" is pretty crazy. "We lost
| 54k GitHub stars"? They're imaginary internet points! Cope.
| mattcwilson wrote:
| It sounds like you are ok with the post, except for the one
| sentence before the epilogue?
| alecbz wrote:
| Acknowledge their own agency and responsibility.
|
| Literally stop blaming with language like "GitHub deleted..."
| mattcwilson wrote:
| How would you word that sentence and remain factual about
| the deletion?
| alecbz wrote:
| "I accidentally made a repo private, which resulted in
| all of its stars being removed."
| mattcwilson wrote:
| From the post:
|
| > Due to an unfortunate sequence of events, I
| accidentally made the project's repository private for a
| moment. And GitHub cascade-deleted our community that
| took 10 years to build.
|
| This reads the same, to me, in terms of cause and effect.
| Rapzid wrote:
| I swear there's something in the water. This entire
| thread has a ton of nastiness/bitterness in it.
| sschueller wrote:
| In a normal organization where stuff like this happens one has
| backups since one runs these things internally.
|
| Humans make mistakes all the time. We build systems to try to
| mitigate these and build them better by learning from new
| mistakes.
| FabHK wrote:
| With that mindset, planes would still fall out of the sky every
| month. Because basically 90% of plane crashes used to be "pilot
| error". If you then say, well, it was pilot error, bad pilot,
| can't do anything about it, that's the way it is, pilot
| should've not made an error... well, then we wouldn't have
| reached the amazing aviation safety we have now.
| munk-a wrote:
| Pilots and doctors are two great examples of customer pools
| where UI/UX actually gets a significant amount of attention
| because we all realize how high the stakes are. I imagine the
| FDA has zero tolerance for vendor software that is bundled
| with dark patterns that encourages doctors to promote the
| prescription of certain drugs over others... at the same time
| we have quizzes that have made it to HN multiple times[1]
| that reinforce the "correctness" of dark patterns.
|
| UI/UX often gets overlooked as being unimportant, and, as a
| backend person I can definitely sympathize, but when you're
| building a product that people use for important things it is
| important to give UI/UX the attention it deserves.
|
| 1. https://cantunsee.space/
| pmw wrote:
| > I imagine the FDA has zero tolerance for vendor software
| that is bundled with dark patterns
|
| Here's a recent case of a nurse going to prison for a
| medication error, where the UX of the medical cabinets is
| blamed in a big way: https://khn.org/news/article/radonda-
| vaught-fatal-drug-error...
|
| > The case against Vaught hinges on her use of an
| electronic medication cabinet, a computerized device that
| dispenses drugs and is widely used in hospitals > > ... > >
| Vaught triggered an override that unlocked a much larger
| swath of medications > > ... > > Some experts have said
| cabinet overrides are a daily event at many hospitals. > >
| Vaught insisted in her testimony before the nursing board
| last year that overrides were common at Vanderbilt, and
| that a 2017 upgrade to the hospital's electronic health
| records system was causing rampant delays at medication
| cabinets. Vaught said Vanderbilt instructed nurses to use
| overrides to circumvent delays and get medicine as needed.
| acheron wrote:
| I think there might be a difference between losing a plane
| and losing your "GitHub stars".
| ncmncm wrote:
| It is a difference of degree.
|
| People making bad UIs make them that way regardless of
| consequences for users.
| izacus wrote:
| Planes have plenty of ways you can deliberately turn off
| systems and kill everyone on board. And they require less
| work that having to retype a whole text into a confirmation
| box.
|
| You missed that besides fixing UX, we also train pilots to
| think about their actions, talk to copilots about their
| actions, take responsibility for their actions and most
| importantly, not to press buttons on "autopilot".
|
| That's a completely different situation and defending learned
| stupidity of just clicking ok to everything.
| ncmncm wrote:
| Likewise, surgical deaths. The number of people dying on the
| operating table is in sharp decline because hospitals have
| lately begun to institute procedures that make mistakes non-
| fatal.
|
| An early one was making the "oxygen" knob on the
| anesthetist's gas panel _not go to zero_. But it appears lots
| of people here can 't imagine why that change was made.
| bawolff wrote:
| To borrow something from safety engineering - there is no such
| thing as an operator error, only bad user interfaces.
|
| I definitely think this is github's fault for creating a system
| where an operator error is likely. OTOH stars are such a vanity
| metric that i can't be bothered to feel too sympathetic because
| who cares about stars?
| munk-a wrote:
| Having read through the article I'm really not getting the same
| vibes of Github being wholly blamed for this mistake - they
| clearly call out their own user error directly in the article
| but offer suggestions to make it less of an issue in the
| future. I got the sense that a long time user had went through
| a hellish week of trying to restore data and is feeling bitter
| but mostly just wants the product to improve.
| drewda wrote:
| 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" :)
| forty wrote:
| 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?
| mekster wrote:
| I sometimes decide what to use based on number of stars. It's a
| trust in the quality of the software.
|
| Now httpie is on 2.5k stars and if I only knew about it today,
| I'd consider using an alternative with 10k stars if there's
| any.
| dajonker wrote:
| From personal experience and from reading the other comments,
| some people see open source as a popularity contest and more
| stars will get you more users (which in turn gets you more
| stars).
|
| Choosing one library over another just because it has more
| stars is bad decision making.
|
| Consider choosing a command line tool for making http requests.
| If you consider GitHub stars: - curl has 24.7k stars - httpie
| has 4.3k stars as of writing this - wget only has a mirror on
| GitHub with 264 stars
|
| Does this mean wget is a bad tool? Does it mean httpie used to
| be vastly superior to curl with over 2x the amount of stars? I
| don't think you can really say anything meaningful about these
| projects based on the amount of stars, especially relatively to
| each other. Except for how many people clicked on the star
| button.
| acid__ wrote:
| (Whether it's a good idea or not,) people often use stars as a
| quick-and-dirty proxy for "is this repo reasonably well
| trusted?" and "how big is the community for this project?". All
| else being equal, many people would default to using a repo
| with 20,000 stars over a repo with 20.
| maxloh wrote:
| As a junior developer, GitHub star was one of the most
| important metric when I am choosing library/software.
| hvdijk wrote:
| A practical consequence (not necessarily the only consequence)
| would be for the people who starred it who use stars as a
| bookmark feature: they have now lost their bookmark.
| wpietri wrote:
| Starring a repo is a way of tracking it. So now there are 55k
| people who were trying to keep an eye on the project who have
| silently lost that.
|
| It's also an important indicator of community size and
| authenticity, important factors in the decision to use the
| code.
| layer8 wrote:
| > silently
|
| I'd argue that GitHub should send them a notification that
| the repo they starred has been made private.
| ncmncm wrote:
| And another that it was made public again. Or neither, and
| just not delete shit that there was no need to delete.
| lalopalota wrote:
| The user said "delete this stuff". GitHub asked, "Are
| your sure?" User: "Yes".
|
| Seems like a good reason to delete it.
| ncmncm wrote:
| No. The user said, "make it private". That has nothing to
| do with deleting anything.
| layer8 wrote:
| My point is that IF they delete everything, they should
| send a notification to the affected users. When the
| repository is made public again, then since they deleted
| the star relation it's not possible to send another
| notification.
| ncmncm wrote:
| Unless, of course, if they just changed the column
| setting from "starred" to "was starred". As they could
| do. If they cared.
| layer8 wrote:
| That's why I wrote "IF they delete everything". You're
| saying they shouldn't delete everything, which I agree
| with, but that's not the case I was addressing.
| israrkhan wrote:
| 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.
| kelnos wrote:
| 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?
| mc4ndr3 wrote:
| What are some of the benefits of HTTPie over classic wget and
| cURL?
|
| Does HTTPie support WebSockets?
| kelahcim wrote:
| 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.
| sefrost wrote:
| It does strike me as unfair that GitHub themselves made the exact
| same mistake but were able to fix it with database backups.
| qbasic_forever wrote:
| I wonder how different the response from Github would be if
| this blog post was instead, "Oops, Github's confusing UI made
| me delete the entire project metadata... so since we're forced
| to start fresh we decided to move to Gitlab/sourcehut/etc."
| maleldil wrote:
| httpie would never do this. Deleting their stars is already a
| blow for their community, but changing to another provider
| would kill it.
| BlueTemplar wrote:
| And yet they _specifically_ call out Microsoft. And then
| the only consequence is "I will probably take a break from
| wearing Octocat-decorated t-shirts."
|
| Which makes them come out as hypocrites. You don't get to
| blame Microsoft for EEE, and then continue to help them
| with it !!
| [deleted]
| pwdisswordfish9 wrote:
| There is no way in the world that the kind of person who
| writes a post like this and clearly places so much emphasis
| on gamified social media stats as a proxy for self-validation
| ever chooses to move to Sourcehut. No way. GitLab is most
| likely out of the question, too. The author of this post is
| exactly the kind of ideal customer for what GitHub is
| "selling" and that the others can't provide.
| callalex wrote:
| There was a way to say this without framing it as a
| personal attack. The author may care about stars because
| they find that increased engagement leads to higher quality
| contributions, for example.
| nessguy wrote:
| Just as AceJohnny said, the scope of this is entirely
| different. Restoring a backup for an internal project costs
| time/resources that the company can easily handle. If it became
| a problem it would be easy for github to tell their internal
| projects "No, we're no longer restoring from backups"
|
| Opening up the ability to do that externally would potentially
| require multiple people working full-time to handle the
| requests.
|
| "We even offered GitHub financial compensation for any
| resources required." Considering the tone of the article I
| think there's a very high risk if github accepted agreed to
| that we'd see an article titled "Github charges popular open
| source project $5000 to fix a minor accident"
| Johnny555 wrote:
| Or, knowing that it's the only way they have to recover from
| this situation, they could make the process easier to do and
| price it out as a service.
| ncmncm wrote:
| Or, just leave everything in place, always, and have the
| other code ignore the annotations for exactly as long as
| the repo is private.
| munk-a wrote:
| Just FYI - you can star private repositories so it's not
| quite that simple. You'd need to determine if the
| starring aligns with permissions... but I think it's
| still relatively reasonable.
| ncmncm wrote:
| Ok, then have a separate button: "Delete all 54,000 stars
| on this repo", completely independent of public/private.
| rincebrain wrote:
| I would observe that even today, the GH desktop repo has only
| 14k stars, and at the time, archive.org says only 2.6k[1] - so
| I would not be surprised if the costs associated with the
| restore were massively different.
|
| (Not weighing in on whether they still should have considered
| it or not, just observing that their claim that it costs an
| unacceptable amount may not be inconsistent with having
| restored a much less comparatively "hot" repo.)
|
| [1] -
| https://web.archive.org/web/20201116172809/https://github.co...
| fourseventy wrote:
| What is possibly unfair about that?
| munk-a wrote:
| I'm just surprised that after going through that pain
| themselves they didn't decide to revise how that social linking
| data is handled. A lot of github content is softly deleted by
| necessity, you couldn't nuke tickets written by a now non-
| existent user or unmerge PRs so this isn't really a new concept
| to the team.
|
| I don't think it's surprising they'd do such a thing for
| themselves and not a customer - I'm more surprised they didn't
| remove the footgun for future mistakes on their part.
| [deleted]
| op00to wrote:
| Or simply automate the restoration! They know how to do it!
| Make it easy!
| hrpnk wrote:
| True. On the other hand - Atlassian did automate their
| backup restoration. Look where it brought them ;-)
| op00to wrote:
| Obviously you need to automate the restoration of the
| restoration!
| AceJohnny2 wrote:
| Internal vs External support.
|
| Internal support is inherently limited: the single organization
| is of limited size.
|
| External support has no limit in scope, you have to setup SOPs
| (Standard Operating Procedures), communicate expectations,
| likely hire support staff...
|
| Look at it this way: internal support is helping your friends,
| but external support requires setting up contracts.
| BHSPitMonkey wrote:
| I get that, but they probably shouldn't have publicized the
| remediation via a public tweet if it's an avenue that's
| closed to the rest of us plebs (since in cases like this, it
| really feels like salt in the wound).
| yreg wrote:
| It would strike me even more unfair if GitHub fixed this
| mistake only for customers they like.
| nemothekid wrote:
| When you think about it, it seems reasonable, I think about
| what would happen if it were me.
|
| If I was working at GitHub, and I nuked something, then the
| rest of my day would be un-nuking that thing. On the other hand
| if I was working on something totally unrelated, and then you
| my PM came to me and said "can you stop what you're doing and
| unfuck this thing" it would obviously depend on what I was
| working on.
| mekster wrote:
| It's your customer (repo owners) asking for support and
| throwing it away being busy is just lazy attitude. You had
| prior incidents and the bugs were left as is and apparently
| it will happen again.
| nemothekid wrote:
| Being busy is lazy? GH has hundreds of thousands of
| customers. In your company, how often do you immediately
| drop everything to work on a single customer's issue? How
| often do customer issues sit in a support queue? What would
| be the reasonable turn around time for an issue like this?
| [deleted]
| [deleted]
| maxpert wrote:
| Goes to show how "red buttons" won't make a difference when it
| comes down to screwing up.
| tomphoolery wrote:
| This happened to me as well. It's sad that GitHub doesn't retain
| that data.
| mekster wrote:
| They apparently do. Even if they did hard delete they still
| should have backups. They just got lazy fixing it after several
| similar incidents and this one was expected and yet all they do
| is a tweet saying "good luck building up the community again".
|
| My faith in their tech department is falling when they can't
| fix such a small issue.
| salmo wrote:
| 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.
| RangerScience wrote:
| 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.
| vaishnavsm wrote:
| 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)
| ncmncm wrote:
| > " _that GitHub couldn 't restore it_"
|
| What an odd turn of phrase.
| vaishnavsm wrote:
| Not sure what you meant? Are you pointing out _couldn 't_ vs
| _didn 't_? If so, I didn't really think about it, although
| now that you point it out, I think _didn 't_ would've been a
| better fit. I'll edit it, thanks!
| ncmncm wrote:
| I mean "refused to". There was absolutely no value to
| Microsoft in refusing to restore the deleted information,
| and there was no practical reason to have deleted it at
| all. Ultimately, it just amounts to contempt.
| lalopalota wrote:
| "I screwed up. By the way, it's your fault. I hope you
| realize how many people think more highly of your service
| because my project is there. Why wont you accept some
| money for a service you don't provide?"
|
| What's the value in capitulating to that? Also, a user
| saying "delete this stuff" is a pretty practical reason
| to do so.
|
| Indifference != contempt.
| ncmncm wrote:
| Define the difference.
| a-dub wrote:
| or maybe just incompetence? or just retro-1990s
| microsoft? what is this? slashdot in 1998?
|
| i mean, this is the company that perfected the "throw it
| all away and start over" serviceability paradigm and the
| "we don't know what's wrong with it just reboot it every
| six hours" reliability paradigm for systems.
|
| totally reliable business partner to trust for
| outsourcing critical business and government
| infrastructure for sure!
|
| those who are serious and prudent seek assurance, for the
| reckless and feckless, there's azurance.
|
| if the blog post doesn't work, i'd suggest renaming the
| project (specifically the cli) such that it makes
| reference to the hollowness of the new microsoft's
| apparent love for open source. that way when those
| thousands of developers (who happen the be of the exact
| variety that the dinosaur is trying to court) are
| invoking it every day, it can burn into their skulls to
| never ever work for, or choose technologies made by,
| microsoft.
|
| score 5: funny, insightful
| benjaminjackman wrote:
| For Lesson 1: I think the general pattern that ought to be
| followed is to "prefer undo to warnings." Undo is often harder
| to implement, however it's usually a superior experience.
| SnowHill9902 wrote:
| Rollbacks even better.
| ncmncm wrote:
| Even better, flipping "public/private" has absolutely no need
| to delete any information at all.
|
| There could be separate buttons, "Delete all my stars",
| "Delete all my watches".
| hk__2 wrote:
| > Even better, flipping "public/private" has absolutely no
| need to delete any information at all.
|
| Of course it does. You can't watch/star a private repo
| unless you have access, so all watchers/starrers should be
| removed. If you kept the data as-is watchers would still
| see the repo updates in their feed, which is the opposite
| of the 'private' feature promise.
| alpaca128 wrote:
| Sure, if you don't change any part of the system it has
| to be that way. But there's no reason a private switch
| can't just suspend stars/watchers instead of permanently
| deleting them.
| vaishnavsm wrote:
| I agree that undos are pretty nice for when errors are
| possible, but I think there's a really good reason to put up
| warnings too. Let's say they accidentally made the repo
| private, but didn't notice it (unlike what happened here).
| Although you would be able to undo the change, it may have
| only kicked in once the news spread around (followed by
| reputation damage, etc). A well worded warning would prevent
| that.
|
| In a way, I think warnings and undo serve two different
| functions-warnings are meant to inform the user of their
| action, and undos are meant to roll back actions taken.
| lolinder wrote:
| There are definitely still cases where warnings are
| important, but the point of "prefer undo to warnings" is to
| eliminate as many warnings as possible to avoid
| desensitizing users. I should only see a scary pop-up if
| the action that I'm performing is going to be well and
| truly destructive.
|
| Undo-instead-of-warning is a great pattern for lower-stakes
| actions that are easy to undo and cause minimal damage if
| left done. This allows the few warnings you _do_ show to be
| recognized as truly important.
| whack wrote:
| > _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_
|
| Relying on database cascade deletions is very dangerous.
| Especially since as the application/org grows, it's easy to
| lose track of all the things that may get cascaded. There's a
| good chance you'll find yourself having cascade-deleted data
| that you never intended to have deleted.
|
| Manually implementing logic for _" when archiving X, also
| archive Y and Z"_ takes more effort, but is a lot safer. When
| it comes to data.
|
| What surprised me most is that github performs irreversible
| deletions when someone making a repository private. I would
| have expected them to just create a "is_deleted" column and set
| that flag to true. I wonder how much of this behavior is
| motivated by GDPR. Ie, complying with it requires completely
| deleting data when requested by the user, and they decided the
| most straight forward way to comply with that requirement is to
| delete the data immediately when requested.
| harg wrote:
| Regarding cascading logic with soft deletes; I think the answer
| is that you don't cascade anything. You basically need to have
| `deleted_at IS NULL` conditions in your queries to exclude
| them.
| cmeacham98 wrote:
| I specifically dislike the "Lessons" section, as it throws all
| the blame on github and doesn't mention the seemingly obvious
| advice: "make sure you're not on autopilot when taking
| potentially dangerous actions, on github or any website".
|
| Yes, GitHub probably should show the stars in the warning UI,
| and hopefully that will prevent some of these mistakes. But
| GitHub makes it pretty hard to make this mistake already - the
| author had to _type out_ the name of the repo they wanted
| deleted into the warning box. At that point, it's hard to
| believe the author when they claim that this one addition to
| the warning UI would have definitely stopped them when they
| weren't paying enough attention to notice they had typed the
| entirely wrong repo into the confirmation box.
| Abishek_Muthian wrote:
| > "make sure you're not on autopilot when taking potentially
| dangerous actions, on github or any website".
|
| Have the advertisements/sign-up/GDPR pop-ups trained us to
| 'engage autopilot to dismiss the pop-up' as soon as possible
| irrespective of its importance?
| mkl wrote:
| Having to also type out the number of stars you're deleting
| when it's above some threshold would probably eliminate the
| error. I think people who use git a lot are used to having
| the same or similar repository names in multiple contexts and
| locations (it's decentralised), so typing out the repository
| name, even though it includes the user/organisation, is not
| as severe-seeming as the designers thought. Confirming the
| consequences seems better than confirming the command.
| prepend wrote:
| I think of the burden on the typical use case and think the
| current prompts should be sufficient.
|
| What's the star threshold? 1000? 5?
|
| I'd hate to now have to type in the number of watchers and
| stars as part of the private/delete/move/etc prompt for all
| the times I know what I'm doing.
|
| It's a balance between punishing the non-stupid users vs
| protecting the stupid users. And people switch between
| these categories. I might be non-stupid today and stupid
| tomorrow.
| pmontra wrote:
| The author explicitly admits "my brain switched to auto-pilot
| mode." The problem with that is that we're on auto-pilot many
| times and we realize we're doing it only after something bad
| happens. The UX should prevent auto-pilot to do harm to us
| (and possibly to the customer/company relationship.) "You're
| about to delete 55k stars" should be enough, as the author
| suggested. But designers can be on auto-pilot too.
| josephjang wrote:
| > But designers can be on auto-pilot too. You're blaming
| some people without any basis.
| johnywalks wrote:
| > make sure you're not on autopilot when taking potentially
| dangerous actions
|
| Humans will be humans, we can't help it.
|
| Structures or systems that handle large amounts of user
| interactions should predict such use cases and design
| accordingly. a.k.a make them "idiot proof".
| barrkel wrote:
| "The user shouldn't be stupid" - which is what you're saying
| sounds like to my ears - is not an approach that scales well.
|
| Mistakes happen. It's better to have a really good Undo than
| a lot of confirmation dialogs.
| derefr wrote:
| If your whole job is to use power-tools, the fact of using
| power-tools by itself -- scary to some -- becomes benign for
| you. `rm -rf` isn't scary to type if you e.g. write CI
| scripts intended to run in sandboxes all day. Deleting a repo
| isn't scary if you delete a lot of pointless repos.
|
| A prompt that pops up to warn you that you're doing something
| potentially dangerous, when you know that what you're doing
| is benign, is a prompt that's crying wolf. You'll learn to
| tune it out.
| prepend wrote:
| This is a good point and reminds me a story of many years
| ago when someone accidentally ran "rm -rf" on an important
| directory and caused a lot of work.
|
| A well-intentioned PM then thought the fix was to alias rm
| and add prompts to confirm. They had a whole project to add
| this alias everywhere.
|
| First it broke existing scripts all over the place. So they
| fixed them to auto apply the confirmation.
|
| Cut to a few months later and someone rm-rf'd something
| again, ignoring the prompt (or maybe auto applying it).
|
| So the PM wanted a better message and a second prompt.
|
| People are well intentioned but I've seen this path of
| stupidity that doesn't solve the problem but is an activity
| in response to a problem.
| Macha wrote:
| Yeah, aliases for "rm" to "rm -i" I find are especially
| counter productive in this regard, as it conditions
| people to type rm -f after they get spammed to approve
| several hundred files while trying to delete a git
| checkout or node modules too many times.
| makeitdouble wrote:
| On typing out the name of the resource, it is of course a way
| better check than just displaying it. I think it also was
| very efficient when there was only a few places using it, and
| the novelty made it attention focusing.
|
| Thing is, we type all day, and can type pretty much any
| string at a decent speed without putting much thought into
| it.
|
| Any of us must have mistakenly typed a full file path or API
| URL, just to realize it's not the right machine or project
| after having typed it all. It just take 2 or 3s max after
| all.
|
| I think it becomes an arms race to get attention on important
| things, we can do better by focusing more on every single
| destructive operation. We can also avoid having too similar
| interfaces for completely different contexts.
| oriki wrote:
| It's also worth mentioning that the name of the resource
| here was confusing - the author mentions that this happened
| because he mixed up how GitHub names profile READMEs for
| organizations vs users.
| rmbyrro wrote:
| > make sure you're not on autopilot when taking potentially
| dangerous actions
|
| If they're in autopilot, how are they going to "make sure"?
|
| Everyone has been in this spot several times. Those who
| didn't are just lucky.
|
| There's got to be external contingencies to protect people
| when they're in autopilot.
| [deleted]
| Aeolun wrote:
| Tbh, it doesn's look like the wrong repo name if you want to
| make your organisation README private. I agree with the
| author that the discrepancy between user and organisation
| profiles doesn't help here. If every user/organisation could
| make a .github repo instead it would be much more obvious.
| aasasd wrote:
| > _the author had to _type out_ the name of the repo they
| wanted deleted_
|
| Where does it say that they deleted any repo?
| mherdeg wrote:
| My favorite example of this is that the cloudflare.com web UI
| has some extremely scary buttons, like a little "bypass CDN"
| button with a cloud on it that will rapidly increase traffic
| to your site 2-100x if you accidentally click.
|
| I mean this isn't _exactly_ how it works. But it 's a bit
| scary.
| d3nj4l wrote:
| Agreed, and I'm genuinely surprised that so many on HN are
| angry at GitHub when they _already_ made it so hard to do
| this. The author explicitly mentions they were on autopilot -
| it would take a significantly more challenging barrier for
| them to not do the exact same thing no matter how many
| prompts GitHub put there. It does make sense for it to be
| more reversible, but I can also understand why GitHub doesn
| 't want to put in the effort: this is a once in a year kind
| of incident and the resources required wouldn't be worth it
| compared to signal boosting, like they did on twitter. I, for
| one, would be extremely pissed if GitHub made it harder for
| me to do routine actions because there's a _possibility_ of
| data loss. I signed up for that when I typed the repository
| name in.
| taink wrote:
| The point the author makes is not that it should be more
| tedious to make private: they in fact suggest making it as
| tedious as it is _only_ when you are on a new, non-
| massively-starred repository. Right now it is only tedious
| and not sufficiently alarming, is what people are saying.
| tyrfing wrote:
| I intentionally did this very recently for a whole bunch of
| old repos (mainly because a Github bot decided to start
| emailing me weekly about vulnerabilities in stuff that has
| been untouched for nearly a decade) and was mildly annoyed
| at how inconvenient it was to make them private. I would
| have said the warnings are unnecessary overkill.
|
| It's quite amusing to read this so soon after.
| d3nj4l wrote:
| Same here - not too long ago I had to take a bunch of
| repositories private, and while I appreciated the prompt
| (I've dealt with destructive actions that have even
| _less_ of a barrier before, and that sucks) it still was
| annoying to do that again and again.
| _moof wrote:
| _> make sure you 're not on autopilot when taking potentially
| dangerous actions_
|
| When it comes to repetitive or familiar actions, this is
| physically impossible. If a repeated action is dangerous you
| cannot use a human interrupting themselves as your only
| control. It just won't happen.
|
| Overall this is a classic UI design failure. In addition to
| the "people physically can't take themselves off autopilot"
| problem, the interface destroys the user's data without
| providing a way to get it back. It would take relatively
| little engineering effort to make this reversible.
| wpietri wrote:
| I suggest you read "The Field Guide to Understanding 'Human
| Error'". You'd learn a lot.
|
| https://www.amazon.com/Field-Guide-Understanding-Human-
| Error...
|
| My view is that expecting humans to stop making mistakes is
| much less effective than fixing the systems that amplify
| those mistakes into large, irreversible impacts.
| josephjang wrote:
| It's not about whether human can make a mistake or not.
| It's about how much effort should be made to prevent a
| certain type of human mistakes.
|
| If every system we're interacting daily should be fool-
| proof, it will requires enormous time and effort.
| Naturally, we invests more time and effort when it's about
| life and death situation. If we only lose 2 cents by our
| mistake, we just don't care.
|
| Of course, I'd like to have more fool-proof design in all
| the destructive interactions from all websites. But, the
| question is, does it worth it?
| mynameisvlad wrote:
| This, 1000x this.
|
| It's easy to be an armchair engineer and say "well,
| obviously, don't make this mistake in the future".
|
| As a species, we will always take shortcuts. If a mental
| pathway doesn't need to be exercised to do something, it
| won't be. If we see the same popup a hundred times, we're
| going to ignore the contents by the 100th time because
| we're used to it.
|
| But it shouldn't _be possible_ to make this mistake if this
| was designed properly and in a way that made it clear that
| _what you 're about to do is actually dangerous_ and not
| "dangerous" like the other dozen times you've seen the same
| message.
| quacker wrote:
| > It's easy to be an armchair engineer and say "well,
| obviously, don't make this mistake in the future".
|
| It's sort of equally easy to say Github should do X or Y
| to improve the UX in this (rare?) case without actually
| knowing the effort or opportunity cost.
|
| Like maybe I'd rather Github figure out how to not have
| outages so frequently and how to not accidentally give
| people million+ dollar bills and such.
| mynameisvlad wrote:
| > Like maybe I'd rather Github figure out how to not have
| outages so frequently and how to not accidentally give
| people million+ dollar bills and such.
|
| I doubt the engineers working on the stability issues or
| billing have anything to do with UX and vice versa. It's
| not like there's a singular focus that everyone at the
| company must prioritize above all else. Multiple people
| can work on multiple projects and not impact one another
| at all.
| ncmncm wrote:
| On one hand you have millions of users who each are
| obliged to walk on eggshells.
|
| On the other, you have a few Microsoft hacks who could
| easily do the right thing on behalf of those millions of
| users.
| chefandy wrote:
| Pretty much agree-- Universal human fallibility is not an
| avoidable moral failure, but looking down on those who've
| made, admitted, and taken responsibility for simple
| mistakes sure is. Unrealistic assumptions about people's
| attention, processing capability, and physical
| capabilities may be the greatest hurdle when trying to
| actually solve people's problems with software. It can
| even be a safety issue-- consider the Therac 25 incident.
|
| That said, superlatives like _" impossible"_ aren't
| realistic here. As long as an action is possible, it is
| also possible to fuck it up. The challenge screen _does_
| require typing in the repo name which is a pretty solid
| attention-getter. It would be nice to list the important
| side effects in big angry letters but I 'll bet the list
| of side-effects that are important to _some people_ would
| be pointlessly long. Maybe a sanity check requiring repos
| with extremes in certain metrics to get a sanity check
| from support first-- but I have had some preeeeettty
| protracted response times from GitHub support.
| wpietri wrote:
| > The challenge screen does require typing in the repo
| name which is a pretty solid attention-getter.
|
| This is not quite correct. In requires _inputting_ the
| repo name. It 's attention-getting the first time. But
| recently with some colleagues as part of a handoff we
| went through 50+ repos and archived the irrelevant ones.
| Very quickly the person doing the actual archiving went
| from typing to just copy-pasting the repo names. For
| programmers, copy-pasting from one spot to another can
| become _very_ mechanical.
|
| So I think this UI choice works well for something that
| is done very occasionally. But it's no better if people
| are in the habit. Whereas showing novel information about
| the cost of the choice would be helpful in breaking the
| routine. Then could then also make it so that they had to
| type something only when the operation has a high cost,
| and what they typed could be something not directly copy-
| pasteable.
| chefandy wrote:
| That's fine. The goals of designing a sanity check prompt
| to snap people out of autopilot are entirely different
| from goals you might have in a security system-- their
| being defeatable isn't even a flaw. Jersey barriers vs
| rumble strips.
|
| If someone deliberately doing the same thing over-and-
| over can avoid the manual effort, that's fine. Their
| frustration would likely make them think about it less.
| You don't, and shouldn't get prompted to do the same
| thing using the API, either.
| mynameisvlad wrote:
| > I'll bet the list of side-effects that are important to
| some people would be pointlessly long.
|
| There's many good ways to design this that wouldn't
| result in pointlessly long lists (which is another
| problem). You don't need to expose _everything_ that will
| happen when you do an action, just the "most important".
|
| With unlimited budget, you could compare a bunch of
| metrics to a baseline to figure out what might be
| important. Have a lot of stars, way more than the
| average? That would be nice to highlight. Only have a
| normal number of forks? Probably less important to
| highlight that. At the end of the day, Github repos
| aren't extremely unique. Sure there's probably extremely
| rare edge cases, but for most repos, comparing against a
| relatively small number of metrics should get enough to
| paint a picture of what might get broken. Everything else
| can be hidden behind a "... and X more" if people are
| curious.
|
| This both highlights the most important things that might
| happen, and also provide people with an action to do
| before confirming, hopefully helping to break the
| autopilot at the same time.
| chefandy wrote:
| You assume the metrics you have are sufficient to
| determine intent and importance, that your users needs
| are uniform enough for those determinations apply, and
| discount the possibility of making things worse by
| communicating the wrong thing. These assumptions
| perennially land developers and inexperienced designers
| in hot water designing things like this.
|
| _> "most important"_
|
| Yes-- the problem is determining the most important
| metrics _for the human who 's reading the dialog._
| Sorting the second part is a lot more difficult than the
| first.
|
| _> With unlimited budget_
|
| This framing is only useful to determine what _behaviors_
| would be great, not feasibility. We seem to both agree on
| the ideal behavior but not on the feasibility.
|
| _> you could compare a bunch of metrics to a baseline to
| figure out what might be important._
|
| Important to whom?
|
| _> Have a lot of stars, way more than the average? That
| would be nice to highlight. Only have a normal number of
| forks? Probably less important to highlight that._
|
| Average for what? Just average for everybody? For the
| deprecated SlackTextViewController which has vastly
| higher numbers overall than the unmeasurably more
| important net-snmp? What about for repos that serve as
| core functionality to frameworks that only care about
| forks? XML Schemas that people refer to but never
| interact with? What about for a company that doesn't care
| about stars because they're incredibly popular outside of
| that repo but it's critical for them to monitor the small
| number of people who've forked their repo?
|
| _> Sure there 's probably extremely rare edge cases, but
| for most repos, comparing against a relatively small
| number of metrics should get enough to paint a picture of
| what might get broken._
|
| The repo about which you said this mistake _should not
| have been possible_ was an extremely rare edge case. The
| article went to great lengths to explore just how
| fantastically different this repo was. And if you 're
| talking about painting pictures you're using the wrong
| medium. More information can make the message more
| pointed but only if it's brief and extremely relevant. If
| it's not, it's going to reduce the focus on the _danger_
| message.
|
| _> Everything else can be hidden behind a "... and X
| more" if people are curious._
|
| Aaaand we come full circle. The whole point of this is to
| put the metrics most important to that user right in
| front of their face in bold type because that's going to
| stop autopilot mistakes. _If it 's hidden, it failed._
| Beyond that, the order in which you list things connotes
| importance-- closer to the beginning means more
| important. Being hidden connotes far lesser importance.
| If you put the _wrong things_ at the top and the _right
| things_ behind a click then the autopilot user
| subconsciously assumes they 'd care about the hidden
| things even less. You're _increasing_ the risk of failure
| rather than decreasing it. If you 're going to highlight
| anything, you better highlight the right thing.
|
| The existing dialog is pretty clear that you should
| investigate what it does before you actually execute the
| command without giving people false clues, and that may
| be the best compromise. You don't convey false
| impressions but still convey danger.
|
| _> At the end of the day, Github repos aren 't extremely
| unique._
|
| From a quantitative perspective they're not incredibly
| diverse, even if they're probably more diverse than you
| imagine. What is immeasurably diverse is the roles those
| software packages serve, the people who interact with
| them, and what they need to accomplish their goals.
| Assuming you can boil that down to a heuristic using
| available data is something that needs to be concretely
| proven-- not assumed.
| chefandy wrote:
| Anyone wanting to dig deeper into the design side of this
| should check out Triadic Semiotics-- it's the philosophy
| of signs.
| ryandrake wrote:
| Warnings are good but not perfect. At the end of the day,
| you can't help everyone with just warnings. You could
| make the UI bright flashing red, with a skull and
| crossbones, have it say "Never invoke this: it will
| delete all your data and kill your dog. Please type
| 'I_WANT_CANCER' to continue." And users will do it. It
| can't be helped. The only (admittedly hard) way is UNDO.
| beaconstudios wrote:
| There are a couple of issues with UNDO too:
|
| - (not intrinsic) many interfaces only give you a few
| seconds to undo your action, which wouldn't help in this
| case
|
| - (intrinsic) some events can be layered on top of your
| change, meaning that you have to either block the undo or
| reverse all the subsequent events too. This wouldn't be
| the case for this HTTPie incident, but does prevent UNDO
| functionality from being a silver bullet.
| tialaramex wrote:
| Undo. If it's possible, you want undo. If it's difficult,
| you still want undo. Only when you've satisfied yourself
| that it's outright impossible should you reluctantly
| design the UX with the "Are you sure?" prompt instead.
|
| Also, if you must have I_WANT_CANCER type prompts, try to
| make them involve expressing what it is that the human is
| agreeing to, because sometimes it's only at that point
| the human realises their plan was very stupid. GitHub
| does that here (you have to type the name of the repo, to
| delete main_project you'll need to type main_project) but
| many things do not.
|
| This is why I like Git's force-with-lease. When I try to
| forcibly overwrite the state, because I know Jim's push
| was wrong and must be undone, force-with-lease makes me
| express that, "--force-with-lease=jim-daft-change". And
| when in fact what I'm going to overwrite is Lisa's urgent
| bug fix, not Jim's erroneous change, the force-with-lease
| _fails_ and to get it to apply this way I 'd need to say
| "--force-with-lease=lisa-bug-fix" and that's one last
| opportunity to say "Wait, what? That's not what I want to
| do".
| snurk wrote:
| It's a real strength of Gmail and some other Google
| interfaces -- undo instead of warning dialog.
| flowerbreeze wrote:
| I think from UX perspective it is unbelievably more
| convenient as well. Plain popup warnings with "press Ok
| if you mean it" are bad enough, but quite recently the
| new even worse "type delete, if you want to delete, then
| press Ok" popup has been spreading about... If I want to
| delete over a couple of things I get incredibly irked.
| necovek wrote:
| It sounds like you've never been part of an engineering
| organization (I know you have since you bring up
| unlimited budget ;)
|
| It is obviously possible to design a much better,
| contextual warning with (more) relevant details
| highlighted. How much time is usually set aside for
| those?
|
| And yet, it's never going to stop mistakes.
|
| And how many other places like these are there in a large
| service like GitHub?
|
| A much better way to fix this is to expect mistakes and
| make it possible to revert instead. Soft deletes can make
| that trivial to implement for the most part too (except
| in GDPR like cases where you've got to really remove
| stuff).
| wongarsu wrote:
| Even for GDPR stuff you can delay the hard delete for a
| day or so, which should give the user some time to notice
| and correct a mistake.
| [deleted]
| Proven wrote:
| klabb3 wrote:
| Yeah. A warning that can be pattern matched by a human
| brain, that is just a routine action, will result in
| autopilot behavior. Flipping early repo visibility is
| common, I assume. Flipping visibility of 100+ star repos
| is likely much less common. So having a separate warning
| in that case might help you snap out of autopilot due to
| novelty.
|
| A common knee-jerk reaction to "users aren't taking our
| warnings seriously" is making the warning look more scary
| and involving more (mechanical) steps - such as two
| confirmations instead of one. Well, that's pattern
| matchable and subject to desensitization.
|
| Like the article states, it's more efficient to instead
| show _what_ you 're about to remove, i.e. a summary of
| the content as opposed to an identifier, then you get
| both novelty and proportional scariness, depending on how
| "big" it is.
|
| https://en.m.wikipedia.org/wiki/Alarm_fatigue
| icambron wrote:
| That's not quite it. The solution isn't to stop them from
| doing it or warning them more aggressively; it's to make
| it genuinely less dangerous. For example, make the stars
| all come back when you reverse the switch.
|
| Of course that's a lot harder to do, since it's a lot
| more than a UX change. So I'm not really slagging GitHub
| here. But it's the right way to attack this problem.
| mynameisvlad wrote:
| True "Undo" is, IMO, a pipe dream for all but brand new
| projects. That will pretty much require you to
| rearchitect a decent chunk of anything that wasn't built
| with it explicitly in mind.
|
| In this case, I don't quite understand why stars and
| forks need to be deleted when switching visibility, since
| it seems like the two shouldn't be linked. I can star and
| fork my private repos just fine, so it seems like it was
| just easier to clear it out than to deal with RBAC at
| that level.
| kevinforrestcon wrote:
| Then don't "do" the delete, when the users "do" the
| delete.
|
| Pretend to do it, actually do it 24 hours later, and if
| they "undo" the delete within that time frame, just
| remove it from the delete queue process.
| whym wrote:
| I don't think any fork was deleted. 3.5k forks as of now
| vs 3.4k forks in January: https://web.archive.org/web/202
| 20129022012/https://github.co...
|
| Many people won't notice some of their stars having
| disappeared, but many would be surprised to see their
| forks deleted without _their_ consent, especially those
| that are not merely a mirror. People can have diverged
| forks after adding substantial changes without feeding
| them back to the original for a variety of reasons.
| ncmncm wrote:
| Just not deleting them in the first place, or not
| deleting them until explicitly asked to, would suffice,
| and would be, ultimately, less code. So, I am not buying
| the apologetics.
| djur wrote:
| It seems to me that services that pretend to delete data
| but don't actually do it are usually subject to criticism
| on Hacker News, not praise.
| ncmncm wrote:
| You did not read the comment you replied to. Why? And
| then, why reply?
| vidarh wrote:
| The issue tend to be services who are not upfront about
| it. "This is potentially really damaging, so in case it's
| a mistake we'll just hide it for 24 hours during which
| you can undo" or something to that effect would be
| sufficient.
| necovek wrote:
| I am surprised so many people treat losing stars as
| "dangerous": I can certainly emphatize with the designer
| coming up with this pop-up while looking at a sample
| project with 12 stars.
|
| Considering this project was out of ordinary in having
| 54k stars (article mentions being in top 80), they should
| not be surprised that their case is not top of mind.
|
| Sure, it would be nice to highlight the most destructive
| of actions, but they already had to type out full project
| path as confirmation.
|
| I do believe it would be better if Github allowed
| restoring data in the next few days (soft deletes ftw)
| once they hit this issue themselves in the past.
|
| And Github support should have recognized that this
| project is a special, out of ordinary project, and
| afforded it some engineering time to restore everything.
| Conan_Kudo wrote:
| > I am surprised so many people treat losing stars as
| "dangerous": I can certainly emphatize with the designer
| coming up with this pop-up while looking at a sample
| project with 12 stars.
|
| Lots and lots of websites and companies use the number of
| stargazers as a strangely important metric for success,
| so losing them can be really bad.
| np_tedious wrote:
| From the product's perspective speaking in aggregate, that
| is entirely correct.
|
| From an individual user's perspective, you still need own
| your shit and avoid making these mistakes. You can't rely
| on everything you use having smart safeguards.
|
| There will always be dumb/careless users that a product
| should consider. There will always be suboptimal UI (we
| could've just as easily been talking about CLI database
| tools) that a user should watch out for
| react_burger38 wrote:
| This idea - fixing systems that amplify mistakes into
| large, irreversible impacts-- is why I am against alcohol,
| marijuana and other mental-state altering drugs for
| recreational purposes. (I'm not talking about people who
| really need pain relief from cancer, amphetamines for ADHD,
| etc.)
|
| If no one in the world drank, smoked pot, or did drugs, how
| much better off would we all be? 100,000 deaths come from
| alcohol use every year in the United States alone[1]. That
| doesn't even account for countless cases of abuse, broken
| families, crime, and other negative effects of alcohol and
| drugs.
|
| So many people say "oh well it's fine if I do it, I'm
| responsible" but then at some point someone isn't fine and
| isn't as responsible as they think they are.
|
| [1] https://www.cdc.gov/alcohol/features/excessive-alcohol-
| death....
| wpietri wrote:
| You haven't really thought this through.
|
| One, those substances are fine for a lot of people.
|
| Two, some of those substances are fine for most anybody.
| I've never even heard of a deadly marijuana overdose, and
| the evidence shows no increase in mortality for marijuana
| users.
|
| Three, we already tried alcohol prohibition, and we are
| currently trying drug prohibition. It does not solve he
| problem you care about, while creating other large
| problems.
|
| So really, you sound like somebody who has a personal
| hobbyhorse and uses pretty much anything (like say,
| losing stars on GitHub or mentioning a book on airplane
| safety investigations) to argue for it. And that sort of
| motivated reasoning around argument for societal change
| strikes me as way more dangerous than somebody eating a
| THC edible.
| dns_snek wrote:
| > If no one in the world drank, smoked pot, or did drugs,
| how much better off would we all be?
|
| Perhaps that's true for your definition of "better off",
| which is perfectly fine, but it isn't universal. Even
| though I don't do drugs, I don't think it should be
| anyone's business to police what other people do with
| their minds and their bodies on their own time, as long
| as they don't pose a threat to anyone else.
| mdoms wrote:
| ufmace wrote:
| I think that do-gooders who have a "Great New Idea" for
| how to make society better are 1000x more dangerous than
| any type of drug ever invented. People drunk on alcohol
| mostly fall asleep harmlessly. People drunk on power and
| how awesome their own ideas are launch prison-industrial
| complexes, dystopian enforcement schemes, wars,
| genocides, etc.
|
| It may be an even worse drug. People on drugs mostly have
| some awareness that their ideas aren't very good. But for
| those drunk on power, the fact that their same great idea
| has already been tried and led to total disaster is no
| cause for concern at all. You see, they're obviously
| smarter and better than the last batch of power-addicts
| who tried that, so they'll do it right this time. Heaven
| help us if we ever discovered a chemical intoxicant that
| was capable of making people that deluded.
| tdfx wrote:
| I'm scared to see what your sanitized world would look
| like. Some of the most interesting art, music, and
| personal perspective has come from the consumption of the
| substances you deride as unnecessary and destructive.
| axiomsEnd wrote:
| How much art, science and deep, personal perspectives
| were lost due to abuse and death stemming from substance
| abuse? In case of certain substances (like alcohol) we
| have rather hard statistics about it's overal impact on
| physical and mental condition of society. Slow change
| from alcohol to safer alternatives (ex. cannabis) is
| probably one of the best trends in current times.
| headsoup wrote:
| How many lives were saved or changed for the 'better'
| through the escape of, enjoyment of or numbing with drugs
| and alcohol? Who knows?
|
| Perhaps if we think more like adults instead of infants
| we can try to understand complex issues better instead of
| reinforcing black and white stereotypes of the world or
| rehashing whatever our favourite source of ignorance
| tells us.
| naedish wrote:
| An interesting thought experiment - how many of us would
| be here at all if not for alcohol? Ignoring butterfly
| effect aspects, the number of people who were only
| conceived due to decisions made under the influence of
| drugs would surely be very large even today, let alone
| prior to the availability of birth control.
| [deleted]
| cmeacham98 wrote:
| > My view is that expecting humans to stop making mistakes
| is much less effective than fixing the systems that amplify
| those mistakes into large, irreversible impacts.
|
| This is applicable to almost any activity: "Sure he was
| driving drunk, but the car's manufacturer should have
| prevented that from causing any damage!" I agree that
| GitHub should improve the design here - privating a '10
| star / 1 week old' repo shouldn't be treated the same as
| privating a '50k star / 10 year old' repo. I don't mean to
| diminish the fact that GitHub's UI should be improved here.
|
| But the author needs to take some responsibility and
| realize they were ""driving distracted"", and not act like
| GitHub is 100% at fault here. Just because GitHub didn't
| act perfectly doesn't mean the author didn't make any
| mistakes.
| barrkel wrote:
| Neither the author, nor anybody that I can see here, is
| saying that the author didn't make any mistakes.
|
| But what you _are_ saying is that marginal effort to
| prevent mistakes is not worthwhile.
|
| Cars, to take your example, would not be as safe as they
| are today if they followed the principles you've shown in
| this post and the grandparent. And yes, even when driving
| drunk, which is illegal, is safer too - stay in lane,
| adaptive cruise control, automatic braking, etc. have all
| incrementally made even extremely ill-advised behaviours
| safer.
| NeutronStar wrote:
| MichaelBurge wrote:
| The penalty for sin is death.
| JackFr wrote:
| Romans 6:23
|
| The _wages_ of sin is death.
| dheera wrote:
| What about cos?
| pbhjpbhj wrote:
| death + p/2
| xupybd wrote:
| Yeah, it's a different story when dealing with safety.
|
| With industrial machines you have to assume people will do
| the dumbest thing possible. Because someone will find a way
| to get crushed in a moving part if they can.
|
| You have safety fence after safety fence and regularly test
| that your lockouts work.
|
| If you don't do all of this and someone dies you can face
| very harsh legal penalties.
|
| We don't do this with software when the cost of failure is
| so much lower but we should still understand smart humans
| will make mistakes.
| jeffreygoesto wrote:
| In software often the cost is paid by other people (your
| users) and you don't (want to) see them. How much did the
| Atlassian outage cost it's clients altogether? How much
| thereof will they need to compensate?
| WalterBright wrote:
| My favorite is "let's imprison people who make mistakes".
| It doesn't stop mistakes, it just covers them up.
| db_admin wrote:
| People are imprisoned when they are a danger to others or
| at risk of flight. Their time in prison is meant to
| reform them and help them back into society. The
| community is protected from further "mistakes" from a
| person, while allowing the person to learn not to make
| the same mistake again.
|
| At least that is the idea.
| rob74 wrote:
| But still, I also share the opinion that GitHub's UX for
| dangerous actions on a repository is currently already best
| in class, so blaming them for your mistakes is pretty
| unfair. To make your repo private, you have to:
|
| - click "change visibility" in the "Danger Zone" area of
| the settings.
|
| - select "make private" with an additional warning shown
| that you will lose all stars and watchers. Ok, maybe it
| should mention how many.
|
| - type the name of the repo into a box and then click "I
| understand, change repo visibility".
|
| And yes, sometimes it _is_ important to expect humans to
| not make mistakes. For example, at railway crossings. Even
| if you drove over it 100 times and no train came, the 101th
| time you may still die if you don 't check for a train
| before crossing.
| dskloet wrote:
| That's why a level crossing has a barrier that's only
| there when a train is approaching. Imagine the barrier
| was always there; that would be asking for people to
| ignore it.
| MrBlueIncognito wrote:
| > And yes, sometimes it is important to expect humans to
| not make mistakes. For example, at railway crossings.
| Even if you drove over it 100 times and no train came,
| the 101th time you may still die if you don't check for a
| train before crossing.
|
| For somebody going through a railway crossing, yes, they
| shouldn't allow themselves to be prone any mistakes
| there. However, for the people involved in the
| construction of the railway crossing, they should
| certainly expect everyone to screw up and scrutinize the
| safety. We don't want to leave anything affecting
| livelihoods to chance.
|
| "On average, each year around 400 people in the European
| Union and over 300 in the United States are killed in
| level crossing accidents."
|
| https://en.wikipedia.org/wiki/Level_crossing#Safety
| [deleted]
| jonahx wrote:
| There is also an audiobook version, for some reason not
| linked from there:
|
| https://www.amazon.com/Field-Guide-Understanding-Human-
| Error...
| iforgotpassword wrote:
| So, displaying an additional or more explicit warning that
| mentions stars and watchers makes sense. No arguing, hope
| they do that. But to me also, it left a little bit of a bad
| aftertaste that the author _completely_ skips over the part
| of that process where you have to enter the repository name
| right where they show the two screenshots side by side.
|
| Anecdotal: You have to enter the full name for a couple
| destructive actions on GitHub, and every time I had to do
| it was so jarring to me that I stopped everything,
| rechecked what I'm doing twice, started wondering if I
| might be dreaming, am on drugs or a voice in my head is
| telling me to do something dumb. Like, yes we should
| improve nonetheless, and I usually try to put myself into
| other people's shoes before judging them, but this is just
| one of the few times where I just can't help but, you know,
| think it was somewhat dumb to make this mistake with the
| current system in place. Like, next time we have this stars
| and watchers warning in place and _still_ someone will
| manage to proceed on autopilot, what do we do next? Have a
| siren sound go off in addition? Have the user enable their
| mic and spell out the repo name? Send a written letter to
| GitHub? You 'll never get the error rate to 0, at which
| point would you rather accept people making mistakes and
| calling them out on it than adding more inconvenience on
| top that just bothers everybody else?
| bspammer wrote:
| Most people in this thread seem to be ignoring another
| very major cause: the inconsistent naming for personal
| READMEs between users and organizations. Users have their
| README at username/username, but orgs have it at
| orgname/.github
|
| Nothing else on GitHub is like this: orgs and users are
| treated as the same class of entity pretty much all the
| time. I could easily see myself making the same mistake
| on autopilot.
| _asummers wrote:
| They have a bunch of differences under the hood,
| particularly when you want to give perms. It makes sense,
| sort of, on its face, that a user can't have teams, but
| why? That decision is pretty arbitrary, to me. Then in
| GHE, users and orgs have all sorts of fun differences
| when you consider things like internal/public/private and
| how people can interact with them; to wit, if you're in
| ANY team you can see ANY internal repo in an org, but if
| you're limited to just personal repos, you can see no
| such things.
| krick wrote:
| Is that book still worth to spend time reading if I do
| understand what you are saying and I hold the same views?
| I'm always hungry to learn something useful from books, but
| more often than not I find these hyped books ("The
| Checklist Manifesto" comes to mind) really annoying in that
| they make me spend a significant amount of time reading
| stupid "curious life stories" to bring across a point that
| can be expressed in a 3 word sentence, like "checklists are
| good". And it's even worse when these are trivial truths
| most sane people would agree on, which doesn't make the
| "advice" more actionable, because it's just much easier
| said than done.
|
| I mean, it would be disappointing to read it to find it
| summarizes exactly to what you just said.
| wpietri wrote:
| It's an incredibly rich book. I learned a ton from it.
| Indeed, I avoided summarizing it here precisely because
| it's hard to sum up.
| [deleted]
| pishpash wrote:
| Agreed, the swipe at Microsoft (with links he saved from who
| knows when!) was especially gratuitous. He mad. Don't write
| something public when bitter should be a lesson right after
| don't be on autopilot.
| ncr100 wrote:
| I disagree because there is no UI to indicate you're in a
| special repo. And I blame GH for not considering this "large
| project maintainer" use-case.
|
| When I administered many VAX / UNIX machines waaay back, the
| terminals were all configured to be 'special' for the super
| user. It would have been HORRIFICALLY BAD if any command were
| executed unknowingly.
|
| GH does -not- distinguish for project sizes, so there is NO
| SUPPORT for its users in this way. Every feature is to be
| considered with the same "shotgun severity".
| rhtgrg wrote:
| > I specifically dislike the "Lessons" section, as it throws
| all the blame on github and doesn't mention the seemingly
| obvious advice: "make sure you're not on autopilot when
| taking potentially dangerous actions, on github or any
| website".
|
| I don't know. Github employees themselves have made this
| mistake as outlined in the post, and they were easily able to
| recover from it, which probably lowered the priority on
| changing any UX.
|
| Essentially, it's a complete non-issue _depending on whether
| Github cares about you._
|
| Would you like the police in your area to behave in this
| manner? I think not.
| input_sh wrote:
| I found GitHub's Senior Director of DevRel on Twitter
| saying this:
|
| > Sadly we can't easily do that without triggering lots of
| issue. We tried with a couple of projects in the past and
| found it caused a bunch of bad things to happen.
|
| https://twitter.com/martinwoodward/status/14933302894935162
| 9...
| bandyaboot wrote:
| > Essentially, it's a complete non-issue depending on
| whether Github cares about you. Would you like the police
| in your area to behave in this manner? I think not.
|
| Obviously it would be nice to see A similar response from
| GitHub regardless of whether the issue at hand is affecting
| themselves versus a member of their community. But, as long
| as humans are making the decisions, that's probably a pipe
| dream. And honestly, policing could very well be the
| standard example of this.
| jacobsenscott wrote:
| Idk about "easily", but I'm sure they were motivated. If
| you've ever tried to restore parts of a database in a
| piecemeal fashion, it is usually fairly labor intensive.
| But you would hope there are a few gh engineers who would
| be motivated to do so without manager approval in the dead
| of night because httpie is great.
| swiftcoder wrote:
| > But you would hope there are a few gh engineers who
| would be motivated to do so without manager approval in
| the dead of night because httpie is great
|
| On the other hand, you _should_ really, really, really
| hope that GitHub has internal guardrails to prevent their
| engineers making cowboy edits to the production databases
| without manager approval.
| jacobsenscott wrote:
| Haven't worked there, but I assume one engineer just
| needs one other engineer to approve their PR. I would be
| pretty surprised if it was more robust that that.
| katbyte wrote:
| I recommend reading "the design of every day things", it
| talks about this exact attitude and why it's terrible.
| tluyben2 wrote:
| It would be very rare to have lived through an IT career and
| not make one or two fatal autopilot mistakes. In the 90s and
| early 00s it was very easy to lose a production system
| because you did something wrong that you did 1000x times
| right before. And this is a modern version of it; for me,
| this should not happen; if I designed GitHub, these people
| giving stars and watch would get selected based on the
| visibility of the profile. That hardly costs anything and
| then the user can just switch between visible and invisible
| at will and not lose anything. But I have made many similar
| mistakes in the past which is why I don't delete stuff
| usually anymore; I just flag it deleted and gdpr material I
| encrypt. I simply don't want either software bugs, hacks or
| human error to cause any damage. With the cost of storage and
| the fact that I work only in b2b, this comes at virtually no
| cost but with a lot of happiness for both our users and
| myself.
| jagged-chisel wrote:
| > the author had to _type out_ the name of the repo
|
| I copy/paste the repo name every time I delete a repo on
| GitHub. Yeah, it's still a minor impediment, but it's
| definitely not "TYPE the account and repo name."
| vaishnavsm wrote:
| Sure, I understand that. But I think, as a designer, I can't
| really control the actions of my users. I can only try to
| design such that I can get them closer to the action they
| want to take. From that perspective, I think adding the
| additional information to the warning UI would, if not solve
| the problem, at least get us one step closer to helping the
| user make the right decision.
|
| Tbh, when I've deleted repo's, I've mostly just copied the
| repo name and pasted it in the box. Careless of me?
| Definitely. Can GitHub change that carelessness? Probably
| not. Will a box that says "Stars: 54k" help? I think it'd
| help me, at the very least.
| saila wrote:
| In addition to typing the repo name, maybe they should make
| you check a box for each type of item that will be deleted:
| [ ] Delete 54,000 stars? [ ] Delete 8,000 watchers?
| [ ] etc
| ncmncm wrote:
| Or just, you know, not delete anything until otherwise
| asked to. None of tha has anything essential to do with
| making the thing private.
| prepend wrote:
| Is the repo is private then it's impossible for anyone to
| "follow" by starring or watching.
|
| There's also an issue of taking a repo private, making
| changes when no one gets alerted, and making it public to
| make it harder for people to know what's going on.
| gpvos wrote:
| And, importantly, don't show an item if it has zero items
| in it.
| js2 wrote:
| > I specifically dislike the "Lessons" section, as it throws
| all the blame on github and doesn't mention the seemingly
| obvious advice: "make sure you're not on autopilot when
| taking potentially dangerous actions, on github or any
| website".
|
| First of all, this is self-evident. But second of all and
| more importantly: it doesn't scale.
|
| The reason we have blame-free postmortems is because people
| will always make mistakes, so we find ways to change process
| or design to minimize those mistakes.
|
| If you think you'll never do something on autopilot, you're
| fooling yourself.
| remexre wrote:
| Also sudo mode, right? They had to authenticate to the whole
| website again too, before doing this!
| JackFr wrote:
| I feel for the guy and what he says about user interfaces is
| all true, but the tone of the piece grates on me a little.
|
| "I take responsibility, but..." is not "I take
| responsibility."
| abnry wrote:
| How many years have we had to learn from people using
| programs to know that people make mistakes. Goodness knows
| how many people burned themselves using "rm". For that reason
| alone, "rm" is a bad tool, and should be replaced with
| something like trash-cli.
| [deleted]
| freedomben wrote:
| that would break billions of scripts and confuse the hell
| out of hundreds of thousands or millions of users.
| Especially seems unnecessary since most distros ship an
| alias that makes the default `rm` command run with the `-I`
| or `-i` command.
| abnry wrote:
| Of course it is here with us to stay. The point is that
| if the initial design was different, there would be fewer
| headaches. We certainly have the power moving forward.
| And as discussed in the article, a prompt is not enough
| to deter a user doing something other than what they
| think they are doing.
| mynameisvlad wrote:
| > Especially seems unnecessary since most distros ship an
| alias that makes the default `rm` command run with the
| `-I` or `-i` command.
|
| I would say that makes things _even worse_. Because it 's
| just training you to rely on -i/I as a sensible default.
| One day, you'll encounter that one distro that doesn't
| have that, and it'll be the time where you really wish it
| were.
| freedomben wrote:
| Hmm, interesting point. I removed that alias early
| personally in favor of giving due respect to rm
| (especially with a `-r`!), which is probably an indicator
| in your favor.
| alecbz wrote:
| I alias rm to `echo 'use trash'`, and then use /bin/rm
| when it's what I really want.
| forgotpwd16 wrote:
| >Especially seems unnecessary
|
| An option that shows a y/n action. That's what GitHub
| does when you're about to make private/delete a repo
| (even more asking you to type out its entire name) and
| yet here we're.
| viscanti wrote:
| Data privacy laws like GDPR probably require them to fully
| hard delete when a user asks for something to be deleted. So
| any undo functionality would need to make sure it's compliant
| in every region that could have a privacy law. I'm not sure
| how realistic it would be to ask companies like Github to
| jump through all those hoops because people refused to read
| (and then blindly typed stuff out).
| alpaca128 wrote:
| I'm pretty sure GDPR doesn't say everything must be wiped
| instantly but instead within a reasonable time period. One
| that's certainly enough to undo such actions.
| justinator wrote:
| Interesting idea but what PII is stored with stars?
| lucideer wrote:
| > _obvious advice: "make sure you're not on autopilot_
|
| That... isn't how "autopilot" (or humans in general) work(s).
| oriki wrote:
| Yeah, but on the other hand, "don't make mistakes" isn't a
| meaningful or useful lesson.
| wardedVibe wrote:
| git clone good
| pishpash wrote:
| Don't make this _specific_ mistake is a very meaningful and
| useful lesson.
| alpaca128 wrote:
| Yes. But without the possibility to undo mistakes you'll
| stand in ruins before you learned enough lessons.
|
| "Just don't make any mistakes" is the worst stance one
| can have in this context, it denies reality and only
| assures you're unprepared when (not if) something
| important goes wrong.
| mro_name wrote:
| Yes, and as Don Norman puts it, Design is mostly on how to
| make errors non-catastrophic. No design nor training ever
| will abolish them.
|
| Humans err.
| alasdair_ wrote:
| The problem is that this "seemingly obvious advice" is
| completely useless because it's not actionable. It's similar
| to saying "to avoid the mistake, just don't make the mistake"
|
| To make a better system for every human, you can either try
| changing all the humans, or you can change the system that is
| supposed to serve them. One is easier than the other.
| onion2k wrote:
| _GitHub probably should show the stars in the warning UI_
|
| In this particular case the stars would have been a useful
| clue, but in the majority of similar cases the wouldn't be
| any stars. It would be a useless and redundant signal.
| sjamaan wrote:
| Number of forks, maybe? Or pull requests? Although those
| wouldn't disappear of course...
| cycomanic wrote:
| I would argue that the fact that GitHub themselves made the
| same error really tells us that yes the UI makes it way to
| easy to do this. Considering the number of repos on GitHub I
| wouldn't be surprised if someone made the same error every a
| couple of weeks (but typically not with such high stakes).
|
| I would also say that post does not come across to me as he
| is only blaming GitHub.
| jdmichal wrote:
| I ran into this in pgAdmin recently. When right-clicking on a
| server, the options to disconnect the server and remove the
| server are right next to each other. Clicking disconnect
| presents you with the following dialog box:
|
| "Are you sure you want to disconnect the server? No / Yes"
|
| Click remove presents you with the following dialog box:
|
| "Are you sure you want to remove the server? No / Yes"
|
| Good luck! I mean, it's not a super huge deal to recreate the
| server entry, but still annoying when you're in the middle of
| something and just realized what you did.
|
| Honestly, just replacing the "Yes" button with the action being
| taken would be enough to improve this. "No / Disconnect" and
| "No / Remove". But my personal opinion is that disconnecting is
| not a destructive action unless there's an open transaction or
| running query. So the dialog box should be contextual on that
| scenario, and otherwise it should just disconnect.
|
| "Disconnecting will cancel executing queries and rollback open
| transactions. Continue? No / Disconnect"
| JJMcJ wrote:
| > just replacing the "Yes" button
|
| Or the lazy web dialog popup with "Cancel" and "OK".
|
| So you click on "Cancel Glorping The Frobnitz" and up pops a
| dialog with "Cancel" and "OK". It always takes a moments
| thought does the "Cancel" on the popup mean cancel the cancel
| glorping or cancel the cancel.
|
| Since it takes literally seconds to change the button
| captions it might be nice to think of something clearer.
| Seconds if you're a UI expert which I'm not. Of course the
| webdev part of changing the captions on the page really would
| be seconds for me to do.
| JJMcJ wrote:
| > mean cancel the cancel glorping or cancel the cancel.
|
| Typing error, it should be
|
| > mean cancel the glorping or cancel the cancel.
| [deleted]
| david_allison wrote:
| Would you consider submitting a patch?
| mherdeg wrote:
| > While the author clearly feels bad about the fact that
| they've lost his community and that GitHub couldn'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.
|
| Also, writing a solid blog post about a customer-service corner
| case and getting it to the top of news.ycombinator can be a
| great, if somewhat last-ditch, opportunity to escalate a
| problem.
| bokwoon wrote:
| > I assume that the cascading done on GitHub would be done on a
| FK constraint
|
| GitHub doesn't use foreign keys, the cascade delete must have
| been manually implemented.
|
| https://news.ycombinator.com/item?id=21486494
| ncmncm wrote:
| That it took a half hour to do all the pointless activity
| says something.
| sriku wrote:
| He did have to type "httpie/httpie" in the box to confirm, no?
| I'm rather surprised that that didn't snap him out of auto-
| pilot mode. There ought to have been a DING in the brain seeing
| that the repo this is being applied to was httpie/httpie?
|
| OTOH, I haven't been in such a mode, so I really got no right
| to comment on this. Best wishes to the team -- that those who
| saw his post will restar/rewatch the repo -- and (fwiw) thanks
| for writing it up and making me even more paranoid (in a
| positive sense) about doing such destructive operations.
| ignoramous wrote:
| All the talk about auto-pilot mode reminds me of this
| excellent talk on activation energy, waking up yourself from
| slumber, or flip-flopping between _auto-pilot_ and
| _emergency_ modes: Mel Robbins, _How to stop screwing
| yourself over_ , https://www.youtube-
| nocookie.com/embed/Lp7E973zozc
| decafb wrote:
| By now I've become so accustomed to just copy the bold text
| from the line above it and paste, that it doesn't break me
| out anymore. I know I should concentrate and type it out, but
| in my head it has just become visual noise and a boring
| exercise.
| [deleted]
| [deleted]
| SkyBelow wrote:
| >I often think scary popup boxes are enough to get people to
| think about what they're doing
|
| This would entirely depend upon how often it shows up. The more
| often it shows up when the scare isn't relevant, the less
| people will pay attention to it.
|
| >the distractions ("Type this repo's name", etc) just go away
|
| I think it shows that what one types needs to be relevant
| information. In this case, due to the similarity between when
| the author would've been asked if they did what they were
| intending to do and what they typed to do what they actually
| did, we can judge the prompt isn't enough. If this also asked
| you to type in the number of git stars you were about to lose,
| that would've been enough to make author recheck exactly what
| they were doing.
| CodeWriter23 wrote:
| I've adopted a pattern of:
|
| <dialog-text>
|
| If they click ok:
|
| Asking again to be sure you want to destroy masses of data
|
| <dialog-text>
|
| But even that fails if there is a language barrier.
| organsnyder wrote:
| > But even that fails if there is a language barrier.
|
| Surely GitHub is localized? (and if not, why the hell not?)
| sparqlittlestar wrote:
| 411111111111111 wrote:
| > _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?_
|
| Couldn't you just use an on delete trigger for this? I have no
| experience one the subject however
| nine_k wrote:
| An ON UPDATE trigger for the is_deleted column would do.
|
| Some databases also support INSTEAD OF triggers.
| metaltyphoon wrote:
| > I'm not really sure how you'd do a "cascading soft delete"
| without making some kind of manual cascading logic?
|
| Perhaps the delete action is not accomplished right away and a
| column is checked. Then after a X amount of months a worker
| process goes around actually deleting things?
| vaishnavsm wrote:
| I meant to focus on the cascade part of the equation here.
| For example, lets say `stars` are foreign keyed (FKed
| henceforth) to repos, and (say) `X` are FKed to `stars`, and
| `Y` is FKed to `X`. Then if you do a "hard" delete of the
| repo status (or the stars), then we can set that to cascade
| to `X` and `Y` as well. Otoh, I don't think you can apply a
| cascade like that automatically when you're just changing a
| value (which is how a soft delete would be implemented, ig).
| Can you? Is there some really cool hook that allows this?
| [deleted]
| ncmncm wrote:
| There is no need to delete anything at all. Set the "private"
| flag when the user asks for to make it private. Unset the
| "private" flag when they make it public again.
|
| If it is needful to be able to delete stars, make a separate
| button for that. But it is hard to imagine such a need.
| mypalmike wrote:
| Stop. You've said the same thing a dozen times in this
| thread. Besides being repetitive, you're overlooking the
| obvious fact that having associations from non members of
| private repos to those repos is problematic. At the very
| least at the UI level, maintaining known dead internal
| links is bad form. So you'd be creating edge cases for the
| UI and probably numerous places deeper in the tech stack as
| well. Which is fine if you engineer solutions to all the
| edge cases. Perhaps after this incident they will consider
| doing so. But it's certainly not as trivial as you imply.
| ncmncm wrote:
| Yet... and stay with me, here, 'cause I know this will be
| hard for you... it is. It really just is.
| mypalmike wrote:
| A childish response.
|
| Feel free to address the points that I and others have
| brought up.
| fer wrote:
| Mmh? Maybe it's because I've never touched frontend
| professionally in my life, but I think that if you're
| doing it in the UI you're doing it VERY wrong.
|
| This logic should be purely in the DB model or very close
| to it. In any case the internal API should never ever
| list private repos of an organization a user isn't a
| member of, period. Stars or no stars. Follows or no
| follows. Why should it? There's no corner case here, if
| stars pose a problem, the problem isn't the stars, it's a
| defective model behind. Hiding things that aren't meant
| to be seen in the UI means putting business logic in the
| UI. Just don't.
| mypalmike wrote:
| Fair point. My intent was to point out the UX would be
| broken. But you're right, the data model that backs that
| UX is what would have to change.
| brightball wrote:
| The complicated thing is that every query has to look for the
| column.
|
| Ideally, moving the entire serialized record to an archive
| table keeps things as clean as possible.
| zach_garwood wrote:
| > 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?
|
| I'm not at a terminal, so I can't check it out, but could you
| make a compound foreign key with the soft delete column and use
| the on update cascade? Something like `alter table stars add
| foreign key (repo_id, is_deleted) references repos (id,
| is_deleted) on update cascade;`
| berkes wrote:
| Github is built with MVC. On rails no less. Where problems like
| soft delete are hard, or even impossible to solve (in scale).
|
| Yet there are many architectures beside MVC. Many of them
| decades old. Proven. Established. Yet unknown to devs who
| picked up a rails book on day 1 and never looked back (I've
| been guilty of that for years).
|
| This particular problem is a textbook candidate for Command
| Pattern. The problem of undo is solved naturally in any event-
| sourced setup (git is even sourced, and moving through history
| a prime feature). Probably more architectures that I'm less
| familiar with, solve 'undo' as well.
|
| But we are stuck with the web, backends in 2022, being built on
| MVC frameworks like Rails, where solving such issues is tough
| and complex. So we are stuck with a huge amount of warning
| dialogs to 'solve' this.
|
| Point being: choose your architecture well, based on your needs
| and the tradeoffs. Don't just grab the next fancy framework,
| because that will decide for you, if, and how you solve things
| like 'soft delete' or 'undo'.
| legedemon wrote:
| https://github.com/rubysherpas/paranoia is enough to solve
| problems at very large scales.
|
| There is nothing about Rails or MVC preventing someone from
| doing this. This is a very common design principle for all
| kind of ERP and BPM systems: don't ever delete anything.
| berkes wrote:
| First: soft-delete really doesn't need a library. Paranoia
| is nice, but almost all of the code and complexity in that
| gem is to support multiple versions of rails and to let you
| configure that gem.
|
| DIY in this case really is very simple. And far more
| flexible, performant even, and future-proof.
|
| (I've worked on a project where two full-time devs spent
| _days_ upgrading this gem; this is over 6 years ago). And a
| few months ago, I worked on a project where they had _more_
| code to configure, patch and work around paranoia, than any
| DIY ever did. My even simpler DIY version not only used 50%
| of the code we had to override the gem before, it allowed
| for some custom work that we could not do before.
|
| And no: even DIY ain't as simple as you make it seem.
| Practical issue, that I encountered last year even, was
| where their "soft delete" was making state-machines very
| tough. Because in a FSM, "deleted" wants to be state, like
| anything else. But the "generic soft-delete" conflicts with
| that. So the project had both. And some fugly glue-code to
| sync between the FSM and the soft-delete and vice-versa. No
| suprise that this broke occasionally, making data re-
| available that people thought gone.
| realusername wrote:
| I don't see why you are thinking it's hard with rails, you
| just create a default scope in your model "not_deleted", and
| that's done.
|
| It will apply to all queries unless you specifically call "
| unscoped"
| agraddy wrote:
| I'm in the process of creating an MVC framework and was
| curious about the other architectures you mentioned.
|
| This comment seems to be down on MVC and Rails so I was
| curious about the alternatives you mentioned and came across
| your post that ended with praise of Rails (
| https://berk.es/2022/03/08/the-waning-of-ruby-and-rails/ ):
|
| > Rails still is a great way to get a prototype demo, or
| minimum viable product online in days with least surprises.
|
| Your comment seems to indicate that you started discovering
| new architectures like the Command Pattern but it sounds like
| you are also still a proponent of Rails and MVC based on your
| blog post. Do you have any links to resources that helped you
| discover other patterns or could you share what took you on
| your journey?
|
| In the Rails blog post, you said:
|
| > I have a separate post planned on "RAD web frameworks", MVC
| and ActiveRecord, but it is safe to say that such frameworks,
| amongst which Rails, have found their niche, yet are by no
| means a silver bullet.
|
| Is that post you are planning to write going to delve into
| some of the architectures you mentioned here? That would
| definitely be something I would be interested in reading.
| berkes wrote:
| I'd suggest going through all Uncle Bob Martin[1]s talks on
| clean code.
|
| He has a great article (2014), old, on why you may not want
| to build that framework at all[2] too:
|
| > Using a framework requires a significant commitment. By
| accepting the framework into your code, you surrender your
| control over the details that the framework manages. [...]
| > And yet despite the huge commitment you've made to the
| framework, the framework has made no reciprocal commitment
| to you at all. That framework is free to evolve in any
| direction that pleases its author.
|
| Another great source are the books, and/or youtube channel
| by Dave Farley[3]
|
| What set me on a journey is -decades ago- the pain I, as a
| developer felt when developing web-applications for my
| clients. But worse: the pain they felt for getting
| delivered crap. "Why am I delivering crap" was the question
| that set me to research frameworks, languages, design
| patterns and architecture. Drupal, Rails, Django, ASP: I've
| worked with it, and delivered crap with it.
|
| In general, I found that a framework matters. e.g. the
| simple act of reading ActiveRecord Critisism on
| wikipedia[4] got me thingking:
|
| > also due to the strong coupling of database interaction
| and application logic,
|
| This was true for project D, G and Y! This was why we
| failed to iterate at any speed at all. Because I can relate
| it immediate to Real And Actual Problems, Failed Projects,
| Slipped Deadlines, Burned out colleagues, and so on, all of
| wich I encountered during my career. Not saying all those
| problems were _caused_ by ActiveRecord or Rails! But that
| they were caused by the choice for the wrong framework. Or
| the choice for a framework at all.
|
| It led me to DDD[5], which then is the gateway into all
| sorts of Enterprise Patterns. I dislike that name, because
| the connotation is all wrong. Especially the subtitle of
| the canonical book on DDD struck a note:
|
| > Tackling Complexity in the Heart of Software
|
| This! This is why I'm delivering crap: I fail to tackle the
| complexity that inherit in any domain. In e.g. Rails, I
| would just spread it all over the place, fighting against
| ActiveRecord and Rails, yet still failing to isolate,
| modularize and capture that domain.
|
| So I no longer use Rails, nor any framework in my startup.
| I occasionally do some freelance gigs, often Rails. And the
| more I learned how to Tackle Complexity in the Heart of
| Software through choices and tradeoffs, the more I see why
| a project in Rails that I'm flewn in to salvage, is doomed.
| It's the choice for Rails. Not lacking of services, not
| "Fat Models", not "missing tests" nor missing of any sort
| of "rigorous refactoring" Its Rails! Rails is just unfit
| for this domain, this problem, this customer.
|
| Yet Rails shines for others: I restate: It's brilliant for
| simple CRUD. But anything you expect to have any sort of
| "Complexity in the heart" is probably unfit.
|
| [1]
| https://www.youtube.com/channel/UCCfqyGl3nq_V0bo64CjZh8g
|
| [2] https://blog.cleancoder.com/uncle-
| bob/2014/05/11/FrameworkBo...
|
| [3]
| https://www.youtube.com/channel/UCCfqyGl3nq_V0bo64CjZh8g
| (his books are promoted on this channel)
|
| [4] https://en.wikipedia.org/wiki/Active_record_pattern#Cri
| ticis...
|
| [5] https://martinfowler.com/bliki/DomainDrivenDesign.html
| agraddy wrote:
| Thanks for the detailed breakdown! This is really helpful
| and exactly the kind of information I was hoping you
| would share.
| h3mb3 wrote:
| 1. Why would it be particularly difficult for them to have
| soft deletes in Rails or at scale?
|
| 2. Like the article suggests, additional UX improvements
| could be made besides making it possible to restore a backup
| or providing an undo action.
|
| 3. I feel you are ignoring the fact that technology-wise it
| was probably Rails along with its MVC model that got them
| into their scale in the first place.
|
| 4. Had they focused on a more exotic architecture from day
| one, the UX of other features on the site could've been
| significantly worse.
| berkes wrote:
| > 1. Why would it be particularly difficult for them to
| have soft deletes in Rails or at scale?
|
| I don't know the internals of Github. But we had soft-
| delete dragging down our database. Indexing, for one,
| becomes tough.
|
| It also presumes everything lives in a single, canonical,
| transactional database. In real life, anything of scale,
| with legacy lives in multiple services. There'll be caches,
| search-indexes (elastic etc), data-lakes, leader/follower
| clusters and whatnot. Propagating a "delete" command is no
| easier or harder in such a setup, than propagating a "flag"
| which has severe business and security implications.
|
| 2. Like the article suggests, additional UX improvements
| could be made besides making it possible to restore a
| backup or providing an undo action.
|
| Yup. My point was that with e.g. Event-sourced or Command
| pattern, you don't even need that whole UI in the first
| place. There could be a 20 minute "undo" somewhere. Or an
| "undo" that remains active untill another non-compatible
| command renders undoing unavailable. This is a common
| pattern. Which was invented decades ago, and is still used
| everywhere to solve this exact problem.
|
| Why invent dialogs, soft-deletes, etc, when the problem is
| solved, done and non-existent, given you make the right
| choices? Why do software engineers insist on re-inventing
| wheels every few years rather than grab existing, proven
| and solid solutions for this?1
|
| 3. I feel you are ignoring the fact that technology-wise it
| was probably Rails along with its MVC model that got them
| into their scale in the first place.
|
| Why do you feel this? Rails comes with tradeoffs. I'm not
| saying "rails was a bad choice" But I'm saying "the choice
| for Rails brings the tradeoffs that e.g. Undo is hard".
|
| Saying that "it is easy in Rails" is both disingenuous and
| unfair: there are hundreds of Gems, some of which grown to
| enormous project almost the size of entire ActiveRecord
| itself, to tackle these problems: it isn't easy.
| Papertrail, for example is a magnificent monster. "just
| drop in papertrail" really is not a solution, it's a
| problem.
|
| > 4. Had they focused on a more exotic architecture from
| day one, the UX of other features on the site could've been
| significantly worse.
|
| I.e. "tradeoffs".
|
| 1 The answer, I'm afraid, is a mix of the doubling-of-
| developers-every-four-years (forever september), NIH, and
| unwillingness to invest time in learning the foundations
| layed out in the past decades. The last is what bothers me
| most.
| ezfe wrote:
| Factorio doesn't say "You'll lose unsaved changes" if you close
| the game immediately after saving, which is super nice.
|
| The number of games that DO ask this question, immediately
| after saving, is ridiculously high it's so frustrating.
| nosefrog wrote:
| 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...
| mekster wrote:
| That's one of the exact phrases you don't want to hear from a
| tech department.
|
| They make tech excuses which were ultimately their own design
| and tell that's not possible to be fixed.
| tester756 wrote:
| Why do they even delete those stars?
| akerl_ wrote:
| When the repo goes private, people who can't see it any more
| can't have it in their list of starred repos.
| mekster wrote:
| It's just bad design never getting fixed despite several
| prior incidents except for GitHub's own project which they
| reverted.
|
| Why do they not just give a public/private flag on star data
| than somehow modifying the data irreversibly?
|
| For users, just remove the repo from their starred project
| list if it's not visible.
| tester756 wrote:
| why not just do not display it and keep stars?
| munk-a wrote:
| So mark the repo as private without their permission to view
| and have queries for starred repositories ignore repositories
| you can't view - that's an extremely frequent approach to
| take with complex permission and social functions. I
| completely understand that not everyone has time to build
| everything and software is an evolving process - but soft
| deletion for social links is my default state of mind (then
| you overlay it with indexing or caching or whatever your
| performance flavor is to make sure those soft deleted rows
| don't exist in the active query space).
| akerl_ wrote:
| I mean, they totally could have built it that way. But they
| didn't. I was answering why stars were removed.
|
| From a data complexity standpoint, it sounds like they
| decided they didn't want to have to make calls to the
| authorization layer when parsing a user's stars. The
| downside is the behavior seen when a repo goes private, but
| my bet is that repositories being made private is far less
| frequent than calls to get a list of starred repos.
| munk-a wrote:
| I totally get that - it's not an insane design decision
| it's just different from what my default suggestion would
| be. And to be honest - your source of truth database, on
| a system of this scale, is likely going to be detached
| from your pool of active data (possibly with some data
| shadowing, caching - what have you).
|
| The thing that throws me off is that they shot themselves
| with this footgun - whenever we (munk-a's employer)
| footgun ourselves we remove the footgun to prevent future
| footgunnery. They made the original design decision one
| way, and when they were burned by it they didn't re-
| examine it.
| akerl_ wrote:
| FWIW, if the blog post had centered around "GitHub, it's
| strange to me that you made this mistake and didn't
| reevaluate the root causes, and now I've made the mistake
| and it sucks", I'd not be griping all over the comments
| here.
|
| It's the framing that GitHub has inflicted a deep,
| irreparable wound to the author that I can't reconcile
| with the facts.
| Dylan16807 wrote:
| > From a data complexity standpoint, it sounds like they
| decided they didn't want to have to make calls to the
| authorization layer when parsing a user's stars.
|
| You can also solve that by adding a flag column, or
| putting privated stars in a different table. That tiny
| bit of denormalization shouldn't be more expensive than
| the current process, or the other costs of
| privating/unprivating a repo.
| Dylan16807 wrote:
| Why not?
|
| I think the respectful solution is to show it as "you starred
| X, it's private now, you can unstar if you like" (make sure
| if the name changes privately then the new name isn't shown).
|
| Such a solution is not only good in the case of mistakes like
| this, it also doesn't gaslight the person that starred a repo
| only for it to disappear from their list.
| calcifer wrote:
| > it also doesn't gaslight the person that starred a repo
| only for it to disappear from their list.
|
| It's honestly hilarious how the definition of 'gaslight'
| has expanded so dramatically in the past few years that it
| now means 'anything that confuses me'.
|
| For future reference, here's what it _actually_ means [1]:
|
| > Psychological manipulation of a person usually over an
| extended period of time that causes the victim to question
| the validity of their own thoughts, perception of reality,
| or memories and typically leads to confusion, loss of
| confidence and self-esteem, uncertainty of one's emotional
| or mental stability, and a dependency on the perpetrator
|
| Github did none of those things to you.
|
| [1] https://www.merriam-webster.com/dictionary/gaslighting
| jacobolus wrote:
| The origin of "gaslight" is a movie where a husband
| surreptitiously removes objects from the room, dims and
| brightens the lights, etc. and pretends the changes were
| just the wife's imagination.
| https://en.wikipedia.org/wiki/Gaslight_(1944_film)#Plot
|
| Removing bookmarks from someone's list without
| notification seems at least broadly comparable (in both
| cases, the victim is confused and might question their
| own memory, because the state of the world changed in an
| incongruous way), though it is the action of an
| emotionless machine with a programming bug rather than a
| malicious human.
| calcifer wrote:
| > albeit the action of an emotionless machine with a
| programming bug rather than a malicious human
|
| Yes, if you remove a major part of the definition
| (intent) then it can fit whatever you want it to fit.
| Like Gino D'Acampo most famously said [1], _if my
| grandmother had wheels, she would have been a bike_.
|
| [1]https://www.youtube.com/watch?v=A-RfHC91Ewc
| alecbz wrote:
| I think it's a fair use of the term. I'd maybe feel
| differently if there was a better term to use for "non-
| intentional gaslighting", but afaik there isn't really.
| JetAlone wrote:
| How about we coin a term today, "LEDlighting"?
| (Pronounced Led-Lighting).
|
| "When a digital platform's state is altered in an opaque
| way without input on the user's behalf that directly
| commanded it to, and as a result causes them to question
| reality in the form of either their memory, the actual
| state of the system itself, or whether or not the system
| was intentionally made to do it by an unseen human."
|
| Shadowbans, whether you think they're a good form of
| moderation or not, would be an example of LEDlighting.
|
| In a game if the chat system stops working but the rest
| of the game works and everyone thinks they have been
| muted for some unknown infraction of the rules by an
| overreaching moderator, that's also LEDlighting.
| Dylan16807 wrote:
| Removing something from my personal bookmark list, with
| no notification, does in fact lead me to question the
| validity of my own memories.
|
| That fits just fine with simpler definitions like "To
| mislead someone such that they doubt their own memory,
| perceptions, or sanity."
|
| It's an expansion from the original context but I don't
| think it's an unreasonable expansion.
| [deleted]
| munk-a wrote:
| Or even make it so that those starrings that no longer have
| permissions to view the starred item just effectively don't
| exist because of data rules.
| Dylan16807 wrote:
| That's bad because it lies to users and you can't remove
| the star when it's in that state.
| munk-a wrote:
| But if your star doesn't effectively exist why does that
| matter?
| Dylan16807 wrote:
| Because if the star is merely hidden then the repo can
| come back later. If you don't want any association with
| that repo any more, it's bad that it can put itself back
| into your starred list.
| akerl_ wrote:
| This may be the most hilarious misuse of "gaslight" that
| I've ever seen.
|
| If I publish something and you save the link and then I
| decide "nah, I don't want that to be published", I haven't
| gaslit you.
| Dylan16807 wrote:
| I think you misunderstood.
|
| If you remove the content, that's fine.
|
| If you make the link itself disappear from where I saved
| it, that's gaslighting.
| akerl_ wrote:
| Neither one of these is gaslighting.
| nybble41 wrote:
| Sure, to really count as "gaslighting" there has to be a
| deliberate attempt to make someone doubt their own
| sanity. I think we can rule out malicious intent in this
| case. However, when you save a link to something and then
| later come back to find the service acting like the link
| never even existed, as opposed to telling you that it was
| removed, that can feel pretty similar even if it's not
| intentional.
|
| A user's list of starred repos shouldn't be silently
| abridged just because one of the repos was removed or
| made private. A placeholder should be left indicating
| that the repo _was_ once starred but is currently
| unavailable.
|
| This is something I always found annoying about Google
| Play Music also; when they removed a track from their
| service it would just silently disappear without a trace
| from your playlists, so unless you saved a copy of the
| list somewhere and compared them you might not even know
| to look for it elsewhere. You're just left vaguely
| wondering why that song never comes up in the shuffle any
| more. YT Music is a bit better about this--they generally
| leave a grayed-out placeholder. Sometimes the metadata is
| lacking but you can at least see where it _was_ and know
| that a track was removed.
| throwaway0x7E6 wrote:
| >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
| aerovistae wrote:
| They did admit they fucked up. Then they tried to make the best
| of it by looking for possible ways of preventing other people
| from repeating their mistake.
|
| What did you want? A blog post that says "I suck, I'm a
| failure, thanks for reading"? Why is this your response to
| someone trying to be contructive while post-morteming a
| failure?
| throwaway0x7E6 wrote:
| the guy with 10+ experience of using github went to the
| "danger zone", pressed the red button, saw the very, very,
| very explicit warning about the consequences of pressing it
| and confirmed the action by explicitly typing the exact name
| of the repository.
|
| yes, that blog post would've been apt. as constructive as it
| gets.
|
| >Why is this your response
|
| because I don't want to send a notarized request every time I
| need to delete a folder, format a disk or submit a SQL query
| BeFlatXIII wrote:
| This response would get you laughed out of the medical
| software industry (but welcomed with open arms by CMIOs and
| hospital administration). Physicians are known to click
| through all kinds of red-flag warnings because the legal
| team insisted they all be turned on to maximize patient
| safety.
| user_7832 wrote:
| > because I don't want to send a notarized request every
| time I need to delete a folder, format a disk or submit a
| SQL query
|
| Aah yes, the only 2 extreme options, no/minimal warnings
| and extreme warnings. _" Who needs rationality or subtlety
| on the internet anyway?"_
| 8note wrote:
| Admiring that you screwed up is one thing, but action items
| coming out of it should prevent somebody else from screwing up
| in a similar way.
|
| One typical way is to add a confusing confirmation box, where
| saying yes leaves things as is, but "I want to demolish the
| house" is in a different location that the typical yes/no
| buttons
| chociej wrote:
| They admitted exactly what they did. This experience is still
| really bad UX IMO.
| sorokod wrote:
| None of the "Lessons learned" are of personal nature -
| unbelievable.
| terrymunro wrote:
| I know, I'm seething at how many people are supporting this
| person.
|
| I would be on his side too if he started with accepting his
| part in this and took responsibility but he clearly blames
| GitHub for everything and learned nothing from this. Such
| arrogance, let's see if HTTPie will have a nice warning every
| time you try to do a http delete command.
|
| I've done something similar to this and took responsibility. I
| accidentally deleted an Azure Resource Group with the CLI tool.
| It just says "Are you sure you want to do this? Y/n" Doesn't
| even tell you what you're deleting. Oh whoops all the resources
| within that resource group are now irreversibly gone now.
|
| My lessons learned was, when doing something potentially
| dangerous no matter how unimportant you think it is, slow down
| and take your time.
|
| Things such as making a repo private or deleting things are
| relatively infrequent. It doesn't hurt to take a few minutes to
| carefully check all the variables before doing anything. You
| aren't losing much time in the grand scheme of things. Now he's
| definitely lost more time. Was it worth the few seconds you
| would have saved if you were on the right thing?
| sorokod wrote:
| Your comment about HTTPie DELETE (or any other verb that
| changes the system state) points at the exact problem: what
| is the right balance between giving the user the power and
| preventing the user from shooting themselves in the foot.
|
| For example, should _" my brain switched to auto-pilot mode"_
| be seriously considered as a risk to be mitigated?
| pbhjpbhj wrote:
| >"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.
| hk__2 wrote:
| > If a project is made private, I still want to have the star
| in my account list
|
| You can't star a private project, so by definition you can't
| "keep" a star on a project that went from public to private.
| That's not bad design, that's a logical behavior.
| pbhjpbhj wrote:
| >so by definition you can't "keep" a star on a project //
|
| That doesn't seem to follow. It's not intrinsic, it's a
| design choice, surely.
| forgotpwd16 wrote:
| >Projects I star are a characteristic of my account.
|
| What about deleted repos? Should those be maintained as well?
| pbhjpbhj wrote:
| I wasn't thinking the repo would be maintained beyond the
| title (and short description, maybe whole readme?) being in a
| list of starred repos, and maybe having something like "[now
| private]" or "[removed]" added.
|
| If I know I starred a repo and then go back to it and it's no
| longer accessible, I want to see that I'm not going mad and
| have some information about why the repo is no longer
| accessible.
| yowlingcat wrote:
| 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.
| paxys wrote:
| "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?
| [deleted]
| googlryas wrote:
| Note the repository names here are "httpie/httpie" and
| "httpie/.github". I don't use github(but I do use git), but the
| difference between the two is not exactly clear to me.
|
| They could show you the number of stars, follows, commits,
| creation date, the number of files, all sorts of things.
|
| Also, note that github themselves accidentally set one of their
| repos to private, but restored it to a previous state through
| backups. If the move is so boneheaded, why did github make it
| themselves?
|
| A better question might be why, after making the mistake(which
| was big enough for the CEO to tweet about), and restoring from
| backups, they didn't just fix the glitch and prevent this sort
| of behavior.
| ccheney wrote:
| Also seems a bit suspect that they had a "perfect UI/UX
| example" to show how they would have handled these dialogs. Is
| this whole thing an advertisement for HTTPie?
| pharrington wrote:
| As much as I dislike the general tone of the blogpost (as
| well as specifics like expecting special treatment (ie
| restoring a backup) in exchange for money when 1) Github
| doesn't offer that as a standalone service and 2) that wasn't
| already in their contract), I don't see how the example UI is
| anything but a straight improvement.
| hnlmorg wrote:
| I've never liked those "type this string to confirm" dialogs.
| It doesn't actually tell me what I'm confirming aside from the
| name of it (and names are easy to get muddled up if you're
| tired or rushing through something). What's more, dialogs like
| that encourage people to copy/paste those often long strings,
| which completely sidesteps the diligence they're trying to
| encourage.
|
| Whether you agree with the tone of that article or not, the UI
| suggestions made are sensible. Showing the contents of the repo
| you're about to change is a lot more useful than asking someone
| to type the name of it.
| Dylan16807 wrote:
| > 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?
|
| It makes you type user/repo, which is different in a serious
| way. It's easy for the difference between ".github" and
| "httpie" to set off alarm bells. But the difference between
| "httpie/.github" and "httpie/httpie" can slip through.
|
| > "It's their fault, they only showed 5 warning banners. A 6th
| one would have totally stopped me from doing this."
|
| The request is for the warning to say how much will be deleted,
| not to add another step.
| kemitche wrote:
| There's more nuance there:
|
| > I didn't realize at the moment there's an inconsistency in
| the naming of this special repo containing profile READMEs and
| that it differs for users and organizations: name/name vs.
| name/.github.
|
| It's not unreasonable for the author to have taken the action
| they did given what they were trying to do. The inconsistent UX
| for User vs Organization READMEs is a major factor in how the
| error happened.
|
| And given the number of single-repo orgs where the org's main
| product repo name == the org's name, well, it's not as
| surprising I'd say.
| farmerstan wrote:
| I came in to say precisely this. It's easy to point fingers
| after the fact but probably the person wouldn't have checked
| regardless of the message in the dialog box.
|
| "They warned me but because I didn't read the dialog box
| because it was too boring!
| sbarre wrote:
| if you RTFA he did actually read the dialog box (which is
| where he found out that it would delete the stars) he just
| didn't notice the 1 line in a 30+ line generic modal.
|
| He accepts responsibility for what he did, but points out the
| very real opportunity to improve the UI/UX of a very
| destructive operation with real contextual data about what is
| about to be destroyed.
| farmerstan wrote:
| I did RTFA. I do not accept the excuse that he didn't read
| it properly. He skimmed it because he thought it was the
| same box but it wasn't. He even admits that it contained
| the exact information that he was looking for. I don't see
| any way he can complain.
| sbarre wrote:
| Ok then.
|
| I hope others are less judgmental of you than you are of
| them next you make a mistake in life.
| farmerstan wrote:
| I take ownership over my mistakes. I don't try to blame
| others. The world would be a better place if everyone did
| that.
| sbarre wrote:
| I believe the world would be a better place if we all
| showed a bit more compassion towards each other, but
| let's agree to disagree.
| farmerstan wrote:
| I am very compassionate towards their loss. It must suck
| to have mistakenly destroyed their community. However I
| draw the line when they falsely blame others for their
| own mistake.
|
| You can be compassionate for a mistake and still insist
| someone take ownership over this own careless error
| instead of blaming others. You mistake compassion for
| "let them do or say whatever they want because they are a
| victim".
| pharrington wrote:
| You can only confirm the dialog box by _typing in_ that
| line you 're saying he didn't notice.
| Brian_K_White wrote:
| Reads article and somehow misses it's entire thoroughly
| examined point, chides author for not paying attention.
| pharrington wrote:
| If I understood the blog post correctly, the author wants
| the "You will PERMANENTLY lose: All stars and watchers
| from the repository" to be changed to "[...] _X stars_
| and _Y watchers_... " Which I agree would be a better UI.
| cycomanic wrote:
| Like so often we can easily judge this by how willing we
| would be to accept the same behaviour in real life and
| I'm pretty certain that most would not accept an UI where
| you could e.g. just give away your house by writing the
| wrong adress into some form.
| Brian_K_White wrote:
| The article spent significant space describing exactly what,
| and why.
| burnished wrote:
| Yeah, I also found that tone sort of jarring, but they do bring
| up a good point; the warning banner and inputs should be
| contextual and having to input the number of things affected
| would be a UI improvement. And I can understand why they would
| write this in anger/frustration.
| mattcwilson wrote:
| I'm curious which statements from the article carried that
| tone?
| burnished wrote:
| I think in the "But theres a confirmation box, right?" and
| if I had to quote a portion I'd quote
|
| >>"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."
|
| >>"The dialog should be more contextual and, paraphrasing
| again, it should say "You're about to kill 55,000 people."
| That would've certainly made me pause."
|
| Theres something about the juxtaposition that makes it feel
| like it should have been obvious. I think its because in
| those examples you would blame whoever didn't put whatever
| guard rail was necessary to prevent those outcomes. My
| suspicion is that it wasn't the authors intent and they
| were probably just upset, but thats an opinion I formed
| after reading the rest.
| mattcwilson wrote:
| Thank you for quoting. I see where you're coming from -
| the comparison to killing people is pretty hyperbolic.
|
| Do you agree that, hyperbolic metaphors aside, the UI
| improvement suggestion is a good one?
| [deleted]
| bradgessler wrote:
| 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.
| HL33tibCe7 wrote:
| 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
| ncr100 wrote:
| I read it.
|
| I think there should be a follow-on discussion here about
| programming paradigm that empowers a "do what I mean not what I
| say" mentality.
|
| Atlassian's recent fiasco
| https://www.atlassian.com/engineering/april-2022-outage-upda...
| is another motivating example for such a paradigm.
|
| The author of the blog touches on this paradigm as a UI
| element. Software engineers should have pushed that as a
| "gotcha" up through Product Management to expose controls for
| such a risky scenario.
| forgotpwd16 wrote:
| 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.
| jamesmishra wrote:
| 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.
| thayne wrote:
| 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.
| jonenst wrote:
| 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
| lixtra wrote:
| There are also notifications and more. It's about loosing the
| community enabled by the social features of github.
| anm89 wrote:
| 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.
| jfmc wrote:
| In a few years you'll be able to buy GitHub stars as NFT.
| bsuvc wrote:
| 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?
| GnomeSaiyan wrote:
| Agreed. This just screams bad UX on a corner case.
| JadoJodo wrote:
| I don't know for certain but I feel like this could allow
| something like 1. Takeover/inherit public repo with lots of
| stars 2. Take repo private (retaining stars) 3. Replace repo
| code with some malicious/offensive code. 4. Take repo public
| again 5. Inherit the trust/prestige of the old repo.
| ninkendo wrote:
| You can do that without the "making it private and public
| again" part anyway.
| [deleted]
| V__ wrote:
| But couldn't the same be achieved without taking it private?
| notreallyserio wrote:
| Yeah, that's a risk. They could mitigate it by allowing you
| to revert all branches/tags back to the pre-private state,
| but we're getting more and more complicated here.
| sam0x17 wrote:
| Yeah but it's not like stars are seen as some amazing
| endorsement on the part of the individual starring. It's more
| like a favorites list if anything
| freedomben wrote:
| stars absolutely are seen as an endorsement. I'm guilty of
| that for sure, and I've been in a ton of conversations
| about adopting some thing and the "number of stars" is
| often a consideration unless it's a project like React or
| Vue, etc.
|
| Would you really not look at two repos that do the same
| thing, with similar ages and recent commits but one has
| zero stars and the other has hundreds, and not at least
| initially trust the latter more?
| ranman wrote:
| 1) probably not the desired experience
|
| 2) probably part of the currently required setup on their
| database side (triggers)
|
| Features tend to evolve evolutionarily and certain data
| patterns are hard to invent around for security/privacy
| constraints. So err on the side of deleting rather than
| potential privacy/security bug.
|
| Definitely fixable with some decent investigation, coding, etc.
| - but hard to prioritize.
| DryLabRebel wrote:
| I think this is getting at the more robust solution.
|
| When youtube videos are taken down or made private, they are
| not deleted _necessarily_ from my playlists. There 's simply an
| indicator that they video is 'no longer available'. I don't see
| why something similar can't be the behaviour for GitHub stars
| and watches?
| wodenokoto wrote:
| You do lose the title, which is super annoying. "What did I
| used to have?" Super frustrating feeling.
|
| Here's a list of your favourite songs, but two are missing,
| have fun figuring out which two it is!
| nilleo wrote:
| I recently discovered a neat trick that if you Google the
| url for the private video (you still have this in your
| list), you're likely to find the title of the video,
| therefore allowing you to at least figure out what it was
| and seek out a new video.
| whoibrar wrote:
| Thank You! I needed this all my life!
| metadat wrote:
| This works about half the time. It's better than nothing,
| but not great.
| diego_sandoval wrote:
| Let's assume that the stars don't go away when the repo is made
| private. There are a couple of options:
|
| - The users can still see all their stars and find the private
| repo, which makes it not private.
|
| - The users can't see all their stars, they can only see their
| stars for the public repos. There's no way to find or unstar a
| private repo that you starred while it was public. This would
| lead to the situation that if you unstar everything and make
| sure you have zero stars, you could wake up the next week with
| 1 starred repos, and then with 3 starred repos, because some
| repos went public again.
|
| - The users can see all their stars, but the private ones lead
| to a 404, which would be perplexing for a greater number of
| people than the current behavior.
|
| - All private repos that have been public at least once lead to
| a "this repo is now private" message, that would in practice
| allow anyone to make an index of all the private repos that
| were public at least once. And it would also allow anyone to
| know when a private repo that was private at least once is
| deleted.
|
| I think the current behaviour is better than all of these
| options.
| saila wrote:
| Twitter has this kind of problem with likes (or maybe they
| fixed this since I haven't been on there in a while).
|
| When someone deactivates their account, you can see that you
| have X additional likes, but you can't access them. If that
| user reactivates their account, those likes suddenly show
| back up.
|
| This could be a privacy issue if you've decided to remove
| likes for a certain categories of posts for whatever reason.
|
| For GitHub, a couple other options I can think of would be to
| 1. show stars for private repos but only for the purpose of
| unstarring or 2. hide stars when a repo goes private and then
| give users an option to re-enable their star if a repo goes
| back to public. But these options are relatively complex, and
| I can see why GitHub would go with deletion.
| aflag wrote:
| The repo could lead to 404 to everyone, but if someone had
| starred it they would get a 403. They would be able to see
| all their stars but not access certain repos because they
| were made private. Probably less surprising then some of
| their stars disappearing. They would at least know what
| happened and it's not like wouldn't know the repo was public
| at some point anyway. Additionally, there could be another
| button to clear stars and watchers, if the owner of the repo
| really wants to.
| langsoul-com wrote:
| Perhaps 1-2 weeks of warning before a full delete of stars
| would be desirable for any repo with over 1k stars.
|
| Sorta like most social media apps when you want to delete
| your account. It doesn't delete it fully until a month later
| jimmaswell wrote:
| > The users can't see all their stars, they can only see
| their stars for the public repos. There's no way to find or
| unstar a private repo that you starred while it was public.
| This would lead to the situation that if you unstar
| everything and make sure you have zero stars, you could wake
| up the next week with 1 starred repos, and then with 3
| starred repos, because some repos went public again.
|
| Sounds fine and expected to me.
| neoromantique wrote:
| >I think the current behaviour is better than all of these
| options.
|
| Current behavior is destructive.
|
| >- All private repos that have been public at least once lead
| to a "this repo is now private" message, that would in
| practice allow anyone to make an index of all the private
| repos that were public at least once. And it would also allow
| anyone to know when a private repo that was private at least
| once is deleted.
|
| This is a much better option.
| MrStonedOne wrote:
| XCSme wrote:
| > The users can still see all their stars and find the
| private repo, which makes it not private.
|
| Why seeing a start you made for a previously public
| repository makes it not private? People remember things too,
| there's also the webarchive. You should be able to unstar it
| or keep your star, the only difference is that you don't know
| if the repository still exists or not.
| judge2020 wrote:
| > the only difference is that you don't know if the
| repository still exists or not.
|
| If an admin were to private->delete, then all the stars
| referencing the report would stay and thus the reference to
| the repo would still be there, on GitHub's servers. There's
| a difference between GitHub storing things forever and
| third parties on the internet being a forever archive of
| visible pages.
| jedberg wrote:
| But that's an easy fix. If they delete the repo, delete
| the stars. If they make it private, indicate it is now
| private in some way.
| judge2020 wrote:
| That's information disclosure; nothing about the repo
| after it's privated should be known, including name
| changes and deletion.
| jedberg wrote:
| It's unclear to me what the attack vector is for that
| disclosure.
| loa_in_ wrote:
| It was known and there are many sites scraping GH for
| metadata that will have it anyway
| judge2020 wrote:
| Not whether or not a repo exists after it's set private.
| KeepFlying wrote:
| Your last option sounds appealing to me here. Yes it does
| mean that you can never really make the name of your repo
| fully private after it's been started, but the name isn't
| really what's important most of the time.
|
| And there's always the potential to add a other toggle when
| privating a repo that lets you force-remove all stars.
| ozim wrote:
| Totally agree - cascade delete is such a nice thing - until it
| is not.
|
| Technically you want to delete dependent stuff, but in this
| case this seems like overstepping on development side.
| catsarebetter wrote:
| Starred and watched again, it's a great project, hopefully the
| whole audience comes back soon
| [deleted]
| krick wrote:
| > 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.)
| mproud wrote:
| 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.
| williamsmj wrote:
| 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.
| paxys wrote:
| "Type a specific thing to confirm" (as suggested by the post
| you linked) is _exactly_ what Github does for destructive
| actions. And the author still messed it up because they were on
| "autopilot". At that point the suggestions go beyond being
| reasonable.
| williamsmj wrote:
| It doesn't suggest that you type a any old "specific thing".
| It specifically suggests that you type something to
| demonstrate you acknowledge the _scale_ of the destructive
| operation you are about to perform.
|
| The OP's main suggestion is along exactly those lines. It's
| actually less extreme, in some ways (see OP's "Lesson 1").
| BHSPitMonkey wrote:
| The confusion is justifiably well explained by the article:
|
| > What put me on the wrong path was an otherwise completely
| unrelated action: I had just done the same (i.e., hidden an
| empty README) on my personal profile by making
| jakubroztocil/jakubroztocil private.
|
| > GitHub's conceptual model treats users and organizations as
| very similar entities when it comes to profiles and repos. In
| this context, and since I just wanted to repeat the same
| benign action on our organization's profile, my brain
| switched to auto-pilot mode.
|
| > I didn't realize at the moment there's an inconsistency in
| the naming of this special repo containing profile READMEs
| and that it differs for users and organizations: name/name
| vs. name/.github.
|
| > That's why I proceeded to make httpie/httpie private
| instead of httpie/.github without realizing my mistake.
| tedivm wrote:
| This isn't "exactly" what Github does. The author suggests
| the number of machines to destroy in their example- a Github
| equivalent would be to use a number that represents the
| amount of resources to be destroyed. This is close to what
| the OP recommended.
| cycomanic wrote:
| So you never copy and pasted into dialog boxes? This is
| exactly the same thing as the Windows warning messages were
| they found that nobody reads the because they are being
| trained to click them away.
|
| The main thing I really don't get is why it even needs to
| delete all the stars? It's not like they delete all
| comments/issues... by users who have been deleted. So why
| could they not simply make the star point to a "ghost
| repository"?
| BlueTemplar wrote:
| > Of course, if you run into this a lot and you actually
| intend to hit that many machines, someone might start
| cutting and pasting the number. In that case, I would say
| that you're using that tool far too often, and should take
| a look at changing the way things are done to avoid having
| to rely on it this much.
| sam0x17 wrote:
| They could very easily list the number of stars that will be
| deleted, as a sanity test. That in my opinion is even more
| reasonable than having to type the repo name, and should be
| implemented.
| sbarre wrote:
| You really think that adding contextual information in a
| destructive modal (i.e. "You are about to erase 54,000
| stars") is "beyond being reasonable" ?
|
| It seems like a pretty reasonable suggestion that doesn't
| _feel_ like a lot of work, but could potentially prevent an
| irreversible mistake.
| steve_adams_86 wrote:
| 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.
| apostacy wrote:
| Should customers who have had a bad experience just not give
| any feedback then?
|
| Github should be grateful for this feedback. I know that it
| takes effort to make your product or service better, but that
| doesn't mean that customers shouldn't ever say anything.
| Customers are telling Github how it can improve its service.
| Github can choose to listen to them, or not.
|
| With some simple frontend changes, they can probably reduce
| accidental destructive changes to customer's accounts.
|
| I think Github cut some corners here. I would much rather that
| repo stars were treated similar to how resources on other
| platforms are. If someone makes it private, then return 403
| "repos is private"
| steve_adams_86 wrote:
| I completely agree that the feedback is valuable and I don't
| think no one should say anything. In fact I think it's
| essential to say something.
|
| I'm only commenting on how so many comments trivialize the
| work required to resolve this. I have a feeling nothing is
| trivial at GitHub.
| njsubedi wrote:
| But.. one of their developers also made the same mistake as the
| OP. The OP learned a lesson but seemingly anyone at GitHub
| didn't think, "we should fix this confirmation dialog so this
| doesn't happen again".
| steve_adams_86 wrote:
| It's also possible that they did consider it, but upon
| investigation it entailed more work than they could justify.
|
| I do think including more context about what will be
| destroyed by the action would be great, and probably
| pragmatic, but... If typing out the name of the repository
| isn't enough, providing context might not be either.
|
| The more I think about it, the more it seems like one of
| those "Whatever, we've got a million other things to do"
| situations. It might get a handful of inquiries about it per
| year while a dozen other features get hammered with attention
| and requests from paying customers.
|
| Again, not saying they can't improve it. Just giving them the
| benefit of the doubt here and proposing that it's possible
| that it isn't better for legitimate reasons.
| junon wrote:
| They're owned by Microsoft and funded/now led by by Nat
| Friedman. They can justify a lot.
| steve_adams_86 wrote:
| No doubt, and I've never worked on a team with these kind
| of resources so I can't be certain either. I'm just
| advocating for the people at GitHub and casting doubt
| that it's trivial to avoid situations like this or
| resolve them.
| wilg wrote:
| Do people use GitHub stars for something? Sometimes I star things
| but I have no idea what it does or why I do it.
| layer8 wrote:
| It's basically just a bookmark for yourself. And GitHub shows
| how many users have "bookmarked" a particular repository.
| mattgreenrocks wrote:
| In the absence of metrics to use for ranking, it is hilarious
| how people co-opt whatever weak metrics they find and then
| retcon a deeper meaning into them.
|
| "They're not stars, they're a community!" What percentage of
| your community actively contributes bugfixes?
| lexx wrote:
| 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
| ncmncm wrote:
| You wholly miss the point.
| lexx wrote:
| I just add to the conversation. There are great points
| discussed. No reason to repeat them. I just add
| ghoomketu wrote:
| 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.
| capableweb wrote:
| > 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.
|
| That's not the only difference. The other difference is that
| you also have to type the full repository name, including the
| organization name.
|
| If they wanted to delete the correct repository, they would
| have to type httpie/.github, but instead they typed
| httpie/httpie.
|
| It's unfortunate what happened, but without GitHub removing the
| possibility at all to delete repositories/change the
| visibility, I don't know what else they could have done to try
| to prevent it. It's really hard as a user to affect the wrong
| repository, as you are gonna have to mentally and literally
| pause to write out the organization name + repository
| (httpie/httpie in this case) and if that doesn't stop you, I
| don't think anything would.
| hinkley wrote:
| This UI is predicated on the notion that the user will
| connect the word you're asked to type to the repository
| you're intending to modify.
|
| Most of the time that's true, or we'd be hearing about this
| happening all of the time. But 'most of the time' is not
| 'every time'. 'Almost always' is also not 'every time'. This
| is a distinction that Human Factors people make that victim-
| blaming nerds do not.
|
| You've seen the video on Youtube (or Reddit) of the guy
| holding the fish throwing his phone into the lake? He didn't
| do that because he was stupid, he did it because he made an
| executive decision to, "hold fish, take picture with phone,
| throw it in the water" and then his motor cortex swapped 'it'
| to the wrong hand and went on autopilot.
|
| If you don't like that example, I know of a highly secure
| data center in Seattle that had the emergency power cutoff
| button pushed not once but twice by different tenants. The
| first time was a pure accident of bumping it while doing
| maintenance. The second time someone opened an acrylic case
| and pushed the button because they thought "buttons open
| doors, I see a button. Sure is weird that it is covered with
| a box... hey why did the lights go out?" You have problem,
| you observe action or object that solves problems (maybe not
| this problem), monkey brain attempts action to see if problem
| is solved.
|
| Typing in the repository name narrows the gap between intent
| and action, but it doesn't close it. Technically making
| someone type, "Make hippie/hippie private" would at least
| make them spell out the intent, narrowing it again. But it
| doesn't make them state the intent. Strictly speaking, they
| are being told to transcribe text. Whether they parse the
| text they're typing or not is a separate step, in two
| different parts of the brain. Any of those fails to connect
| and you have a catastrophic destruction. From a Precautionary
| Principle standpoint, the consequences are exactly the same
| with all three options, and only the likelihood has changed.
|
| If you want to make a big dent in outcomes you have to also
| reduce the consequences, not just the opportunity. Making all
| actions reversible is the most conceptually simple and the
| most technically difficult option. Parceling out consequences
| over time is usually less difficult, and if you pick an order
| that makes the feedback immediate, then the person realizes
| quickly that what they meant and what they said didn't line
| up, before the real damage kicks in.
|
| Github is built around git. The two biggest ways to
| permanently lose data from git, one of them is protected by
| permissions and may be off by default. The other one is
| automatic but takes 30 days. That's two very different
| precedents that have been set, and they picked the wrong one
| to emulate.
| dzmien wrote:
| Maybe some kind of grace period could be implemented that
| would allow changes like this to be undone within 24 hours or
| something.
| vollmond wrote:
| The other thing they could do is make user/organization
| structure for that profile readme the same - as he mentioned,
| he had just done it on his personal account, which is of the
| form `<user>/<user>`, so doing `httpie/httpie` for the
| organization made contextual/autopilot sense in the moment.
| dmitriid wrote:
| > The other difference is that you also have to type the full
| repository name, including the organization name.
|
| No, you don't have to type it, and I doubt anyone types it.
| You copy that line and paste it. Often it's done on
| autopilot, especially when in a rush.
| ivirshup wrote:
| I type it.
|
| It's typically short short, and it's a very destructive
| action. It's also very apparent to me why I would want to
| type it out.
|
| That said, someone is going to make a mistake at some
| point. I'd expect better from github support here.
| makeitdouble wrote:
| This topic really got me thinking.
|
| A lot of us navigate by typing, be it CLI, in our IDE,
| URLs etc. And we must have got used to type hundreds of
| times our company or project names every day, in many
| places.
|
| I can't imagine typing <project name>/<project name> in a
| input box triggering in us a lot consciousness or extra
| care. Typing something more unusual could actually be
| more impacting I think.
| superasn wrote:
| I always just select the text and drag drop it in the text
| box with mouse.
|
| In famous words of Mr. Larry wall, 3 great virtues of every
| programmer: laziness, impatience, and hubris.
| FabHK wrote:
| > I don't know what else they could have done to try to
| prevent it.
|
| As the author of the post suggests: Prominently spell out
| "This will remove 54,000 stars." vs. "This won't remove any
| stars (there are none yet)."
| drexlspivey wrote:
| Until the next post by someone else that missed that
| warning and suggest to make the warning blinking with a big
| font
| vollmond wrote:
| There is a difference between using UI tweaks
| (color/size/motion) to call out information, and actually
| displaying that information.
|
| Right? As in, "this will affect 0 stars" vs "this will
| affect 54,000 stars" is an informational difference.
| Calling out "this will affect all stars" (without
| specifying a number) doesn't break a user out of doing it
| to the wrong repo, since that message is the same in both
| cases.
| tshaddox wrote:
| I'm not convinced that would have really solved the
| problem. One could just as easily post a screenshot of two
| nearly identical dialogs where the only different is that
| one says "This will remove 54 stars" and the other says
| "This will remove 54,000 stars" and the same argument could
| be made that "the only way to notice the difference is if
| you happen to notice those 3 zeros."
| grog454 wrote:
| >I'm not convinced that would have really solved the
| problem.
|
| It almost certainly would help. When you attempt to
| delete a world of warcraft character you are prompted
| with the character's level, among other info. This is the
| biggest difference you'll see between the delete
| procedure for a level 1 alt with < 1 hr played and a
| level 80 (or w/e) character with >10,000 hr played if
| you've named them similarly.
|
| Because of the relatively low character limit and the
| popularity of alts, this feature (delete character) gets
| a lot of use and misuse so it's reasonable to expect the
| developers to have put some thought in to it.
| freedomben wrote:
| It seems like a pretty easy feature to build. No database
| changes required, and I wouldn't be surprised if the API
| already returns the star count for the repo so it's
| client-side only. I'd guess somebody could do it in a
| couple of hours (famous last words lol). I'd guess adding
| that feature would be less time/effort than restoring
| httpie's stars. A/B testing might be a little harder
| since conditions like OP's don't happen often, but you
| could at least do some testing.
| Gigachad wrote:
| No amount of warning popups will help. The only solution
| is a delayed delete with the option to undo.
| eyelidlessness wrote:
| I think the only people who won't notice three trailing
| zeroes are people who don't need to
| ovao wrote:
| Another commenter suggested having to type the number of
| stars you'd be forfeiting instead of the repo name. Kind
| of a neat idea I think.
| BlueTemplar wrote:
| In practice, they are extremely unlikely to be zeroes.
| r3trohack3r wrote:
| > That's not the only difference. The other difference is
| that you also have to type the full repository name,
| including the organization name.
|
| This is not true.
|
| We had an internal tool at a previous job that required you
| to type the name of a service's cluster into a field before
| deleting it. Automated deployments sometimes got left behind
| - and users would go in periodically and clean them up.
|
| If you watched folks, they would type the name of the cluster
| being deleted into that box UNTIL they had to do this many
| times in a row. As soon as it was a "batch" job, folks would
| go through the motion of:
|
| 1. click delete
|
| 2. double click service name
|
| 3. ctrl+c
|
| 4. click text input
|
| 5. ctrl+v
|
| 6. press "Confirm"
|
| It was remarkable, after someone did this once, I don't think
| I ever observed them going back to typing in the cluster
| name. That algorithm of "copy and paste" carried over into
| every prompt they saw of that form moving forward.
|
| I'm guilty of this too - I no longer type the prompted name
| for this form of confirmation dialogue, it's a copy-and-
| paste.
| pm90 wrote:
| Lol, I do this whenever they ask me to re-enter my
| email/password for verification even though I know exactly
| the purpose this mechanism is trying to enforce.
|
| Humans will always take the easiest route. We just have to
| accept that and come up with better solutions that aid
| humans or fit to our very weird nature.
| endless1234 wrote:
| This is exactly what you start doing on Github too, since
| many repo operations require you to do it. Seeing this
| warning modal where you have to copy-paste some string is
| what you expect when clicking delete/make private/make
| public. I don't know if it really helps.
| rootusrootus wrote:
| > I'm guilty of this too
|
| You and most of the rest of us, I suspect. Like I want to
| type that out every time...
| ikiris wrote:
| I mean obviously users are going to cut and paste that
| output. It's completely hostile design in terms of
| usability on their part. What did you expect to happen?
| Meai wrote:
| I think you make a good point, the retyping is not
| perceived as a genuine sort of 2-factor step but is
| perceived like an annoyance. Maybe the consequences of the
| action should be shown in a screenshot with a 5 second
| wait. Personally the only reason it works for me as a
| 2-factor is because I think about what _Github 's_ intent
| is when they prompt me to retype the repo name and
| therefore I take a moment to reflect that I indeed want to
| do what I want to do. But isn't that backwards? I have to
| imagine what Github's intention was instead of simply
| seeing a ui and understanding it for what it is.
| bredren wrote:
| There are certain repository actions that require an
| interaction and assistance from GitHub customer support.
|
| The community was valuable to GitHub as well.
|
| I could see a spec on "sizable community thresholds" where if
| an interaction might blow away something of that size GH
| affords you an exchange with a "concierge" forcing a minor
| exchange with a real person.
| KennyBlanken wrote:
| In both cases the dialog clearly warns you, with bolded text,
| on a separate line, of the consequences of your actions.
|
| "We were in the top Xth percentile" makes the author sound like
| a complete tool and I have little sympathy for them, especially
| given they're already back to 3k stars.
|
| Expecting the dialog to say "now, you've got 50,000 stars, are
| you REALLY REALLY SURE?" is just infantile, but really matches
| the overall tone the author has.
| WesolyKubeczek wrote:
| I'm afraid to think that these same people, having attitudes
| like this, are driving cars on public roads.
| vollmond wrote:
| The dialog clearly warns you that if you have something to
| delete, it will be deleted, but it doesn't let you know if
| there is anything to delete.
|
| That's not in itself a huge problem, but in this case it was
| compounded with the fact that the generic repo he was acting
| on is named inconsistently for users vs organizations, and he
| had just done it on his user account. If I'm reading
| correctly, a user's profile readme repo is `<user>/<user>`,
| while for organizations it is `<org>/.github`, and,
| crucially, `<org>/<org>` is almost always going to be the
| core project for that org.
|
| So yes, the warning says you will lose all stars on the
| project, but in the moment it would have seemed (to a
| fallible human brain who was in a user-space context) that
| this was the right repo, whereas a "you will lose 54k stars"
| message would have broken the user out of that space.
| tshaddox wrote:
| Just showing the two screenshots feels a little disingenuous
| though. It's not like that dialog just pops up randomly and
| asks if you want to delete a random repo, and the only way for
| you to know which repo it's talking about is to read that line
| near the bottom. In each case the path to summon that dialog
| had to go through direct interactions with the repo in
| question.
| throwawayHN378 wrote:
| Ugh that sucks
| whoisthemachine wrote:
| 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?
| johnwheeler wrote:
| 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.
| alecbz wrote:
| It's both, but mostly the first one. rm's default behavior is
| terrible design. Just because UNIX does something doesn't make
| it good.
| mjyut wrote:
| > GNU rm normally declines to operate on any directory that
| resolves to /.
| https://www.gnu.org/software/coreutils/manual/html_node/Trea...
| GettoiBoise wrote:
| This is giving me a really great idea for a tool that saves past
| states and allows for clean reversals of said mistakes.
| ev0xmusic wrote:
| Same story happened to us last December :/
| https://www.qovery.com/blog/we-lost-3800-stars-on-github-in-...
| prmoustache wrote:
| 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.
| lucideer wrote:
| 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".
| pluc wrote:
| 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.
| williamsmj wrote:
| The article literally has a section "Lessons learned".
| forgotpwd16 wrote:
| Lessons learned... for GitHub to take.
| epidemian wrote:
| This is a similar attitude to blaming users who close an
| program without saving, telling them it's their fault; the
| program even asked if they _really_ wanted to close without
| saving!
|
| But, it's also totally possible for a program to store a
| backup, and let the user restore that the next time they open
| the program in desperation for not having saved their document
| in a moment of distraction.
|
| > but it should be a "lesson learned"
|
| Yes. And as the article notes, the lesson can be that software
| and UX can be make to accommodate better for possible user
| mistakes. I personally think it's nice to have Undo actions, or
| some ways to revert possible mistakes. It makes software way
| less scary :)
| edem wrote:
| > 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.
| bearbin wrote:
| 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).
| evouga wrote:
| Of course if GitHub were only a service for cloud hosting of
| Git repositories, it would be totally irrelevant whether or not
| the repository was marked private for 30 minutes.
|
| But GitHub, by design, seeks to be as much of a social network
| as a repository hosting service and people take the stars
| _very_ seriously. I've seen many CVs that brag about the
| candidate's star counts.
| asadawadia wrote:
| >GitHub, by design, seeks to be as much of a social network
|
| This is so true - not sure why it isn't getting talked about
| more - they even have a feed now [which is getting better
| every few days]
| terinjokes wrote:
| This change also clears out watchers. I was watching the repo
| to be notified of new releases (and security updates) and that
| was wiped out as part of this mistake.
| C4stor wrote:
| 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 ?
| pmarreck wrote:
| I like the tool, somehow I'd never heard of it until now
| pizza234 wrote:
| 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.
| jacoblambda wrote:
| The post addressed this.
|
| > What put me on the wrong path was an otherwise completely
| unrelated action: I had just done the same (i.e., hidden an
| empty README) on my personal profile by making
| jakubroztocil/jakubroztocil private.
|
| > GitHub's conceptual model treats users and organizations as
| very similar entities when it comes to profiles and repos. In
| this context, and since I just wanted to repeat the same benign
| action on our organization's profile, my brain switched to
| auto-pilot mode.
|
| > I didn't realize at the moment there's an inconsistency in
| the naming of this special repo containing profile READMEs and
| that it differs for users and organizations: name/name vs.
| name/.github.
|
| > That's why I proceeded to make httpie/httpie private instead
| of httpie/.github without realizing my mistake.
|
| There's a subtle naming difference between profile README repos
| for users and orgs that was the root cause of this. The user
| typed the repo name in however because it matched the same
| format for the previous profile README repo, it didn't register
| that this was not in fact the profile README repo they were
| looking for.
| burnished wrote:
| The post did not omit that, it included the very similar thing
| they typed as context for how they auto-piloted it. In that
| autopilot state having to type out 54000 would probably have
| snapped them out of it. I get why you'd think the author is
| being unreasonable, they seem to imply that this should already
| have been done, but I think that is mostly them feeling upset
| about the situation. The actual observations would be
| thoughtful improvements to the UI.
| arcticfox wrote:
| Your comment is omitting that the post covered this exact point
| in detail: they had just done the same operating on their
| personal profile where you have to type [username]/[username].
| [organization]/[organization] is the obvious corrolary.
|
| Anyways it's embarrassing that Github made this same mistake
| themselves, and yet couldn't spare the time for a massive
| content creator contributing to their platform
| ncmncm wrote:
| Not just embarrassing, disgraceful.
| qbasic_forever wrote:
| They address that in the post. Github treats organization
| accounts differently from personal accounts, and what would
| have worked perfectly fine and expected for a personal user
| account actually impacted a different and unexpected repo for
| an organization account. I would wager 99% of Github users
| would make a similar mistake in the same situation since they
| rarely deal with organization accounts directly.
| phphphphp wrote:
| Does anybody actually type those? They were a neat solution 10
| years ago but they're so common now for even inconsequential
| actions that I always copy and paste, on complete autopilot.
| w-m wrote:
| I came across such a prompt maybe three times total in my
| life, all of them making GitHub repos public or private, or
| deleting them. Made me stop completely in my track. So it
| seems to be very much dependent on what you do day to day.
| hitovst wrote:
| Yikes. Can this be turned into a multi-sig 2fa, or 1 hour waiting
| period before confirmation?
| dogdot wrote:
| 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?
| jakelazaroff wrote:
| 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/
| joshxyz wrote:
| Hi newbie developer here, where do i find and learn about ux
| design priciples like this? Just curious, thank you thank you.
| smusamashah wrote:
| "Design of everyday things" is a great book to start.
| capableweb wrote:
| Which comes with its own problems. What if I just published
| something I wanted to be secret? Then I need to be able to
| switch it back to private, and it has to be quick, not after
| five minutes. Distributed systems with eventual consistency
| already make fixes like that hard, not to mention caches and
| whatever.
| mgdlbp wrote:
| Making a private repo public could also be delayed.
| kortilla wrote:
| There is no undo there. 5 mins seems like a long time to you
| but to the bots that scrape GitHub repos for secret things,
| the time it took you to notice and reverse something yourself
| was already the time they needed.
|
| If you made something public on GitHub that shouldn't have
| been, it was immediately compromised, you just might not
| notice.
| [deleted]
| hnlmorg wrote:
| The GP didn't mean "wait 5 minutes before making any action",
| they meant "stage the change so the user can see the result
| of their action but they still has a grace period to undo
| it".
| ncmncm wrote:
| Or, have there be no need to undo anything. Why should
| ticking the "private" flag have any effect on anything
| else? If you wanted an effect on something else, a separate
| button "Nuke all 53,675 star from this repo", with its own
| protections, would suffice.
| maleldil wrote:
| How would stars and watchers work on a private repo,
| though?
| jakelazaroff wrote:
| Just don't show them. Filter out private repos before
| showing a user's stars, notifying them of issues, etc.
| lalopalota wrote:
| Right, just more work. More tests. More edge cases. More
| time.
| jakelazaroff wrote:
| Sure. But that's the cost of good UX.
| 14u2c wrote:
| Well, they put in the time to test a massive cascading
| delete operation. Surly a flag would have offered far
| less possibility of catastrophic outcomes and therefore
| would been significantly easier to confidently develop
| and test.
| hnlmorg wrote:
| Cascade delete is a less risky operation from a security
| stand point. There are so many edge cases where
| potentially sensitive information could get leaked with
| regards to subscribed private repos if not handled
| correctly. In fact I have personally filed a bug bounty
| with GitHub after discovering just such a bug.
|
| I'm not saying there isn't a better way Github could
| handle this situation. Just that I do sympathise with the
| decision to cascade delete.
| mypalmike wrote:
| If they are using a database's built in support for
| cascading deletes, and if the star tables are simple m2m
| tables (basically just 2 fk's per row), the work to
| implement and test cascading deletes is trivial.
| Jowsey wrote:
| Could just make them inactive for a while, but still
| registered.
|
| Stop sending notifications to watchers, and replace the
| repo in the stargazer's starred list with a "The
| following starred repos are currently private and cannot
| be viewed:" and make the stars be remove-only for a
| while.
| umvi wrote:
| It's understandable why warnings are used instead of undos
| though. Warnings are dirt simple to implement - probably a
| single line of code in most languages. Undo is very complex by
| comparison. You have to flag something for deletion and put it
| into some sort of deletion queue that somehow gets deleted at
| some future date, etc.
| jakelazaroff wrote:
| It's definitely easier from the implementer's point of view.
| That doesn't make the UX any better, though.
| WhyNotHugo wrote:
| 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.
| alecbz wrote:
| Open source doesn't mean direct access to the underlying
| data/databases. Self-hosted could work, but creates new
| problems like "are you sure your backups are working?"
| mekster wrote:
| 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.
| yellowapple wrote:
| 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).
| anonfunction wrote:
| GitHub doesn't use foreign keys[1], and there's likely many
| tables related to all the users, notifications, permissions,
| etc... that would need to be cleaned up. Without foreign keys
| they likely have some system process that does this instead of
| a simple `DELETE FROM` which cascades.
|
| 1. https://github.com/github/gh-
| ost/issues/331#issuecomment-266...
| bawolff wrote:
| 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.
| pingsl wrote:
| 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.
| agluszak wrote:
| Please don't use discord, use gitter or something else which
| itself is open source
| michaelterryio wrote:
| 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.
| soorya3 wrote:
| 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.
| bilkow wrote:
| 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.
| lfnoise wrote:
| I find it ironic that you can't reverse a mistake on a site
| dedicated to a software that is all about reversing mistakes.
| mlatu wrote:
| 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?
| roxaaaane wrote:
| I really like this post.
|
| It shows how we gamify everything including open-source.
| jdorfman wrote:
| 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.
| a-dub wrote:
| 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.
| pm90 wrote:
| 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.
| OJFord wrote:
| 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.
| wly_cdgr wrote:
| The author shows admirable restraint in characterizing
| Microsoft's response
| dom96 wrote:
| Surprising amount of people blaming the user here. I agree
| completely with the author, the UX should be different for
| clearly "big" repos.
| barrucadu wrote:
| How big is "clearly big"? Whenever someone makes the same
| mistake with a slightly-less-big repository should the warning
| thresholds be revised to also show up for those?
| dewey wrote:
| It should just show the amount of stars / watchers for any
| repository. I don't think a custom strategy based on repo
| size is needed.
| HellsMaddy wrote:
| 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
| _moof wrote:
| Thankfully there are exceptions to this, notably aviation.
| Having all accidents investigated by an independent board with
| a systems approach has proven to be an extremely successful
| model. It's a shame it isn't replicated elsewhere.
| izacus wrote:
| In aviation, a pilot who would ignore so many warning
| elements of UI (red button, dialog, retyping things) on
| "autopilot" would have their license revoked and possibly
| criminal charges pressed.
| ncmncm wrote:
| A disgrace. It's not like it is any easier in aviation than
| anywhere else.
|
| Civilian oversight of police departments could be instituted,
| too, investigating killings and maimings by police. It could
| be federally supervised, instead of relying on every state,
| county, and Podunk town to institute it.
| kgeist wrote:
| 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.
| langsoul-com wrote:
| Damn, would be interesting to know what the effects of the
| third iteration is.
|
| Would validate/invalidate the authors ui suggestions.
| eknkc wrote:
| GitHub also makes you type out the project name and that still
| did not help here.
|
| I guess users will always be able to fuck things up.
|
| Best solution would be to offer undos but then people will
| complain that deleting things does not actually delete. You are
| keeping data to yourself! Start citing privacy issues etc.
|
| There is no winning here.
| WA wrote:
| Same here. I finally brought accidentally deleting stuff down
| to zero by having them type the number they get to lose:
|
| "You have 55,231 GitHub stars. Please type 55231 if you want to
| delete them all."
|
| But I guess, if you delete repos often enough, this will also
| become muscle memory.
|
| Edit: Just saw the other comment here suggesting the same:
| https://news.ycombinator.com/item?id=31033996
| manmal wrote:
| So, for projects with 100+ stars, add a wait period of 60
| seconds until the delete button can be clicked _after_ the
| number is typed in. That should allow most users on autopilot
| to snap out of it, or make drunk users switch to a different
| tab and forget about it.
| gscott wrote:
| Better to flag it as archived. This way they can unarchive if
| need be.
| spixy wrote:
| almost all of my projects have < 5 stars, typing "0" half the
| time is more dangerous than typing my_name/my_repo.
| roflulz wrote:
| just do soft deletes that can be undone... seems so easy..
| Agentlien wrote:
| I've seen some software, can't remember which, that forces you
| to type the name of the project you're deleting to confirm.
| That's made me think twice.
| notRobot wrote:
| GitHub does that
| Agentlien wrote:
| Considering the context I'm amazed I didn't realize that
| was where I'd seen it.
| NoboruWataya wrote:
| > 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".
| jasonlotito wrote:
| > It seems a bit much to expect the website to show you a
| warning of different levels of severity
|
| I've done this for personal projects. I don't see why GitHub
| can't do something similar.
|
| > It even makes you type the name of the repo you want to make
| private before proceeding
|
| No, it literally does not. Nor does this mean you fully
| understand the implications of what you are doing as explained
| in the article.
|
| > check what repo you're in before taking destructive actions
|
| The amount of checking and automation of things for non-
| destructive actions, you'll forgive someone for expecting a bit
| of extra automation that, in this case, literally costs less.
| stonemetal12 wrote:
| >he was not sufficiently warned of the consequences
|
| Like most computer warnings it was overly generic, it warned
| there are potential consequences, but never warned of the
| actual consequences. If the warning had said hey this is going
| to effect 55K stars and watchers, he would have known he was in
| the wrong spot.
|
| The problem is if you expect a generic warning then a generic
| warning doesn't actually warn. A specific warning is more
| likely to, but not guarantied to catch attention.
| bocytron wrote:
| A developer at GH made the same mistake. It clearly means the
| UI is not working the way intended.
|
| On one hand, there's a UI change GitHub could implement that
| would greatly prevent this situation from happening again. On
| the other hand, one could try warn every github users that this
| situation can happen and to be carefull... Well I have my
| opinion on which would be most effective.
| yreg wrote:
| I found this article interesting, exactly because "typing the
| name of the repo you want to make private before proceeding"
| seemed like a good solution to me as well. (Until now.)
|
| However, I can absolutely imagine doing the author's mistake
| and I think their UI improvement suggestion is great.
|
| To me the interface design lesson here is valuable. A
| recommendation to "check what repo you're in before taking
| destructive actions" has zero value, since everyone knows that
| already.
|
| ---
|
| Completely agreed on the second point though, it's weird to
| blame this mainly on GitHub.
| kolanos wrote:
| It occurs to me that if your users are mindlessly doing
| repetitive things, no amount of "Are you sure?" or other hoop
| jumping is guaranteed to snap them out of it. Humans are
| pattern recognition machines.
|
| GitHub may be better off preventing a repo with this size of
| a following from being made private without a support request
| or something requiring a second party to confirm.
| yreg wrote:
| Yes. Someone elsewhere in this thread suggested that it
| could be improved to make it impossible to make the repo
| private before you delete all the stars somewhere else in
| the UI, therefore breaking out of the pattern.
|
| Surely there are multiple solutions, but I think you
| distilled the essence well: make the truly dangerous action
| different to the learned repetition.
| kif wrote:
| At my company, we had like 3-4 steps, each with clear
| wording to cancel a subscription, and they had to type
| something in the end to confirm. Guess what? We still had
| tickets asking to restore their subscriptions :)
| yreg wrote:
| I was mesmerised how the Japanese train operators (and
| perhaps other similar workers) have to follow checklists
| where they physically point[0] at everything they are
| doing even when they are alone.
|
| Now I'm wondering whether this approach actually works.
|
| [0] - https://youtu.be/9LmdUz3rOQU?t=66
| bmacho wrote:
| I think that's a different matter. Using checklists to
| automate a task, and make sure you don't skip any is
| working. Random obstacles before dangerous acts IMO make
| little to no use. Before destroying a house a checklist
| can ensure that they checked if there are anyone in the
| building (i seriously have no idea how they do that), but
| requiring them to stand on one leg with pinched nose, I
| don't think that'd have any use.
| jjoonathan wrote:
| > It even makes you type the name
|
| More and more IT systems are starting to do this for more and
| more tasks. I understand why: it's a hell of a lot easier than
| implementing a trashcan, timed undo, joining in helpful data,
| etc, but man, one good session with a couple hundred resources
| that need to be deleted this way is enough to burn you out
| pretty hard on these.
|
| Also, systems that go for these lazy solutions tend also to go
| for the lazy solution of "just delete and recreate the
| resource" instead of implementing proper modify functionality.
| This compounds the problem. As if administrative tasks didn't
| already come with enough drudgery, now you have to constantly
| do the old timey school punishment of writing lines just to do
| your job.
|
| "Just add friction" is evil. Easy, but evil.
| BrandoElFollito wrote:
| When doing such massive changes it may be worthwhile to
| consider using the API (requires some coding, but still
| faster then typing in the repo names)
| jjoonathan wrote:
| It wasn't github. There was no API, and if there had been,
| I would have been ill advised to trust it.
| wussboy wrote:
| I have worked with an extremely complex system in the past
| (Genesys Engage telephony) and their configuration was so
| complex that changing even the most innocuous attribute in
| the most seemingly unrelated object could bring the system to
| its knees.
|
| As time went by they slowly started to "improve" the
| situation by constantly forcing you to click through a
| "changing this setting may have knock on effects to your
| system" banner...that they showed every time you changed
| anything. Making it completely useless for actually
| preventing you from harming your system and really just
| giving the impression they were trying to cover their butts
| legally.
|
| I hated working with that platform.
| behnamoh wrote:
| > 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.
|
| If you're using Github's CLI tool, you can _autoconfirm_ repo
| deletion so that you won 't have to type the name ever again.
| It seems like if Github were to change their UI, they would
| need to somehow change their API as well.
| dmitshur wrote:
| I'm wondering if you got a chance to see this part of the post:
| > [...] I obviously had no intention to make httpie/httpie
| private. So, why then? > > The proximate cause was
| that I thought I was inside a different repo; [...] What I
| actually intended to do was to hide the HTTPie organization's
| profile README, [...] > > What put me on the wrong
| path was an otherwise completely unrelated action: I had just
| done the same (i.e., hidden an empty README) on my personal
| profile by making jakubroztocil/jakubroztocil private. >
| > GitHub's conceptual model treats users and organizations as
| very similar entities when it comes to profiles and repos.
| [...] since I just wanted to repeat the same benign action on
| our organization's profile, [...] > > I didn't
| realize at the moment there's an inconsistency in the naming of
| this special repo containing profile READMEs and that it
| differs for users and organizations: name/name vs.
| name/.github. > > That's why I proceeded to make
| httpie/httpie private instead of httpie/.github without
| realizing my mistake.
|
| For me, this part of the post really helps understand the
| context in which the mistake was made. The post is long so it
| is possible some people read other parts but missed this one.
| parkingrift wrote:
| I did read that part. He or she had to exactly type out
| "httpie/httpie" to confirm the action. I don't know what else
| GitHub could do to prevent this. How much handholding does
| GitHub need to offer? People need to accept the consequences
| of their own actions. The amount of manual steps necessary to
| take httpie private is fairly substantial. This person was
| careless and learned a lesson on being careless.
| millerm wrote:
| Funny thing is that I have never typed in a repo to delete.
| I always just copy/paste from the message. It's probably
| what the repo owner did. Perhaps Github should generate an
| image instead of using text that can be copied. That way
| they could help mitigate the copy/paste problem.
| kolanos wrote:
| This would be an accessibility regression.
| ratww wrote:
| Not really. alt and title are a thing in HTML.
| kolanos wrote:
| Then you're back to the original problem (you can copy-
| paste alt/title attributes).
| [deleted]
| scrollaway wrote:
| Where do you see that they didn't accept the consequences
| of their own actions? They just wish it were
| different/better.
|
| There's no harm in that, and Github being used by millions
| of developers is a strong reason to make it just a little
| bit safer for even the rarer cases like these.
| glacials wrote:
| Based on your phrasing I'm still not sure if you understand
| parent--yes, the author had to type "httpie/httpie", but
| due to GitHub's user-level README repo feature, _that
| specific repo name_ conventionally would be a README repo,
| which is what the author was trying to delete.
|
| For example, my README repo is and must be called
| "glacials/glacials"; if I wanted to delete it that is what
| I would type, but if I were an organization and wanted to
| delete it, I would type something else. This different
| behavior between acting as a user vs. acting as an
| organization is what caught the author off-guard. They
| typed "httpie/httpie" and consciously thought "yes, I want
| to delete the README repo, which I know must have name
| httpie/httpie, so that's definitely what I'd like to do,
| I'll go ahead and type that".
|
| This is not absentmindedness, it is a misleading product
| inconsistency. Were it not for this, I would 100% agree
| with you.
| senjin wrote:
| Thank you for this explanation. I didn't know profile
| READMEs were a thing and have to be named the same as the
| user account. I can see how this could be confusing when
| the functionality is different between users and orgs.
| addingnumbers wrote:
| > I don't know what else GitHub could do to prevent this.
|
| The article describes exactly what else they could do,
| including example screenshots from another app that does
| it.
| sunir wrote:
| I don't see the need for moralizing. They took
| responsibility, and offered GitHub money to help. They
| aren't leaning in heavily to blame Github here.
|
| It's fine to express the gulf of evaluation and execution
| that led to the error. It happened. There may not be any
| better known solutions at the moment to lower the risk any
| further.
|
| Calling them careless is also unjustified. They made a
| mental error processing the information. Whenever humans
| are involved there is a risk of illogical and bizarre
| mental errors in decision making because we are
| degenerating meat robots granted full agency.
|
| Shit happens. How we emotionally deal with it is the test
| of life as a human being.
| media-trivial wrote:
| > and offered GitHub money to help
|
| It's not like they can just run a few SQL queries on prod
| and have the author PayPal them 10$.
|
| They need to create a plan, cost estimate, risk
| assessment, get management/qa/security/SRE/... approvals,
| write the code, documentation, reviews, tests, run on
| prod, create invoice, etc. This means 10-20 people work
| for 1-2 days. I doubt that the author is willing to pay
| 20000-60000$ for this.
| TAForObvReasons wrote:
| https://httpie.io/ has a star display on the homepage,
| and the story https://httpie.io/about alludes to the star
| count:
|
| > That humble tool, which we open-sourced, quickly
| captured developers' hearts and rapidly became one of the
| top projects on GitHub.
|
| > We've raised a Seed Round ...
|
| It's not hard to believe the seed round and the entire
| pitch of the commercial venture was tied to the star
| count, and it's not hard to believe that the author would
| drop $1/star to restore the count.
| some_random wrote:
| Honestly, they are blaming Github here. They included a
| whole "Lessons" section, which are complaints about
| Github's UI, then database design, then community
| support. I don't think we should be making fun of them
| for accidentally privating their repo, but I absolutely
| laughed at
|
| >The dialog should be more contextual and, paraphrasing
| again, it should say "You're about to kill 55,000
| people." That would've certainly made me pause.
| canadaduane wrote:
| > They aren't leaning in heavily to blame Github here.
|
| > Honestly, they are blaming Github here.
|
| I think both of these statements can be true at the same
| time. They are taking much of the responsibility while
| also explaining how some aspects of Github's design are
| partly responsible for the outcome.
| tobr wrote:
| As a UX designer, I don't understand this attitude. Clearly
| there are things GitHub could do to improve the design
| here. That doesn't mean it's GitHub's _fault_ , mistakes
| can always happen.
|
| This screen gives you pretty poor context for your action.
| You can't so easily see things that normally tell you at a
| glance where you are. They also don't offer a good preview
| of the action, or undo, which is how you normally make
| potentially destructive actions less dangerous. Instead
| they made a scary prompt, but since they use that solution
| a lot, users may get desensitized to it.
| jessep wrote:
| This kind of attitude is how bad products get made.
| blindmute wrote:
| Honestly, no. Your type of attitude is how bad products
| get made: products that cater to the absolute lowest tech
| illiterate user. Products that hide and simplify every
| useful tool to the point of annoyance and disfunction.
| Github's warnings are _plenty_ enough. It doesn 't matter
| what Github did; this post would still be made, and you
| people would still be thinking of even more absurd ways
| to make the user not do something. At a certain point, a
| tool has to do the function you asked it to do.
| golanggeek wrote:
| Just my 2c.. GitHub, instead of the statement "All stars
| and watchers", can improve it by showing "All 54000 stars
| and 32000 watchers" will be deleted.
| bmacho wrote:
| It seems a bit few to expect a website to show us which
| repository are we going to delete on the delete page, instead
| of hiding it (or not showing). Datas, charts, content, every
| info that it could gather, and it may matter. Name is not
| enough.
|
| Also I believe that asking us every day the ridiculously
| braindead act, to copy a text from here to there is more
| harmful than it helps, it just sets people to autopilot mode.
| Although I don't have any measures.
| Retric wrote:
| Warnings are vastly less useful than making such activities
| less dangerous.
|
| If you feel something needs get giant flashing warning messages
| perhaps make it reversible for a week.
| pc86 wrote:
| I don't know for sure but I think in some jurisdictions "hang
| on to this data you told me to delete for another week" would
| be a non-starter.
| ratww wrote:
| Which ones? Even in Europe there is ample time for replying
| and complying to GDPR requests. Way more than would be
| needed for this specific case.
| playpause wrote:
| They could simply offer a "move to trash" approach to get
| around any legal restrictions of the kind you are
| imagining.
|
| This would also be much nicer UX. Just click a button to
| delete something, and it says something like "This has has
| been moved to Trash, and will be permanently deleted in 30
| days". No big scary warnings needed. And you can still
| delete it immediately if you want (by emptying your trash
| afterwards) so it's not in breach of any laws.
| IYasha wrote:
| 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.
| CreepGin wrote:
| 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! =)
| wly_cdgr wrote:
| Sounds like Microsoft recruits from the same pool as Atlassian
| for its Customer Success team :)
| yu-carm-kror wrote:
| 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.
| Cthulhu_ wrote:
| > Won't actual fans be right back using and contributing?
|
| Yes, but if "actual" fans are <1% of your existing user base
| then your reach and ranking is still far below what it used to
| be. I'm sure most people on GH don't even remember what repos
| they've starred, and httpie may be one of just thousands, of
| which many will disappear from their starred repos overnight
| without them even noticing.
| barrucadu wrote:
| If a user didn't care enough about the project to even
| remember that they starred it, why is that star being lost a
| problem? It was already the case that nobody was getting any
| value out of it.
| einpoklum wrote:
| 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.)
| kizer wrote:
| Restore their stars! Restore their stars!
| davedx wrote:
| 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.
| hutzlibu wrote:
| "A bad workman always blames his tools."
|
| It is a workman, who builds a very succesful tool for others.
| Not a bad workman by my definition.
|
| And his suggestions of improving the UI sound very solid. Also
| I am not sure, if you got the part, where he pointed out, that
| Github themself made the same misstake for one if their repos.
| Sure, sure, all bad workman.
| fourseventy wrote:
| Couldn't agree more. The author not only messes up his own repo
| while blaming the GitHub UI, he proceeds to then whine that
| GitHub employees won't restore his data from a backup.
| user_7832 wrote:
| If it's a mistake that even a GitHub employee can make with
| very heavy consequences, is that entirely the fault of the
| author?
|
| When Lauda Air Flight 004 crashed because the pilots
| accidentally deployed the reverse thrusters in air, even
| though it was the pilot who "made a mistake", Boeing was
| forced to change their design and now the original design is
| considered flawed.
| hutzlibu wrote:
| But the point he makes, is that Github made the same misstake
| - and for themself they could restore it.
| abuggia wrote:
| I don't think he's blaming HN to the point where he's shirking
| responsibility for what he did. I read this post as a clever
| way to get play on HN which will help him get some of his
| stars/watchers back.
| raldi wrote:
| Completely disagree; when it comes to programming (where all
| tools are infinitely malleable), it's a poor programmer who
| _puts up with_ suboptimal tools.
| kif wrote:
| Maybe the UX is not great, but surely having to type
| "httpie/httpie" would have given me a pause.
|
| Regardless, to make mistakes is human. What I don't really like
| is how the author starts attacking Github and Microsoft, just
| because they can't afford to fix the author's mistake. A huge
| red flag for me.
| hombre_fatal wrote:
| Once you do it a few times, writing the repo names means
| nothing. You have to do it on your repo with 0 followers just
| making it public. It's not very notable unless you're new to
| Github.
|
| My advice is for Github to tell you that you're losing 53,000
| stars (not just "all your stars") to help knock you out of
| autopilot.
|
| I don't get the finger pointing though. Obviously they messed
| up, it's the entire post. But it's also a good moment to
| reflect on how UX can be used to prevent people from messing
| up.
| barrucadu wrote:
| What should the threshold be? 53,000 stars? 50,000 stars?
| 25,000? 100? No matter what number you pick, there will be
| someone with fewer stars who considers _their_ stars
| important enough to merit a warning.
|
| Unless you set the threshold to 1, in which case it's just
| more meaningless noise, like the repository name
| (apparently) is.
| electroly wrote:
| They didn't say so, but 100% they copy-pasted the name from
| the prompt. I always do. They didn't type manually it in a
| way that would help them catch the error. That's a big reason
| that "enter this thing: ______" isn't foolproof. Perhaps it
| should at least be made unselectable.
| FeepingCreature wrote:
| Good workmen also blame their tools. Because sometimes tools
| are bad, and that's how they get improved.
| matsemann wrote:
| > _"A bad workman always blames his tools."_
|
| That's a meaningless statement, though, as it can always be
| used against anyone complaining about something. I mean, you
| yourself wrote this the other day:
|
| > _I had to work with SAP Hybris a year or two ago. My IDE was
| not smart enough. Well actually I spent a good number of days
| trying to configure my IDE to be able to work properly with
| Hybris. I failed. What a mess_
|
| Are you a bad workman blaming your tools? Or do some tools just
| genuinely have faults?
| Kronen wrote:
| he said "I failed" not "the tool failed"
| matsemann wrote:
| While lamenting the tools. They also wrote "my IDE was not
| smart enough".
| mihaifm wrote:
| > 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?
| prtkgpt wrote:
| I would love to help rebuild the community.
___________________________________________________________________
(page generated 2022-04-15 23:01 UTC)