[HN Gopher] We lost 54k GitHub stars
___________________________________________________________________
We lost 54k GitHub stars
Author : todsacerdoti
Score : 258 points
Date : 2022-04-14 21:51 UTC (1 hours ago)
(HTM) web link (httpie.io)
(TXT) w3m dump (httpie.io)
| 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.
| 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!
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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:
| 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.
| 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?
| 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.
| 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."
| [deleted]
| 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:
| 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]
| 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).
| [deleted]
| [deleted]
| tomphoolery wrote:
| This happened to me as well. It's sad that GitHub doesn't retain
| that data.
| 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 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.
|
| 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 :)
| ncmncm wrote:
| > " _that GitHub couldn 't restore it_"
|
| What an odd turn of phrase.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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"
| 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.
| 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?
| 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.
| 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.
| 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
| 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.
| 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.
| 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?
| 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.
| 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.
| 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.
| 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?
| [deleted]
| 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
| 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.
| 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.
| V__ wrote:
| But couldn't the same be achieved without taking it private?
| catsarebetter wrote:
| Starred and watched again, it's a great project, hopefully the
| whole audience comes back soon
| 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.
| 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.
| 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.
| 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
| 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.
| 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.
| 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)."
| 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."
| 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.
| 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
| 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".
| 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 :)
| 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).
| 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
| 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.
| 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/
| 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.
| jacobolus wrote:
| Restoring the star/follow status for miscellaneous Github
| users after an accidental hiding of the repository is not
| revealing anyone's secret information.
| 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".
| 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.
| 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.
| 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! =)
___________________________________________________________________
(page generated 2022-04-14 23:00 UTC)