Long Term / KDE.org Design Update

[Ben Cooksley]

On Tue, Jul 28, 2015 at 8:54 AM, Ken Vermette <vermette at gmail.com> wrote:
>
>
> 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.

In terms of needing to know Subversion - translators don't really,
they communicate through a translation team lead who handles all that
I believe, so that won't be a problem.
I was more aiming at the provision of initial content needing
knowledge of Subversion - which means a KDE Developer account also,
and is hence a hurdle people need to get over.

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

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