On Fri, Jan 7, 2011 at 7:20 PM, Christoph Noack <christ...@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.sop...@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+h...@libreoffice.org
List archive: http://listarchives.libreoffice.org/www/design/
*** All posts to this list are publicly archived for eternity ***
