[libreoffice-website] Re: [libreoffice-design] Extensions List suggestion

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

[1] http://www.documentfoundation.org/foundation/


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