Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index

On 09/04/2012 10:48 AM, Marc Paré wrote:
Le 2012-08-30 18:34, Jean Weber a écrit :
On Thu, Aug 30, 2012 at 8:42 PM, Marc Paré<>  wrote:

Unfortunately, we are in great need of community building
strategies, which
is where our success rate is quite slim. We need to work on this and
make it
a concerted effort on all of our lists (global and language lists).

Totally agree. I'm trying to organise my notes and thoughts from CLS
(Community Leadership Summit), which I attended in July. I was mainly
looking for ideas that might work for expanding the Docs team, but
most of what was covered should be relevant to other segments of the
community. My interests, as you all know, are in marketing and user
services, not coding: support, training, user docs, and certification
of people working in those areas. IMO the places where we might find
new community members for those areas are not the same places where we
look for developers. More on that topic later!


I also have some thoughts of community building on the project. Some
of my main thoughts are that the TDF/LibreOffice project has managed
to impress all of the opensource community for its quick rise to
success with its amazing product "LibreOffice". However, and this is
where IMO we are running into problems, the complement of devs and its
rise in numbers has far outstripped the TDF membership number of
contributors. While a strong dev participation is a good measure of an
opensource project's health, the problem facing the TDF is its
web/wiki/documentation/QA/design/marketing infrastructures. In other
words, the community building aspect of the project has definitely not
been one of the TDF's (our) success stories.

I believe the TDF should re-focus some of its energies and strategies
on community building in order to address the need for contributor
help in maintaining the QA and public face of the project. The stress
of contributor is quite apparent in major sections of the project;
help is needed in QA (this should be front and centre for recruitment
of help in QA (localization help as well); website management
(desperately needed at the localized level) as well as the global site
-- important as this is the public face of the project; design;
marketing etc. Simply said the number of contributor help has not kept
pace with the number of dev. contributors. One can easily count the
number of active contributors to realize that there are simply too few
for the amount of needed work and these contributors' activity is
often stretched beyond reasonable limits.

The TDF/LibreOffice project should really be seen as a two-pronged
project: a product developed by devs (along with QA/Design) and a
product marketed and supported (Web/Wiki/Doc/marketing etc) by its
membership. This is where, through community building, TDF would try
address the need for help with the project. At this point, the devs
seem to be "humming" along at a great and cooperative speed; where the
need is really required is in the support-contributor group.

Just my initial thoughts on this for now.



Following up on Marc's comments, how many of our non-dev contributors
are active in multiple areas. It seems like I often see the same people
in many areas.

Jay Lozier

Unsubscribe instructions: E-mail to
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.