Refactor: reorganize, split into pages, and order by notability about dotfiles.github.com HOT 11 CLOSED

I'd be in favor of avoiding JS.

We could have a script in the repo and periodically run it to re-sort the items, and then commit these changes. Someone would have to do this manually (or I could write a simple bot to do it).

Since the site is currently deployed with GitHub Pages, we can't really do it during generation time with something like a Jekyll plugin. Another option is that we could switch to doing deployments through Travis CI, and then we could do it automatically at deploy time. (I think it still wouldn't auto-update unless there are new commits, though.)

from dotfiles.github.com.

I was unclear - I meant embedding javascript into the page. I like your idea of using travis/GH actions to render the markdown that is displayed from a source markdown file based on whatever metric we end up deciding on.

from dotfiles.github.com.

I heartily endorse the above topical breakdown.

So long as I'm not doing the work, I'll toss out the notion of curated configs.
Blessed, managed, maintained, working, fully-functional as-is configurations with a semi-specific target audience,
eg:

• python dev with vim & zsh ala zplug
• java, intellij | vsc, zsh ala ohmyzsh
• perl/emacs/ksh (just kidding)
• etc

Or, is that what you, @anishathalye, mean by bootstrap repos?

The effort needed to pick each dot<thing> and read the readme's install, config, without stepping on the other, related, dot<thing> configs is ridiculous. Not to mention getting the path/completion/sort ordering right for the whole mess.

I'd pay a sub fee for an awesome everything env. I can't the the only vim/vsc/pycharm/zsh/zplug/aws with bits of java tossed in person.

from dotfiles.github.com.

Or, is that what you, @anishathalye, mean by bootstrap repos?

Yes, I think we are talking about similar things, though I don't know if we're talking about exactly the same thing.

Here's what I was thinking. Currrently, the website links to a ton of dotfiles repos in the "bootstrap" section. Most of them are just random people's dotfiles, and they aren't exactly designed to be used as-is by others, and in my opinion, they're more suitable as inspiration. But there are certain links like mathiasbynens' dotfiles in the current list that I think are more like "bootstrap" repos, in the sense that they are a good starting point for building on top of (or just using as-is with no modification).

Also, I'm not sure what exactly you meant by "curated configs" --- that seems like it could be tough. The current list does not make any attempt at curation; anyone could open a PR and add their stuff to it. I'm proposing some quantitative criteria for notability, and sorting by a quantitative criteria. Doing qualitative curation seems like it could be tough: who would decide what goes in the list?

from dotfiles.github.com.

This seems related to #2 / #3. @pengwynn, do you have any opinions on this issue?

from dotfiles.github.com.

Thanks @anishathalye. I'm onboard with the outlined work above. I also think we've outgrown our stock GitHub pages theme. I'm happy to contribute on the Jekyll side. Would love if we could round up some design help to create a clean layout that supports your proposed content hierarchy.

from dotfiles.github.com.

Cool! I could work on the content / refactoring over the holiday break. I'm comfortable enough with Jekyll that I could do the first attempt myself (it seems hard to parallelize), and I'll submit a WIP PR (and I'll definitely ask for help if I get stuck).

Where some collaboration / discussion might be helpful is things like deciding on notability criteria.

Moving away from the stock GH pages theme seems like a good change. Were you thinking of using some other open-source theme, perhaps modified to fit our needs, or having a fully custom design? Also, do you think the content / refactoring could be handled separately from the restyling? I agree that it would be awesome to have a new design, but I think the new content hierarchy is a fairly orthogonal change?

from dotfiles.github.com.

I think refactor first, then we can pretty it up.

from dotfiles.github.com.

One note: if we are sorting by stars or some other dynamic metric, then either you will need JS on the page to check the current star count via github API, OR you will need a script to generate the listing at deploy/static generation time (sometimes fully static page is an attractive quality, so something to consider)

from dotfiles.github.com.

I'd prefer to avoid JS-generated lists, if only because it'll add friction when people submit new collections.

from dotfiles.github.com.

I'm a little confused.

If we want sorting by stars (or whatever metric), some computation will need to happen. It could happen at commit time, deploy time, or page view time. Only the last option, page view time, requires JavaScript, the others can be more flexible in the exact method they use.

But based on my read on your comment, you'd prefer to avoid requiring a script that runs at commit time?

from dotfiles.github.com.