[kdenlive] Volunteering website help - if needed?

David david at kenpro.com.au
Tue Jan 26 04:55:25 UTC 2016

My $0.02 contribution to the discussion:

Which platform rather depends on intended use. If it's going to be an 
active site with lots of different functions needing multiple permission 
levels and a complex database, then probably better to use Drupal. If 
it's fairly simple with a bunch of documents, then anything will do :)

On 26/01/16 09:36, Jos Poortvliet wrote:
> If you decide to move to WordPress I can help out a bit too, I have 
> plenty experience maintaining ownCloud.org :-)
> replying on phone. blame faulty text completion/correction for any 
> rudeness!
> On Jan 25, 2016 11:02 PM, "farid abdelnour" <snd.noise at gmail.com 
> <mailto:snd.noise at gmail.com>> wrote:
>     hi guys,
>     i am one of the people interested in helping out with the website.
>     i guess the first step would be to choose if we are gonna stick to
>     the current platform (drupal) and update it since there might be
>     some security flaws or switch to a different one (wordpress?). our
>     lead designer here at the studio can take care of all the design
>     of the website and if we choose wordpress i can apply it (i am not
>     familiar with drupal). eventually we will do a research and
>     develop a design best suited for everyone's demands and needs. i
>     did a quick look around at other video, audio and graphics
>     programs to start getting an idea about what is out there:
>     proprietary:
>     http://www.lwks.com/
>     http://www.avid.com/US/products/Media-Composer
>     http://www.sonycreativesoftware.com/vegaspro
>     https://www.apple.com/final-cut-pro/
>     https://www.adobe.com/products/premiere.html
>     free:
>     http://natron.fr/
>     http://ardour.org/
>     https://www.blender.org/
>     https://inkscape.org/en/
>     http://www.gimp.org/
>     parallel to this we can start thinking about writing/organizing
>     the content and structure. (which is the most important thing.)
>     like ttguy said, i agree that content is the most important but it
>     should be well presented to the visitors. we can point to the
>     forum, wiki and bug tracker from the website and users eventually
>     will use the other services if necessary.
>     if you'd like to continue this conversation here it is fine by me,
>     otherwise we can switch to the forum.
>     cheers
>     2016-01-21 19:50 GMT-02:00 Roger Morton <ttguy1 at gmail.com
>     <mailto:ttguy1 at gmail.com>>:
>         I have been involved in doing some maintenance of the content
>         on both
>         the kdenlive.org <http://kdenlive.org> web site and on the
>         userbase.kde wiki.
>         Historically the kdenlive.org <http://kdenlive.org> site was
>         where everything happened. It
>         was the manual, the forum, the place to make anouncements and to
>         advertise how to get Kdenlive.
>         Then for various reasons - as have already been mentioned - we
>         moved a
>         lot of this functionality to kde infra structure and closed the
>         kdenlive.org <http://kdenlive.org> web site to new user
>         registration. Now if we are thinking
>         of putting more content back on the kdenlive.org
>         <http://kdenlive.org> website we need to
>         consider the future maintenance burden.
>         The way to limit  maintenance burden is to have a large number of
>         contributors to the  maintenance task. We can get this on the
>         userbase.kde wiki since new user registrations are open. We
>         can't get
>         this so easily on kdenlive.org <http://kdenlive.org> because
>         new automatic registrations are
>         closed.  We could try opening up kdenlive.org
>         <http://kdenlive.org> again to new user
>         registrations but I have to tell you that last time we had
>         this open
>         we were getting 5 or more fake spammer account registrations
>         per day.
>         I believe that the security on the registrations system had been
>         exploited somehow because I would see authorised users that
>         had never
>         been sent a confirmation email.  This the reason we turned off
>         registration completely. Maybe this exploit has been fixed. I
>         dunno.
>         But this just something to consider in all this.
>         While I agree that the attractiveness of the site is important I
>         believe the accuracy of the content on the site is more important.
>         And I don't think we should duplicate information.
>         We have
>         https://userbase.kde.org/Special:MyLanguage/Kdenlive/Manual/Installation
>         to speak to installation
>         and we have https://userbase.kde.org/Kdenlive/Manual/Tutorials
>         for tutorials
>         So I am thinking more on the lines that Vincent mentioned. The
>         kdenlive.org <http://kdenlive.org> site can have some nice
>         looking promotional material that
>         is fairly generic in nature and not requiring too much
>         maintanance. It
>         should link to the more dynamic information at the
>         userbase.kde manual
>         pages.
>         >(3) Direct the viewer easily to a web page or location where
>         they can get it... or at least show how they can get it.
>         This is of course one of our biggest issues and has been for ages.
>         There is no way to have simple instructions on how to get it
>         because
>         everyone must rely on the package managers of their various linux
>         distros.  But if we had more contributors to the doco then we
>         might
>         have users from all different distros updating the doco to
>         tell people
>         how to install it on their flavor of linux.
>         While we there is a mood about helping out with doco I would
>         make a
>         plea to people to help out on the userbase.kde manual. I did a
>         lot of
>         work on it a few years ago and got it to a point where it was
>         pretty
>         comprehensive. I had pages covering every menu item (not every
>         effect
>         or transition had a page - but a skeleton link to create a
>         page was
>         there).  But now - with the major overall that kdenlive has
>         undergone
>         - it is out of date in many places. So if people have
>         "documentation
>         fever" they could help out on the userbase.org
>         <http://userbase.org> wiki. - register a kde
>         identity account here
>         https://identity.kde.org/?r=registration/index/
>         I summary my plea to people is to not focus too much on the
>         sexiness
>         of the websites but to focus on getting the content right. If
>         you see
>         something wrong just fix it !
>         _______________________________________________
>         kdenlive mailing list
>         kdenlive at kde.org <mailto:kdenlive at kde.org>
>         https://mail.kde.org/mailman/listinfo/kdenlive
>     -- 
>     1111.1010.r.i.1101|n.o.i.s.1110|i.m.1010.g.1110|مقاومة
>     fsf member #5439
>     usuario GNU/Linux #471966
>     |_|0|_|
>     |_|_|0|
>     |0|0|0|
>     <a href="http://www.gunga.com.br">gunga</a>
>     <a href="http://www.tempoecoarte.com.br">tempoecoarte</a>
>     <a href="http://www.atelier-labs.org">atelier-labs</a>
>     <a href="http://www.mocambos.net">rede mocambos</a>
>     _______________________________________________
>     kdenlive mailing list
>     kdenlive at kde.org <mailto:kdenlive at kde.org>
>     https://mail.kde.org/mailman/listinfo/kdenlive
> _______________________________________________
> kdenlive mailing list
> kdenlive at kde.org
> https://mail.kde.org/mailman/listinfo/kdenlive

David McQuire
0418 310312

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20160126/93e315e6/attachment-0001.html>

More information about the kdenlive mailing list