Access Control for GitHub Pages
github.blog
github.blog
Public service announcement: "login" is a noun; as a verb, you should write "log in". (Consider "knockout" vs. "knock out".) Another thing to watch out for: writing "setup" instead of "set up".
Noun: LOGIN => - a LOGIN - some LOGINS
References: https://grammarist.com/spelling/log-in-login/ https://en.wikipedia.org/wiki/Phrasal_verb
We avoid mic (verb) because the "k" works so much better than "c" when leading into various verb endings like -ed and -ing. It's the same reason we add "k" to the word traffic to form words like trafficking; we would interpret the "c" softly ("s" sound) if it was followed by a vowel. But in this case we replace it with "k" instead of adding "k" to maintain the long "i" which would shorten if followed by more than one consonant.
Mic (noun only) is great as a truncation of microphone, though.
I don't interpret a meaningful difference between "can not" and "cannot," nor between "any more" and "anymore;" thus, I don't find a meaningful difference between "in to" and "into."
I use this extensively on gitlab and these little pages sites are easier to use than markdown.
However one thing that’s cool about GitLab is that we host it internally so any “public” site is available to anyone on the intranet without needing to log in. So the project sites started getting read by lots of users who don’t have GitLab logins and would never commit to a repo.
I wish there was a way to link my orgs logins with GitHub so non-GitHub licensed users could view the sites. I mean, I can do that but I have to then buy GitHub licenses and make them create GitHub accounts just to view project docs. That’s pretty expensive compared to just keeping projects on my internal GitLab.
The solution needed is to allow oauth-style authentication of corporate users.
https://docs.gitlab.com/ee/user/project/pages/pages_access_c...
All it needs to be is a wiki. Instead it requires layers of admin and stuff 5000 settings that don’t work. And it’s really expensive.
Obviously you could make the Github Page load a dynamic page that checks auth, but I guess they wanted scalability more than they wanted features, and that's what we arrived with.
TL;DR: I'm not that baffled. If a feature isn't in the spec, you shouldn't expect an implementation that makes it easy to add that feature.
I could easily be completely wrong about this. But it's interesting, to me, to consider the order that features were requested, and how that affects future feature requests. Sometimes you paint yourself in a corner and make easy things hard. Something to think about as you plan your own software!