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