On Thu, Feb 28, 2019 at 3:47 PM Robert Mayr <robyduck@xxxxxxxxxxxxxxxxx> wrote: > > > > Il giorno gio 28 feb 2019 alle ore 20:21 Rick Elrod <codeblock@xxxxxxxx> ha scritto: >> >> Good day, websites list! >> >> As time goes on and requirements change, I've found that as I've been >> leading the websites updates for the past several releases, they have >> gotten to a point where they aren't scaling very well. I don't purely >> mean from a technical standpoint. >> >> We've had the same websites setup for a lot of years now, and over >> time various "hacks" have been included in our scripts and templates. >> Things that were meant to last for one release, but ended up lasting >> indefinitely, for example. In addition, we've had the same landing >> site templates on our sites for a few years now, and visually, it's >> perhaps time for a change. > > > Ok, I have done this for many years since F16, mostly alone, and I think not all what we have is that bad as you describe it. You should not throw all the work in the trash. > Hacks which were thought for one release have been commented out or in, as we need it, but these comments were not considered during the last release for example.... > I agree that we could think about a "visual" change. I'm curious which comments you're saying weren't considered. But to be fair, the website maintenance was something that essentially fell on me last-minute for the last major release (and the last few betas). So it *is* very likely I missed some comments as I was scrambling to get things done. But even in the templates, I have found a fair but of code that was meant to be removed after one release, along with various version numbers hardcoded (particularly in links) that have fallen out of date, and so on. Further, I think that static site generators have become quite popular and improved quite a bit since the current websites build system was pieced together. I think there are things in modern site generators that can take some workload off of us and give us fewer things to worry about. Ryan's concern is one such thing. Other examples are asset bundling (right now loading getfedora.org makes a whopping 61 requests for static assets, a lot of those can be bundled into one or two asset packages at build time), and general ease of use (new contributors are perhaps more likely to be familiar with modern static site generators than our NIH system). Personally, I am fine with keeping the current system if it is in-fact the best tool for the job. But the proposal calls for looking at other tools and seeing why that is or is not the case. I will say that I have heard from others - people who have a fair number of commits in the repo - that the current system has made it hard to accomplish changes they wished to make and was overall hard to get a full understanding for. > >> >> >> So what I'd like to propose is a redo of the websites repo as we know >> it. I've written up a very rough draft specification [1] that outlines >> some of my ideas as well as some ideas from Ryan Lerch. This >> specification is certainly not set in stone, and is not complete yet. >> However, I wanted to throw it out to the list and ask for comments. >> >> It is largely broken into two key sections: Backend work and frontend work. >> >> >> On the backend, I believe we could benefit from looking at modern >> static website generators and shifting from our custom solution to >> something newer and better supported. As stretch goals, we could also >> look at the infrastructure side of things and change up how >> deployments work. However, that might be out of scope for the first go >> at this spec. > > > That is the same discussion we've had years ago, the problem was that websites with specific targets and specific layouts for that goal, have been changed by several requests from the single SIGs or developers, which asked for additional stuff at every release. i.e. getfedora.org had a specific target, actually it is not the thing we wanted to have originally. > If you decide to go for a static generator, these changes will require even more work, and AFAIK you do not have the people to do that. (which also is the reason why I was not able to make all the changes I had in mind over the last years). Would you mind elaborating here? What extra (long-term) work would using a static generator cause that we don't incur now? (Note I'm not disagreeing with you, I am just trying to achieve a better understanding). > >> >> >> On the frontend, I have suggested working closely with Ryan and the >> design team to have a small set of templates/themes that sites >> inherit, which provide a modern and unified look across all of our >> landing sites. > > > I think we already have a unified look over the single websites. > >> >> >> I think there are many advantages to doing this and it provides a >> great opportunity to rethink our tooling and processes here. However, >> it is vital to both myself and to the project that this be a community >> effort. >> >> I would love to hear thoughts on what I have written so far, >> suggestions for tooling (static site generators?) that we as a team >> should be considering (short experience reports are useful here), or >> any other feedback that anyone has to make this work as well as it >> can. Our websites provide users with a first look at who and what the >> Project is and what we stand for. I feel that leveraging that >> appropriately can lead to great things for the Project and help to >> spotlight the technologies being focused on by various teams. > > > Our websites are really simple and I don't see so many advantages to have generators. Think about translations and add ons, these are easier to manage in our custom solution. Again, could you elaborate some here? Why are they easier in the custom solution? Most of the site generators I've looked at (some in more detail than others) seem to have support for i18n either through well-supported plugins (Jekyll) or out of the box (Hugo). What does maintaining the custom solution buy us here? Similar for custom add-ons, I know most of the modern generators are extensible in their native language (e.g. Ruby for Jekyll, Python for Nikola and Pelican, etc.) - it seems like porting over the add-on scripts wouldn't be that hard, but I am open to the fact that I might be missing something. Rick > >> >> >> Let's revitalize our Project's websites! > > > Yeah, but consider the actual situation too. > >> >> >> Rick >> >> [1] https://fedoraproject.org/wiki/Infrastructure_2020/Websites >> _______________________________________________ >> websites mailing list -- websites@xxxxxxxxxxxxxxxxxxxxxxx >> To unsubscribe send an email to websites-leave@xxxxxxxxxxxxxxxxxxxxxxx >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: https://lists.fedoraproject.org/archives/list/websites@xxxxxxxxxxxxxxxxxxxxxxx > > > > -- > Robert Mayr > (robyduck) _______________________________________________ websites mailing list -- websites@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to websites-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/websites@xxxxxxxxxxxxxxxxxxxxxxx
