Cleanup / restructure img folder about summer-of-code HOT 24 OPEN

YES PLEASE 🎉

from summer-of-code.

One thing I'm thinking about: if we move the images, we would need to check all the paths in the blog. There is no easy way for that i guess

from summer-of-code.

@lislis yep, you are totally right - no easy way to handle this 😞
but it is possible to figure out an image folder structure starting from now? I'm not sure how we want to do this. Any ideas?

from summer-of-code.

I suggest to move all images referenced by a blog post into a /img/blog/ folder as the very basic convention. I also recommend prefixing image files with something that hints at their purpose, but I don't have a more concrete vision yet :)

from summer-of-code.

@carpodaster there was a reason though why we didn't do it like that before -> E_TOO_BIG_REPO. I love the idea of doing it somewhere else like a google drive or dropbox account

from summer-of-code.

well, as of now it seems that a lot of the blog images are actually hosted in the GitHub repo, no? Maybe the biggest problem is eg. that when we fork the project for the new year (like we did last weekend) we are carrying the old blog posts (and folders with images) into the new repo. But I guess that with the blog archives, getting rid of that old stuff in the current fork is not an option.
Taking the example of the blog, I feel that the images for it should be in the same spot where the blog is (simply to make it easier for new people and contributors). But I understand that we will have a space problem at some point... I've never linked to files in google drive or dropbox before from a blog, I feel like it might get messy somehow. a drive or dropbox gives me the feeling that I can move stuff around without messing with resources linking to the files in there, does that make sense?
I've just never used it for that purpose but maybe there is a way to do so.
In any case: if we do go down the external image linking road, we have to DOCUMENT ALL THE THINGS.
Other problem with an external service is that a) we are depending on it b) working locally with, say, no internet (yes I know, 2015 and all, but who knows) sucks when all the image links are broken while you're offline.

hm... it's difficult, I don't really know how to handle it :(

from summer-of-code.

I'm strongly in favor of having all the images in the repo. Repo-size should only be a problem when you clone it and should be neglectable with a resonably fast broadband connection. We can filter the images through something like ImageOptim and/or shrink their sizes/dpi; I think some of the images are rather big. I'm up for a big sorting session, including moving the images hosted at GH into the repo. 😄

from summer-of-code.

Happy to help with a sorting session. Is there a time/day that would suit?

On Friday, 6 February 2015, Carsten Zimmermann [email protected]
wrote:

I'm strongly in favor of having all the images in the repo. Repo-size
should only be a problem when you clone it and should be neglectable with a
resonably fast broadband connection. We can filter the images through
something like ImageOptim and/or shrink their sizes/dpi; I think some of
the images are rather big. I'm up for a big sorting session, including
moving the images hosted at GH into the repo. [image: 😄]

—
Reply to this email directly or view it on GitHub
#8 (comment)
.

from summer-of-code.

@sareg0 Sorry for the late response. I'll be having a look at it tomorrow afternoon and/or on sunday. I'll lurk on Slack.

from summer-of-code.

Part one done. I moved the images embedded in various blog posts to an img/blog/<year> subfolder and prefixed them with a name hinting at the article that includes them. I also resized several of them and deleted unused ones while I was at it. img/ now has 5 MB less.

Next up: tackle all the images referenced externally…

from summer-of-code.

that's amazing!!!!!!! thank you so much for all the hard work, I'm sure it was tricky/long/annoying... ❤️

from summer-of-code.

👍 👍 👍 👍 👍 👍 👍 great work 👏 👏 👏 👏 👏 👏 👏

from summer-of-code.

I totally flaked on this. Sorry Carsten.
Is there anything that can be done to help you with the ;
Next up: tackle all the images references externally…

from summer-of-code.

How are we coming along with this one? I'm guess it's still a work in progress

from summer-of-code.

I think we can safely close this. Downloading the images from the github cloud and storing them in our repo is not gonna happen anytime soon … if at all.

from summer-of-code.

I think it would be good to leave it open though, so we don't forget about it. It doesn't need to have a high priority, more like something that needs to get done eventually.. or do you reckon it's not so important @carpodaster?

from summer-of-code.

I think it's maybe safe to assume that Github won't delete images (or is it?) so I'm ok with ignoring the f.cloud.github.com img references. We could comb through the blog and get those externally referenced images into the repo where the location seems more volatile.

from summer-of-code.

I'm planning to take care of this.. eventually.. maybe before the start of the program.

from summer-of-code.

@carpodaster should I remove you as an assignee from this and have it “up for grabs”?

from summer-of-code.

@alicetragedy oh sorry, totally missed that I am still assigned to this.

from summer-of-code.

@carpodaster to be fair you did want to close this issue and I did write “I'm planning to take care of this” so yeah, it's on me 🙄

from summer-of-code.

Since Laura brought this discussion up from the deeps of our issues list, I would like to add my 2 cents.

As much as I like to have all the images on the repo, I feel that the RGSoC repo has become too huge to handle. Maybe we should bring the external storage discussion back into the table. But we don't need to go as far as using Dropbox or gDocs -> how about a GitHub repo only for images?

If we use GitHub, we can use the absolute link to the image, the same why we'd do with Dropbox or gDocs, but keeping the same organization we have now. However, I think GitHub can also be advantageous to us because it is possible to use relative links between different GitHub repos published in the same Github pages. But I have no idea if jekyll might find this problematic.

Let me explain with an example. "rails-girls-summer-of-code.github.io" is the root of our GitHub page, which is linked to our URL "railsgirlssummerofcode.org". If we create a repo called "images" with "photo.jpg" and publish the repo on GitHub pages, the image will be found at "railsgirlssummerofcode.org/images/photo.jpg". My belief is that we can access that image in any repo published on the RGSoC GitHub pages by using the relative link "/images/photo.jpg".

Let me know what you think and I can look further into this.

from summer-of-code.

@inescoelho I'm very much in favour of a solution that involves an external storage. S3 comes to mind. The question is: how do we get it there easily? When students add images to their blog articles, how are they currently doing it? Do they add the actual image file to their PR or to they reference the image using a full URL?

from summer-of-code.

@carpodaster they usually upload the image file in the PR and refer it by it relative URL

from summer-of-code.