Long Term / KDE.org Design Update

Fri Jul 17 17:34:39 UTC 2015

For all practicality we'll also need to realise that we'll be eating a
bullet from some groups no matter how we go. I also think that, while it
may be easier for WWW members to just upload a file onto the server and
translators can commit, this simply isn't an option for the wider
contributor base. I have no problem being the go-to scapegoat for any hate
that comes in; especially if it means making long-term choices which people
don't necessarily understand in the immediate tense after an update. If you
guys guys are willing to go to a web-based management method with me,
punching-bag is a service I'm willing to provide.

Generally, my preference is to prefer full automation over any workflow,
since the best workflow is not needing one. But to automate things, we need
to use database-driven forms. We can build in or specify permissions which
allow users/projects to be more self-managing. Less technical users can
participate. We can better create feeds and outputs which can be used for
automation. More structure means less failure potential too, and more
future-proofing. Ideally, the majority of KDE.org data should be
structured, if not all of it.

When it comes to just uploading files, this is, in my opinion, the single
biggest thing killing the website. Flat out. It immediately prevents
community participation. I don't know the structure of the translation
files, so I don't know how they are applied in the concept of a large
website, but if using a form-driven approach means more reusable
translations, then that to me is an immediate win. I honestly don't believe
we can significantly advance the KDE.org website if we rely on commits for
content. Additionally, there may be more potential translators for the
website if providing those translations isn't tied to a highly technical
process.

When it comes to Frameworks release announcements, I know there's a huge
amount of work already and announcements are just an added responsibility;
but if the time and effort is an issue perhaps opening up the tools for
another person with extra time is exactly the thing to do. When a release
announcement is made, it represents hundreds of hours of work - and I
apologise if I'm being petulant - but not wanting to take a few extra
seconds to log into a CMS is shortsighted if it potentially derails a much
larger improvement. Alternatively, I don't know how your reports are
compiled, but since I'm a fan of automation if we really *can* script the
frameworks and point release announcements completely I would suggest we
definitely go that route, especially if we can improve data-driven
announcements and build more complex documents permanently by tweaking a
generator.

For Plasma releases, those contain our most visible work. I think those
release announcements should continue to be treated with a great level of
attention, and we've done great with this; lots of images, sectioned
content, etc. I think these can be made easier and even nicer to do, with a
CMS, with more professional results, with less work. I honestly think we
could get beautiful Apple-like results.

I don't think you guys should need to individually add/remove apps to
things like category pages, or remove old obsolete programs from the
website, and if we can automate frameworks announcements that would be good
too. If an application authors interaction with a small form will automate
70% of our content, then I believe it's in the authors best interest to
keep their information up-to-date. If an author or team doesn't have the
time or willpower to visit a form once a year - it makes me question the
viability of a project. And again, if we automate things (like pulling
update info from RSS feeds), this mitigates this even further, as authors
going about their usual business would hopefully trigger those updates.

Anyway, I guess what all this boils down to is; if we use forms and
databases whenever possible, we can generate enough content to offset the
additional effort of logging into a web-based tool. I think we can also
eliminate a lot of the busy-work you guys are stuck doing. Translations are
a tough spot, but we have to accept that we may not get our cake and eat it
too; we will just need to provide the best tools possible for the
translations teams on the web end, and with content more structured than a
wiki we should be able to make more lasting translations which propagate
smartly throughout a new system. If it really isn't working, we could find
some way for the site to just import PO files.

Would this sort of direction work?

On Wed, Jul 15, 2015 at 6:07 PM, Albert Astals Cid <aacid at kde.org> wrote:

> El Dimecres, 15 de juliol de 2015, a les 17:11:12, Ben Cooksley va
> escriure:
> > On Wed, Jul 15, 2015 at 5:25 AM, Albert Astals Cid <aacid at kde.org>
> wrote:
> > > El Dimarts, 14 de juliol de 2015, a les 09:35:10, Ken Vermette va
> escriure:
> > >> Between Drupal and Wordpress, Wordpress is in a hilariously awkward
> spot
> > >> for me; tooting my own horn I used to make Wordpress do crazy things,
> and
> > >> I
> > >> know how to code that platform to do impressive stuff. For example, I
> > >> know
> > >> I could make a pretty good custom post type which could handle
> > >> application
> > >> entries easily. I also know how to make it look beautiful.
> > >>
> > >> On the other hand, I *hate* Wordpress with a passion. Partially
> because
> > >> of
> > >> it's security track-record, mainly because it encourages some bad
> design.
> > >> Apparently they've put effort into the security of the thing, but
> plugins
> > >> are the big area where security falters as well. I'd almost be
> content to
> > >> limit the third-party plugins for security reasons, using only a few
> > >> in-house plugins to provide custom page/post types.
> > >>
> > >> I don't know Drupal, but from what I understand you can make it do
> > >> equally
> > >> impressive backflips - but I don't know a lick of Drupal. I don't mind
> > >> studying it adding the thing to my resume, but I can't vouch that the
> > >> first
> > >> run of plugins will be optimal.
> > >>
> > >> There's a few things I think we really need to consider, and perhaps
> we
> > >> should make a checklist of things we need, and go CMS to CMS and see
> > >> which
> > >> ones offer the best faculties - here's what's on my docket;
> > >>
> > >>    - Easily extend the system with custom types for app entries,
> release
> > >>    announcements, general news, etc etc.
> > >>    - Good administrative options with permissions; we should be able
> to
> > >>    easily grant people permission to make changes in specific areas.
> > >>    - Good multi-language support, and an easy method for i18n teams to
> > >>    submit translations.
> > >>    - Good security track-record. If half the web team dies in a tragic
> > >>    beer-pong accident we need to know the site won't crumble.
> > >>    - Easy paths to integrate other systems; specifically phpBB and
> > >>    KIdentity. I think KIdentity integration will be important.
> > >>    - Support for AJAX APIs or a straightforward way to hack em' in,
> > >>    ideally
> > >>    continuing the KIdentity support.
> > >>    - Support reasonably good coding conventions.
> > >>
> > >> Thoughts? More points?
> > >
> > > You're thinking all this from a web programmer point of view, from my
> KDE
> > >
> > > point of view:
> > >  * I like that i can make the announcements from svn since i copy the
> > >  file, do>
> > > some replacements and i'm set, i could even script it if i wanted
> (AFAIK
> > > David has some scripts for KF5 announcemnts), no need to fire up a
> > > browser, remember some extra user/pass i may have forgotten (this is
> > > eased if we get identity.k.o integration), etc.
> >
> > Note that this will severely curtail our ability to find people
> > willing to generate and maintain content for a website.
> > The sort of people interested in working on this tend to be
> > non-technical types for whom Subversion is hard, and Git is
> > impossible.
>
> I'm not saying commiting files *has to be* the only option, but for those
> doing the work of doing releases now (at least me), it is a much better
> workflow if we *can* use it.
>
> >
> > In any event, i'd like something that imposes uniformity to the
> > content (Markdown, Jekyll templating, etc) so we can play with styles
> > more easily in the future rather than having CSS hacks everywhere....
> >
> > >  * Our translations teams work on .po files they get automatically
> updated
> > >  to>
> > > svn together with all the rest of software translations, they commit
> the
> > > updated .po file and stuff magically happens. Making them learn a
> > > different
> > > interface for translating just the web is probably not going fly (yes
> this
> > > is the same problem with the wikis, i've been saying this is not good
> for
> > > a long time)
> >
> > As in you want the Wikis to flex to how the translators work, or
> something
> > else?
>
> Yes, it's better having a single workflow than 30.
>
> Cheers,
>   Albert
>
> > > I'd like those properties to be kept in any possible change for
> kde.org
> > >
> > > Cheers,
> > >
> > >   Albert
> >
> > Regards,
> > Ben
> >
> > >> On Mon, Jul 13, 2015 at 11:47 AM, Bart Otten <bart.otten85 at gmail.com>
> wrote:
> > >> > And is considered the most vulnerable CMS of all times....Only if we
> > >> > render static pages of it's output it's a viable option imho.
> > >> >
> > >> > _______________________________________________
> > >> > kde-www mailing list
> > >> > kde-www at kde.org
> > >> > https://mail.kde.org/mailman/listinfo/kde-www
> > >
> > > _______________________________________________
> > > kde-www mailing list
> > > kde-www at kde.org
> > > https://mail.kde.org/mailman/listinfo/kde-www
> >
> > _______________________________________________
> > kde-www mailing list
> > kde-www at kde.org
> > https://mail.kde.org/mailman/listinfo/kde-www
>
> _______________________________________________
> kde-www mailing list
> kde-www at kde.org
> https://mail.kde.org/mailman/listinfo/kde-www
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-www/attachments/20150717/891c5e1c/attachment.html>