Long Term / KDE.org Design Update

[Albert Astals Cid]

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?

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

> 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

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