Long Term / KDE.org Design Update

[Ken Vermette]

On Tue, Jul 21, 2015 at 5:59 AM, Ben Cooksley <bcooksley at kde.org> wrote:

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

Thank you Ben. You have now earned the status of "Kenterpreter". :P

But yes, what he says is spot on; you have to have some specific technical
chops to contribute translations. There's probably a lot of people very
fluent in their languages out there unable to contribute due to not knowing
subversion; it's an incredibly specific subset of skills we're currently
demanding.


> >> 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
> translators,
> > 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.
>

Opening the site for non-technical translators doesn't mean we open the
site to a free-for-all; but it does mean we may be able to scale things a
bit better. Any CMS worth considering will enable permission mechanisms.
For example, on release announcements we could limit translations to
trusted individuals - but for more expansive documentation and sections we
can open things up a bit more.

Also (again this could be incorrect since I don't know how the system
handles PO files) this could potentially lead to more consistent
translations. Instead of a translation being tied to a specific page,
translations may be tied to lumps of information; as that information will
be used across multiple pages, it means the same translations will be
consistently applied throughout the system.


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

Ben again nails it; it's not so much about how you interact with it, as
much as it is about how the data gets stored in the end. Files are just
inflexible compared to formal databases.

On diffing, some CMSs actually do have decent diff operations built-in, but
probably not as you envision. I know Wordpress has it, and Drupal *might*
have it; any CMS which seriously tracks versions will have it. The main
thing you should expect would be different workflows; in a CMS the
submitter never sees or works with diffs, but the administrator can view a
diff before accepting changes. CMSs with diffing will also keep a modest
history so changes can be undone as well.


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

I've developed some very dynamic websites but I also haven't administrated
any particularly large websites; I don't want to set out to prove you
wrong, because it seems like we have different kinds of experience and
discounting your knowledge would be moronic. KDE.org is massive. Also, if I
make stupid decisions without being called out, I'm not going to be the one
holding the bag. Even if I hate every second of it I'd rather you call out
every decision I propose.

Thank you;
 - Ken


>
> >>
> >> 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
> _______________________________________________
> 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/20150727/7e6110c5/attachment-0001.html>