GitHub is experimenting with personal READMEs
twitter.com
twitter.com
# [CLICK HERE FOR MORE DETAILS](https://mysite.tld)There’s about a thousand things I wish they would fix or add before this. They still don’t allow videos so every screencast demo on GitHub is still a giant GIF, right?
I used to like GitHub so much I paid out of pocket even when I was unemployed. Now it’s on my list to check out GitLab again. Companies don’t know when to stop. It’s like they created the bicycle and add another wheel every year as an improvement.
I'm certain they have more designers or developers working on other features as well.
I remember a few years ago people were saying Github development seems to be stuck due to legacy issues and they couldn't compete with Gitlab in terms of features.
It would be a huge plus for me if I can sort the code search results and get results from most starred repos on top.
Currently, we can only sort results by time and relevance.
A couple of things I _feel_ (based on personal usage):
- When I search `import package`, I rarely want the package itself, but usage examples.
- There's a lot of repetition from forks.
- Keyboard shortcuts: I’m always triggering these by accident. There’s no easy way (AFAICT) to block or disable them. My browser and OS already define a bunch of keyboard shortcuts. Please don’t steal existing shortcuts for non-standard uses.
- “Mobile” view: this hides so much it's nearly useless to me. (And the desktop view is a pain to use on my phone when I want to check one little thing.) 100% of the reason I use GitHub today is because -- by default, with no action required -- it displays the (entire) README, and the list of files. That’s what GitHub is.
- “?w=1” has always been one of the most useful features of GitHub. It’s completely hidden, hard to use (it messes up my browser history), and easy to forget.
- Releases/Tags: this page has only Next/Previous, no page numbers. If you want to get to an old release, you have scroll down and click "Next", and then repeat that dozens of times. “git tag” is fast (right?), so I’m not sure why normal pagination is missing here. Other GitHub lists have it. (Oh, I just found from poking around that "Subscriptions" also has only Previous/Next. I think that one's new.)
- “Issues" attachments: only a handful of file types are whitelisted, and it excludes 10 common ones I want to use (not just videos). I’ve never been able to figure out why. Is there some security issue we're avoiding by making people rename their .csv files to .txt before uploading them?
- "Issues" email responder: I see people send attachments here, and it silently drops them, instead of attaching them to the issue, or sending them a response that it doesn’t accept attachments via email. I’m tired of talking people through this. At this point, I wish I could turn off the email responder entirely, because it’s more trouble than it’s worth.
And finally, my Completely Unreasonable Requests:
- DOM stability. For example, when I'm not logged in, there's that giant "Create your own GitHub profile” banner, with the confusing “Dismiss” floating over a busy background, near the weird icon that looks like it might almost be a close button but isn't. I guess you have to always upsell, but nothing on github.com seems to ever have a stable DOM class/ID, even when there’s no reason to change it, so I regularly have to edit my user stylesheet to fix or block things I don’t want.
- “Issues" are the only major part of a GitHub project which aren't repos, so there's no easy way to back them up, or use them offline, or query them from a shell, or ... The GitHub docs always suggest some third-party API-based method for backing up Issues, and I've never gotten any of the free ones to work, and I shouldn't have to pay someone else to retrieve my own data. (The cynic in me guesses this is GitHub's primary mechanism for lock-in.) It feels like GitHub is a 2000's-era version control system, with an SVN-era bug database.
Thanks for listening to my ramblings!
MS owns LinkedIn. This very much looks like an effort to turn GitHub profiles into LinkedIn-style profiles.
This is not going to be pretty.
Having a good one is a plus, but having a poor one is worse than not having one.
I'm not following them because we have reciprocal social arrangement where we're "friends", or because I want to chit-chat with them, or see what they're eating, or what asinine 280 character fragments of streams of consciousness that they emit into the void, or to participate in the typical "best foot forward" profile stalking and preening BS that I can't stand about social media.
GitHub is a social network, no doubt, but it is not social media and I hope that does not change.
I'm not sure if I'm convinced this has worked as a bookmark for my repositories: no one ever removed a star from any of them, and no one ever returned with any feedback later. It could be a matter of a small sample size, or of people never actually coming back (which is the bookmark's use case).
They are just leaning into it more.
Stop trying to make it a social network.
I don't have any memories of early GitHub but did any of it's competitors come close to being as good?
I've had to resort to human-side rendering to put LaTeX/math in a GitHub flavored markdown file.
To me, Emojis have a place when you're discussing with others and socially interacting. May be even in code reviews to reduce friction and add some human emotion to what you're saying in cold words. Use it to chat with people - totally ok.
Documents with emojis is definitely an anti-pattern IMO. To give an extreme example, can you imagine reading python docs with Emojis? Or Tolstoy? What about tax documents with emojis? Court proceedings? Job resumes? Aircraft emergency checklists?
I don't like emojis so I don't use them. I have no interest in demanding how other people define their docs.
"I don't like emoji. How do they make you feel?"
I definitely do not want emoji's in official documents, emergency procedures, etc. And I would demand for the same - emoji's are at best decorative, and a lot of times a distraction. Most documents that are of importance to me should be straightforwardly written - and that means no emojis.
> Gender difference is always an important research topic in sociological and psychological studies from which there are many interesting findings. For example, females are evidenced to show a greater number of facial activities than males [40, 41] and observers can identify emotional states more accurately from female faces than from male faces [39]. With the advancement of data science methods, these hypotheses and conjectures about gender differences are measured and tested quantitatively through analyzing online behaviors of users at scale. For example, when the “facial expressions" (emoticons) become popular in text, researchers investigated the relationship between gender and emoticon usage and found superiority of females in using emoticons [44, 48, 54], which verifies the sociological findings about non-verbal expressivity of females [2, 18, 29].
Not that this means YOU specifically need to like emoji, but it's probably important to recognize that preferences and usage patterns differ by gender (and neurotype). Male minds (for whatever reasons) are often less likely to use and rely on them.
Interpretation of any data is fraught (nature? nurture?), but it may be that emojis make documents more legible to certain minds, which perhaps have different optimal conditions in which they process information.
So "Emoji are an anti-pattern" perhaps only holds true for neurotypes that don't depend as much on non-verbal signals when processing information. The opposite may be true for others. E.g. Cultural norms aside, maybe emoji in a resume would actually help certain hiring managers select the best candidates. (heh that's probably a more dramatic claim that I'd actually stake my case on :) )
- Tolstoy: No, he's not gonna writing anything new, so I can't imagine a way someone could insert emojis into his work.
- Tax Documents: No. Government employees won't care enough to put in the effort.
- Court proceedings: Reason same as above.
- Job Resume: Yes. Probably already exist.
- Aircraft emergence checklist: No.
Some of these are too extreme. And such a slippery slope is a logical fallacy.
There have always been people who put playful things into documentations and notes/wikis/resumes, before emoji became so wide-spread. Government documents and emergency checklists never.
Similarly, AFAIK every document in Notion has an icon associated, and when every document just has a placeholder page icon next to it - it looks ugly.
Disclaimer: I am on the younger side on the age spectrum.
I quite like how it looks, but it enrages me that if I try to do it, it ends up more gaudy than when I read others' docs :)
Ive found browser extensions have been a great way to augment and customize my Github experience, bringing quality of life improvements that Im grateful to have every day.
My top two favorites are:
Refined Github [1] -- huge collection of quality of life improvements. e.g. always sort issues/PRs as most recently updated first, when recently pushed to a branch show a button on project page (or upstream of fork) to open a PR based on that branch, quicklink to most reacted to comment on an issue page. Also provides a surface to inject custom CSS for personal tweaks.
Octolinker [2] -- Turns require/import/include paths in files into hyperlinks to that file or repository. I use this every single day to navigate code in projects.
I know that extensions aren't a panacea, but personally I have found them be very valuable to my workflow.
This is actually a default feature. You don't even have to refresh the page for it to show that bar.
We have something similar internally - we call them personal user manuals. They explain how we like to work (e.g. communication preferences), and a little bit about ourselves.
We ask new joiners to write theirs when they join. They make a good introduction to the company and can provide guidance when wondering how best to interact with others.
On the other hand, most profession's do have portfolio's and other mechanisms to share work with new potential employers. For some reason developer's seem to think a hiring decision should be made entirely on a a handful of 1 hour interviews conducted in a single day when their work will usually have massive direct impact on the companies product.
I think there's mostly positives to this and some downsides.
As opposed to... some generic profile on a central site? I don't think that is a substitute to actually talking to a candidate.
But what do I know? If I understand sites like HN correctly, talking to a person is not a good way to discover whether he/she has any skills, so maybe this is better from a recruitment standpoint. But I'm not going to create a personal profile there. For the simple reason that the words 'personal' and 'follow our format' don't go together in my mind.
Why? Because context is powerful. When people are viewing your resume, you want 100% of their focus on you, and you want to present yourself in exactly the way that's best for you.
You don't want to present yourself within the context of another org's branding, site layout, etc, which by definition won't be optimised for you, and also syphons off some of that attention you want focused on you (as the most obvious example, say if the top bar has unread notifications).
The irony is with Github, hosting an HTML resume 'on' Github is possible and really easy already via GH pages. It's what I do :-) https://davnicwil.com/cv/
Maybe even a git hook to do it automatically.
[0] - https://www.profiled.app
My second thought was "Hey if I used this I could delete my stupid Linkedin account."
But this emoji fascination is beyond me.
It's not at all unusual for recruiters to ask about your github profile. The code repositories are the resume. The personal README is the cover letter.