Cleanup / restructure img folder

[carpodaster]

No description provided.

[alicetragedy]

YES PLEASE 🎉

[lislis]

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

[alicetragedy]

@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?

[carpodaster]

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 :)

[anikalindtner]

@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

[alicetragedy]

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 :(

[carpodaster]

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. 😄

[sareg0]

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)
.

[carpodaster]

@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.

[carpodaster]

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…

[alicetragedy]

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

[anikalindtner]

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

[sareg0]

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…

[sareg0]

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

[carpodaster]

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.

[alicetragedy]

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?

[carpodaster]

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.

[alicetragedy]

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

[alicetragedy]

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

[carpodaster]

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

[alicetragedy]

@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 🙄

[inescoelho]

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.

[carpodaster]

@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?

[inescoelho]

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