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


On Fri, Jan 7, 2011 at 7:20 PM, Christoph Noack <christoph@dogmatux.com>wrote:

Hi all,

I'd like to comment some of the comments here (wow), but first I'd like
to answer Andrew's proposal / question.

Andrew, the current wiki page is already an interim solution until we
have figured out a better way to offer extensions and templates. Our aim
- at the moment - is to finalize our very first release including all
the primary web infrastructure (e.g. website).

That said, we are happy to have the "libreplanet" site offering the
extensions. On the other hand, LibreOffice will already ship some
extension per default - there will be less need for users to deal with
the extension sites (although the user interface gets more cluttered).
In the long run, improving to offer "real" extensions (not shipped) will
require much more than a new website ... we currently fail with the
concept of "download --> file --> manual installation --> delete file".

Feel free to have a look at the development mailing list - there has
been a thread called "Extension manager improvement" starting
2010-12-12.


Well, let's continue with the website stuff ... maybe some of you find
some valuable comments / thoughts, the text is a bit longer :-)


Am Freitag, den 07.01.2011, 15:48 +0930 schrieb Michael Wheatland:
On Fri, Jan 7, 2011 at 2:29 PM, Sophie Gautier <gautier.sophie@gmail.com
wrote:

Hi Michael,
On 06/01/2011 23:14, Michael Wheatland wrote:
[...]

 The idea is to have a suggest an extension, then approval system prior
to
publishing on the extensions directory. The same theory will be used
for a
templates library as they also represent high value 'addons' to out
software.
We have been avoiding a public publishing system like a wiki for
these, as
extensions and templates that we suggest also reflect on the quality
of
our
product.


Can you tell me where does this come from? Where this decision has been
discussed and taken and by whom? The fact that we don't use the OOo
site is
to satisfy a request that has nothing to do with quality.

We are an open source project, why should we prevent somebody to
contribute
for whatever reason? what are the criteria for the quality you're
talking
about, where are they written, who is the person giving the approval?
That
would be funny that people could contribute to OOo but not to LibO...


It is a work in progress. We will be consulting with all of the
stakeholders
once things settle down and LibO3.3 has been released. Rest assured we
will
be able to change things once a community consensus has been reached.

We did not want to move focus away from the important areas of community
development at the moment. Hence the comment previously.

Stay tuned

I am :-) Nevertheless, I'd like to comment here, since I see rather
general differences in the understanding what a community project needs.
(Note: I will not comment on any legal or security issues in this mail.)

Michael, the thoughts you provided seem pretty clear to me - if we would
work on a business website, and our aim is to offer high quality
solutions, then I'll sign the contract immediately. As far as I
understand, the goal is to offer only those extensions/template that
have a sufficient quality, thus, providing real benefit to the user.
Estimating the artefact's quality in advance, requires knowledge and
experience - thus we somehow "pay" experts to evaluate the incoming
material.

To rephrase the original intend: For the user, it is ideal to "just
start working" without hassles - the effort of identifying and
installing of artifacts are minimized. The artifacts itself suit the
initial needs of the users. (Well, could be an introduction for a User
Experience Design guide. *g*)

But applying the concept (without modifications) to a community project,
it won't work ... I think this is what Sophie refers to, and I second
her carefulness.

Why?
     * Artifact Estimation: You need qualified approvers to evaluate
       the artifacts. The outlined procedure requires an approver to be
       "qualified" right from the start ... but within communities like
       ours, people do evolve their competencies over time. In the
       outlined process, I miss a natural "evolution".

     * Estimation Quality: Approvers have to estimate a certain
       artifact quality - but extensions and templates are made for
       special domains (accounting, mechanical design, ...). It is
       impossible for approvers to evaluate the real "benefit" for the
       intended user group. In contrast, the FLOSS community evolved
       due to niche applications ("scratch your own itch"), so a
       template that might look worthless may be very valuable for
       other users.

     * Missing reward: In any case, you need some kind of
       "compensation" for the community ... since we don't pay the
       community, it is mainly based on reward/merit. Using an approval
       system that applies high barriers ends up in frustration, some
       content won't even be added right from the start. People
       perceive it as encouraging to quickly see their results (here:
       published artifact).

       Related: Community evolves over time. People who started to
       answer support requests are now doing QA or localization.
       Non-developers who asked for the quality of mathematical
       functions are now (re)writing Calc code. --> Thus, provide low
       barrier entry points to the community. Then, people get
       interested to contribute and to learn how the community works -
       important for more "critical" contributions like for the product
       itself.

     * Effort: If the approval effort and the required knowledge are
       rather high, the resources are spend less wisely ...


Having that in mind, we might ask how critical templates and extensions
are for the "business success" if some of them are questionable.
Instead, how much can we gain from (limited) involvement of a large
number of people?

This is why (also for other businesses) rating systems evolved over time
- and, there has also been a lot of research. Example: Let the community
rate the entities that are available. Once having a certain amount of
ratings, you end up with:
     * Very good ratings --> Propose these items to new users; Firefox
       even proposes them directly within the software. (!)
     * Moderate ratings --> The authors might be encouraged by comments
       (real users, not moderators) to improve their solution. This
       also reflects the iterative / continuous improvement of FLOSS
       communities.
     * Bad ratings --> Live with them, maybe some of the items are
       really helpful for a fraction of our user base. And these guys
       will also recommend LibO, because they found "their" solution.

Concerning the original intend ("UX handbook"), does this solution
satisfy the user's needs? I'd say yes ... and it also encourages
non-users to join and to participate. Thus, the process and the
underlying technology reflects the needs of the project :-)

Of course, there will be questions like:
     * Items like templates are language and country specific, a rating
       doesn't reflect that? --> Provide categories
     * Will new items be rated, if most people just care about the
       "good ones"? --> Provide a way to identify new items, highlight
       them!
     * How to avoid mis-use of ratings? --> Ask people for sign-in and
       validate their email address.
     * How to avoid stressing people with another log in? --> Provide
       single-sign on for all LibO services
     * How to rate the "rating quality" of users --> Let people rate
       comments/ratings of other people, ...
     * What if people upload critical content? --> Provide a "request
       deletion" for the admins. Avoid uploading templates with macros;
       or provide a setting that adds a user to a "I know what I do"
       group - people who have fun to live in danger ;-)
     * What if people don't find an extension / template they need? -->
       Provide a "Author Wanted" section (maybe combine this with a
       brainstorm site)
     * bla bla bla :-)


Well, you may say - we need moderation nevertheless. And then I'd say,
yes, some communities apply the concept of classical moderation
(evaluation) successfully. On mailing lists (unsubscribed posters), or
within Ubuntu's brianstorm ("Is an idea an idea or a bug report?" -->
avoids noise). It works, it because basically boils down to simple
questions like: "Is this an extension or not?" (Which could, in our
case, be a simple non-human technical check).

Finally, my request to you (Drupal Team) is: Please have a look what a
community needs to help itself. Rather base your initial decisions on
what a large group of people (limited domain knowledge, limited time)
can do within the community, instead of what a small group of people
(experts, full-time) can do for the community. [1]

Sophie, others, any further thoughts?

I'm not aware why things like that are not discussed on the website
mailing list ... it would be much more pleasing to join such discussions
from time to time (the stakeholders you are referring to). At least, it
would be possible to get a rough idea what is going on; especially since
I'm sure that there is great stuff we don't see at the moment :-)

Cheers,
Christoph


Christoph,

Thank you for your considered reply. Very constructive ideas.
To clarify, no system has been designed yet to include traditional
'approve/deny' moderation.
In my experience with communities, crowd sourcing of the
approval/disapproval works.

There are multiple ways to implement this, whether it be 'request removal /
spam' links which require a minimum number of people to flag it prior to
moderation, or a rating system where the lookup function only searches
through the template list, only displaying items with a certain average
rating or higher is possible. Ideally both, which is possible with the
framework we are dealing with.

Adding to this, I don't believe that any item being contributed should
undergo a period of initial crowd review, ie. 'New' section and displayed in
a 'Search all' section if deemed to be of poor quality by the community and
never discarded entirely unless it damages the community in some way.

I will ensure that these ideas are contributed towards the initial design
which will be showcased within the community well prior to launch, so
adjustments can be made through community discussions.

Regarding your comments about the business vs personal use case, I don't
believe that there is any sizable difference in user expectations these
days. As can be seen with the success of the Firefox web browser, ensuring
that relevant, high quality product-plus
(Addons/Themes/Extensions/Templates) items are prioritized is a key aspect
in winning over new users and contributors to a project. As a long term user
of OOo one factor which disappointed me about the experience was a lack of
high quality resources 'at arms reach', I am sure they were there, but I
personally had a hard time finding them. As LibreOffice will be looking at
new infrastructure, I feel we can improve this situation, and possibly
contribute some ideas back to the OOo community as we see the feedback and
results from any changes.

I am very interested to hear other view points on this topic, but fear
disrupting the flow of work at the moment.
Again, we will be reviewing the ideas and implementation at a later date
when time is permitting.

Thanks again for your considered point of view.

Michael Wheatland

-- 
Unsubscribe instructions: E-mail to design+help@libreoffice.org
List archive: http://listarchives.libreoffice.org/www/design/
*** All posts to this list are publicly archived for eternity ***

Context


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.