Re: [libreoffice-design] Extensions List suggestion

classic Classic list List threaded Threaded
7 messages Options
sophi sophi
Reply | Threaded
Open this post in threaded view
|

Re: [libreoffice-design] Extensions List suggestion

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...

Thanks in advance for your answer.
Kind regards
Sophie
--
Founding member of The Document Foundation

--
Unsubscribe instructions: E-mail to [hidden email]
List archive: http://listarchives.libreoffice.org/www/website/
*** All posts to this list are publicly archived for eternity ***
Christoph Noack Christoph Noack
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>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 [hidden email]
List archive: http://listarchives.libreoffice.org/www/website/
*** All posts to this list are publicly archived for eternity ***
Charles-H. Schulz Charles-H. Schulz
Reply | Threaded
Open this post in threaded view
|

Re: [libreoffice-design] Extensions List suggestion

Hello there,

> > >>
> > >
> > > 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 must say that I'm left perplexed by all this. Michael, would you mind
telling us:
- who is "We" as "we did not want to move focus away"
- why this secrecy? Do you remember it's an open source project?
- "we will be consulting with all of the stakeholders... " so let me
  rephrase: you're doing something apparently in secret then will
  battle hard to defend it in front of the community? That's about the
  most unproductive thing I can think of here, and it reminds me of the
  Drupal misunderstanding. Nobody has ever talked about an extension
  store/website, although it's definitely something we need to address.
  But working this way around just does not help.


--
Charles-H. Schulz
Membre du Comité exécutif
The Document Foundation.

--
Unsubscribe instructions: E-mail to [hidden email]
List archive: http://listarchives.libreoffice.org/www/website/
*** All posts to this list are publicly archived for eternity ***

Wheatbix Wheatbix
Reply | Threaded
Open this post in threaded view
|

Re: [libreoffice-design] Extensions List suggestion

On Fri, Jan 7, 2011 at 8:30 PM, Charles-H. Schulz <
[hidden email]> wrote:

> Hello there,
>
> > > >>
> > > >
> > > > 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 must say that I'm left perplexed by all this. Michael, would you mind
> telling us:
> - who is "We" as "we did not want to move focus away"
> - why this secrecy? Do you remember it's an open source project?
> - "we will be consulting with all of the stakeholders... " so let me
>  rephrase: you're doing something apparently in secret then will
>  battle hard to defend it in front of the community? That's about the
>  most unproductive thing I can think of here, and it reminds me of the
>  Drupal misunderstanding. Nobody has ever talked about an extension
>  store/website, although it's definitely something we need to address.
>  But working this way around just does not help.
>
>
I don't want to seem rude, but there seems to be a disproportionate amount
of 'push back' within the website mailing list, while groups and individuals
are working hard to build a better future for our community.
Regardless of the development style, or whether it is received well from the
community during consultation and even if ideas are not implemented, could I
suggest everybody attempts to take an encouraging attitude towards new ideas
and people willing to put hard work in to any idea or project. It is the
responsibility of the people doing the work to consult and present their
idea and development to the community at which point feedback and
(hopefully) constructive criticism will always occur. (This is not a direct
reference to Charles, but a feeling that I have from participating in and
watching the mailing lists).

There is no secrecy involved with this or any other ideas/developments I am
involved in. It was an idea floated inside the website mailing list, wiki
pages and instant chat discussions between the website team (Not IRC
unfortunately).
The idea was roughed out and as we have made clear through the website
mailing list a number of times it is very easy to create a rapid prototype
to 'show' the idea rather than tell it.

A number of people in the website team don't like the mailing list
communication style, so we have been successfully coordinating many tasks
through the wiki using a similar style to the marketing team.
I can point you towards multiple references on the mailing list
conversations discouraging consultation about these 'future projects' at the
moment, so instead of halting progress on the idea a group has been talking
about possibilities and integrating it into a first draft prototype so we
have something to discuss when the time comes rather than starting from
scratch. This is also the route that the Silverstripe site has taken through
the initial development which is due on the 10th January, after which
modifications, alterations or redesigns can occur. This is also the way that
the SC asked for the community bylaws to be developed, which IMHO has worked
quite well.

Let me reiterate that this idea is simply that, and idea, at the moment. A
small amount of work has gone into putting a very rough prototype together,
but as with the 'Drupal idea' no decisions have or will be made without
wider consultation.

If anybody wishes to participate in this very early idea development and
prototyping I am more than happy to include them in any and all
conversations relating to this or any other ideas. All of these ideas as
well as developments and participation is being recorded on the website wiki
pages. So I fully refute any accusations of 'secret development', and I
dislike the insinuations that this makes on me and others working together
for the good of our community.

Michael Wheatland

--
Unsubscribe instructions: E-mail to [hidden email]
List archive: http://listarchives.libreoffice.org/www/website/
*** All posts to this list are publicly archived for eternity ***
bedipp bedipp
Reply | Threaded
Open this post in threaded view
|

Re: Extensions List suggestion

Hi Michael, all,

it seems that we restart discussing our communication style instead of
tasks and topics.

I think there are a few points that could ease all our work - and allow
us to spend our precious time on working instead of discussing problems
we can avoid by the right wording...

Starting to comment all the content of the mails here needs too much
time, so just short:

Michael, you referred to "the website team" when you wrote on the
discuss list:

> The website team is
> already exploring the implementation of an extension framework.
...
> 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.

So this creates the impression that there has been decisions by "the
website team" to work in a specific direction.

As this direction is not the one needed and preferred by people active
in our community - and it has not been presented as idea on the website
mailing list, discussion started about your right to present this idea
as "fact".

You could have avoided this entire discussion, if you wrote already in
the beginning what you posted now:

> Let me reiterate that this idea is simply that, and idea, at the moment. A
> small amount of work has gone into putting a very rough prototype together,
> but as with the 'Drupal idea' no decisions have or will be made without
> wider consultation.

So please try to avoid the impression you would base your postings on a
common interest of the "website team", and most of the discussions will
stay much more constructive.

I'm quite sure that you didn't want to create such an impression on
purpose, but if you're not sure about a common agreement of the website
team on a topic, please re-read your mails concerning this point before
sending them.

Best regards

Bernhard

--
Unsubscribe instructions: E-mail to [hidden email]
List archive: http://listarchives.libreoffice.org/www/website/
*** All posts to this list are publicly archived for eternity ***
Charles-H. Schulz Charles-H. Schulz
Reply | Threaded
Open this post in threaded view
|

Re: [libreoffice-design] Extensions List suggestion

In reply to this post by Wheatbix
Hello Michael,

Le Sat, 8 Jan 2011 00:10:35 +0930,
Michael Wheatland <[hidden email]> a écrit :

> On Fri, Jan 7, 2011 at 8:30 PM, Charles-H. Schulz <
> [hidden email]> wrote:
>
> > Hello there,
> >
> > > > >>
> > > > >
> > > > > 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 must say that I'm left perplexed by all this. Michael, would you
> > mind telling us:
> > - who is "We" as "we did not want to move focus away"
> > - why this secrecy? Do you remember it's an open source project?
> > - "we will be consulting with all of the stakeholders... " so let me
> >  rephrase: you're doing something apparently in secret then will
> >  battle hard to defend it in front of the community? That's about
> > the most unproductive thing I can think of here, and it reminds me
> > of the Drupal misunderstanding. Nobody has ever talked about an
> > extension store/website, although it's definitely something we need
> > to address. But working this way around just does not help.
> >
> >
> I don't want to seem rude, but there seems to be a disproportionate
> amount of 'push back' within the website mailing list, while groups
> and individuals are working hard to build a better future for our
> community. Regardless of the development style, or whether it is
> received well from the community during consultation and even if
> ideas are not implemented, could I suggest everybody attempts to take
> an encouraging attitude towards new ideas and people willing to put
> hard work in to any idea or project. It is the responsibility of the
> people doing the work to consult and present their idea and
> development to the community at which point feedback and (hopefully)
> constructive criticism will always occur. (This is not a direct
> reference to Charles, but a feeling that I have from participating in
> and watching the mailing lists).


Certainly so Michael, what is wanted is a contributions-based culture.
>
> There is no secrecy involved with this or any other
> ideas/developments I am involved in. It was an idea floated inside
> the website mailing list, wiki pages and instant chat discussions
> between the website team (Not IRC unfortunately).
> The idea was roughed out and as we have made clear through the website
> mailing list a number of times it is very easy to create a rapid
> prototype to 'show' the idea rather than tell it.


Okay, so indeed it's not exactly secrecy :-) Would you mind pointing
out some of the wiki pages ?

Best,
Charles.

--
Unsubscribe instructions: E-mail to [hidden email]
List archive: http://listarchives.libreoffice.org/www/website/
*** All posts to this list are publicly archived for eternity ***

Wheatbix Wheatbix
Reply | Threaded
Open this post in threaded view
|

Re: [libreoffice-design] Extensions List suggestion

On Sat, Jan 8, 2011 at 1:25 AM, Charles-H. Schulz
<[hidden email]> wrote:

> Okay, so indeed it's not exactly secrecy :-) Would you mind pointing
> out some of the wiki pages ?

We are coordinating the efforts through well structured wiki pages.
http://wiki.documentfoundation.org/Website
http://wiki.documentfoundation.org/Website/Drupal
http://wiki.documentfoundation.org/Website/Drupal_Strategy
http://wiki.documentfoundation.org/Website/Drupal#Drupal_Website_Project_Progression

Please see specifically the Information Architecture proposal which
was the basis of the prototype developments that have occurred so far:
http://wiki.documentfoundation.org/Website#The_LibreOffice_Drupal_Project

This was presented on the mailing list and discussed at length on both
the mailing list and other communication mediums.
http://nabble.documentfoundation.org/Modified-website-design-proposal-td1820077.html

As an open community we are free to collaborate and communicate on any medium.
Once we have something that is good enough to warrant showcasing for
constructive criticism we will endeavour to capture all of these
communication mediums to ensure the entire community is consulted.

I am happy to say that the group of people working on the concepts,
ideas and prototyping within the Drupal section of the website team
have made a huge effort for transparency.
Please don't make accusations that are untrue.

Thanks,
Michael Wheatland

--
Unsubscribe instructions: E-mail to [hidden email]
List archive: http://listarchives.libreoffice.org/www/website/
*** All posts to this list are publicly archived for eternity ***