Long Term / KDE.org Design Update

[Ben Cooksley]

On Sat, Jul 18, 2015 at 5:59 AM, Albert Astals Cid <aacid at kde.org> wrote:
> El Divendres, 17 de juliol de 2015, a les 13:34:39, Ken Vermette va escriure:
>> 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.
>
> Automation is nice, but luckily you can't automate writing text neither
> translating, once that happens Skynet will kill us all :D
>
>> 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.
>
> Why does it kill community participation? Also we can't really give edit
> access to the CMS to everyone, so how would it increase participation if you
> still have a reduced set of people that can actually use the CMS?

To re-word what Ken was trying to say: those who are interested in
providing changes to the text are probably the same which would be
scared off by PHP code, or who have problems dealing with
Subversion/Git.

>
>> 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.
>
> I don't want random translators translating the same word in a different way
> for each announcement (which would happen if you let random passer by
> translate), that just lowers quality. What we need is commited transltators,
> and we have them and they do a good job, and there are great apps that help
> them do the job in a consistent way. Those apps work over .po files and if we
> want them to keep doing the good job they do that's what we should aim for.
>
>> 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.
>
> It is not log into a CMS that's the problem, it's that it doesn't seem to add
> any value, just seems to get in the way.
>
>> 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.
>
> They are scripted to some degree, yes.
>
>> 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.
>
> Someone still needs to write that nice html/js/css that is going to get
> beatiful results, right? How is having a CMS going to help here?
>
>> 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,
>
> What's the benefit above interacting with a form over interacting with the
> .json in svn? Also the same problem above with edit access to the CMS seems to
> apply. With svn they can at least send a diff, how does the CMS cope with
> that?

The existing apps/ json format files are extremely limited - something
more capable is probably needed in reality. A CMS would not provide
any capability to send diffs other than a manually constructed one...

>
>> 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?
>
> I still don't see what we need the CMS for, sorry.
>
> But then:
>  a) I'm not a web expert, so whatever i think has not much value
>  b) I'm and old fart, sometimes I don't like change that much
>  c) The state of www contributors can't be much worse, so it's probably worth
> trying :)
>
> Please go and prove me wrong :)
>
> Cheers,
>   Albert

Regards,
Ben

>
>>
>> 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
>
> _______________________________________________
> kde-www mailing list
> kde-www at kde.org
> https://mail.kde.org/mailman/listinfo/kde-www