Il giorno gio 28 feb 2019 alle ore 20:21 Rick Elrod <codeblock(a)elrod.me> ha
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
I agree that we could think about a "visual" change.
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  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
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
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).
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
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
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.
Let's revitalize our Project's websites!
Yeah, but consider the actual situation too.
websites mailing list -- websites(a)lists.fedoraproject.org
To unsubscribe send an email to websites-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines