Extensions List suggestion

classic Classic list List threaded Threaded
11 messages Options
AndrewT AndrewT
Reply | Threaded
Open this post in threaded view
|

Extensions List suggestion

Currently the "get more extensions online..." link (accessed from Tools -> Extension Manager) takes users to this page: http://libreplanet.org/wiki/Group:OpenOfficeExtensions/List. There are a few disadvantages to that list, namely:

1. It takes users to the main OO.org plugins site anyway, which suggests proprietary extensions
2. There is no easy link to download the source code
3. A list of all the free software extensions for LibreOffice could be completed more quickly and with less effort if it were user-editable

I suggest a new page be made on the LibreOffice website that addresses these concerns. It should be something similar to the list Trisquel project has made for free software only Firefox add-ons, preferably in editable wiki format. See: http://trisquel.info/en/browser
Wheatbix Wheatbix
Reply | Threaded
Open this post in threaded view
|

Re: Extensions List suggestion

On Thu, Jan 6, 2011 at 3:39 PM, AndrewT <[hidden email]> wrote:

>
> Currently the "get more extensions online..." link (accessed from Tools ->
> Extension Manager) takes users to this page:
> http://libreplanet.org/wiki/Group:OpenOfficeExtensions/List. There are a
> few
> disadvantages to that list, namely:
>
> 1. It takes users to the main OO.org plugins site anyway, which suggests
> proprietary extensions
> 2. There is no easy link to download the source code
> 3. A list of all the free software extensions for LibreOffice could be
> completed more quickly and with less effort if it were user-editable
>
> I suggest a new page be made on the LibreOffice website that addresses
> these
> concerns. It should be something similar to the list Trisquel project has
> made for free software only Firefox add-ons, preferably in editable wiki
> format. See: http://trisquel.info/en/browser


At the risk of starting another heated discussion. The website team is
already exploring the implementation of an extension framework.
I suggest you jump over on the website mailing list to find out more.

Sorry to be cryptic about it, but we have seen heated discussions about the
implementation method in different mailing lists rather than on the website
mailing list where the discussion about infrastructure should be occurring.

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.

Thanks for the suggestion.
Michael Wheatland

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

Re: 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/design/
*** All posts to this list are publicly archived for eternity ***
Wheatbix Wheatbix
Reply | Threaded
Open this post in threaded view
|

Re: Extensions List suggestion

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

Thanks,
Michael Wheatland

>

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

Re: 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/design/
*** All posts to this list are publicly archived for eternity ***
Wheatbix Wheatbix
Reply | Threaded
Open this post in threaded view
|

Re: Extensions List suggestion

On Fri, Jan 7, 2011 at 7:20 PM, Christoph Noack <[hidden email]>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 <[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
>

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

Drupal related discussions (was and is: Re: [libreoffice-design] Extensions List suggestion)

Hi Michael, all!

I cannot resist :-) I'd like to add some more thoughts, because I think
it will be helpful for other topics as well ...

Am Freitag, den 07.01.2011, 19:50 +0930 schrieb Michael Wheatland:
> On Fri, Jan 7, 2011 at 7:20 PM, Christoph Noack <[hidden email]>wrote:
[...]
> > > >  The idea is to have a suggest an extension, then approval system prior
> > to
> > > >> publishing on the extensions directory.

[... explanation and discussion ...]

> > > Stay tuned

[... my talkative bla bla ...]

> > 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?
[...]

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

True, although we do have some variance with regard to our user base -
or let's say, we do not only sell the product, but also the idea of
freedom / open-source. Users get the whole "package" - the majority aims
for the "ready to go" solution, but there will be users that accept a
less than ideal solution (Is this "me" talking here? *g*), and there
will be users we want to turn into contributors.

So in our case, it is more challenging (but a great challenge) to suit
all those needs at the same time :-)

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

Especially with regard to the extensions and the templates, the website
infrastructure is just a tiny part of the solution. We (LibO/OOo) fall
short with regard to how templates and extensions are offered. If there
is a superior solution, then the we need developer (API) support ... but
this is another topic.

> 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 for considering the "flow" :-)

On the other hand, I perceive it much more disruptive if it is silent
for quite a while and - suddenly - a statement like "the idea is to have
a suggest an extension, then approval system prior to publishing on the
extensions directory" pops up. Then, time is spend in clarifying the
issue ... I'd rather like to invest this in advance.

Otherwise, it will happen quite frequently that certain topics
(important to some people) will be addressed without considering
available knowledge / experience.

The extension / template is stuff like that ... for example, we
discussed some parts during our "User Experience Done Live 2009"
session. And, of course, continued to do so in the evening and later in
Hamburg. If you look for "extensions" on the OOo ux-discuss mailing
list, there will be plenty of results.

To get an idea:
http://wiki.services.openoffice.org/wiki/User_Experience/Events/User_Experience_Done_Live_2009#Workshop_Experience_and_Result


Finally, I would strongly suggest to move all discussions related to
Drupal to the website mailing list. That makes it far easier to follow.
And if people require to focus on different work topics, they (like me
*g*) will omit the messages - so it would be great if we could agree on
a tag like [Drupal] for the subject.

Would that be okay?

Cheers,
Christoph


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

Re: Drupal related discussions (was and is: Re: [libreoffice-design] Extensions List suggestion)

On Fri, Jan 7, 2011 at 9:31 PM, Christoph Noack <[hidden email]>wrote:

> Hi Michael, all!
>
> I cannot resist :-) I'd like to add some more thoughts, because I think
> it will be helpful for other topics as well ...
>
> Am Freitag, den 07.01.2011, 19:50 +0930 schrieb Michael Wheatland:
> > On Fri, Jan 7, 2011 at 7:20 PM, Christoph Noack <[hidden email]
> >wrote:
> [...]
> > > > >  The idea is to have a suggest an extension, then approval system
> prior
> > > to
> > > > >> publishing on the extensions directory.
>
> [... explanation and discussion ...]
>
> > > > Stay tuned
>
> [... my talkative bla bla ...]
>
> > > 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?
> [...]
>
> > 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. [...]
>
> True, although we do have some variance with regard to our user base -
> or let's say, we do not only sell the product, but also the idea of
> freedom / open-source. Users get the whole "package" - the majority aims
> for the "ready to go" solution, but there will be users that accept a
> less than ideal solution (Is this "me" talking here? *g*), and there
> will be users we want to turn into contributors.
>
> So in our case, it is more challenging (but a great challenge) to suit
> all those needs at the same time :-)
>
> > 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.
>
> Especially with regard to the extensions and the templates, the website
> infrastructure is just a tiny part of the solution. We (LibO/OOo) fall
> short with regard to how templates and extensions are offered. If there
> is a superior solution, then the we need developer (API) support ... but
> this is another topic.
>
> > 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 for considering the "flow" :-)
>
> On the other hand, I perceive it much more disruptive if it is silent
> for quite a while and - suddenly - a statement like "the idea is to have
> a suggest an extension, then approval system prior to publishing on the
> extensions directory" pops up. Then, time is spend in clarifying the
> issue ... I'd rather like to invest this in advance.
>
> Otherwise, it will happen quite frequently that certain topics
> (important to some people) will be addressed without considering
> available knowledge / experience.
>
> The extension / template is stuff like that ... for example, we
> discussed some parts during our "User Experience Done Live 2009"
> session. And, of course, continued to do so in the evening and later in
> Hamburg. If you look for "extensions" on the OOo ux-discuss mailing
> list, there will be plenty of results.
>
> To get an idea:
>
> http://wiki.services.openoffice.org/wiki/User_Experience/Events/User_Experience_Done_Live_2009#Workshop_Experience_and_Result
>
>
> Finally, I would strongly suggest to move all discussions related to
> Drupal to the website mailing list. That makes it far easier to follow.
> And if people require to focus on different work topics, they (like me
> *g*) will omit the messages - so it would be great if we could agree on
> a tag like [Drupal] for the subject.
>
> Would that be okay?
>
> Cheers,
> Christoph


Thanks for you great suggestions Christoph,
As you can see, I am not shy in mailing lists, however there are quite a
number of others who prefer to communicate through skype, XMPP or forums
(anything except mailing lists essentially).
I am more than happy to adopt a [Drupal] tag for these discussions and also
contribute back any discussions to the mailing list that is had on 'private
media' with the permission of the team members.

Having not been a part of the OOo community I will go and look through the
discussions, although trawling through mailing lists I find very difficult.
Personally I would love it if people could simply contribute constructive
ideas while referencing past discussions, successes and mistakes. This would
also give context to other new members who join the discussion. I realise
that this will seem repetitive for some exOOo people, but as a
distinct community I believe it is important to revisit ambitious ideas
which may have been considered unachieveable in the past.

As for the Drupal ideas, at the moment we are documenting and managing ideas
and tasks on the website wiki, however I will endeavour to get the info onto
the mailing list in the future.

Thanks,
Mike

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

Re: Extensions List suggestion

This post has NOT been accepted by the mailing list yet.
In reply to this post by AndrewT
I hope nobody is missing the point of my original post. My main concern is that LibreOffice be an exemplary piece of free (as in freedom) software. Whatever consensus is reached by the LibO community about the details of the eventual implementation of an extensions framework, I believe it needs to fulfill a few basic criteria:

1. Only free software extensions should be promoted. That also implies not linking to the main OO.org website.
2. Source code for each extension should be easily available for download.
3. The process of submission should be open and responsive to the needs of the community. Perhaps a wiki is best for that end, or perhaps not.

The current placeholder fails on all three counts, so I hope the successor will not.
AndrewT AndrewT
Reply | Threaded
Open this post in threaded view
|

Re: Extensions List suggestion

In reply to this post by AndrewT
I hope nobody is missing the point of my original post. My main concern here is that LibreOffice exemplifies free (as in freedom) software. Whatever consensus is reached by the LibO community about the details of a future extensions implementation, it should fulfill a few basic criteria:

1. Only free software extensions should be promoted. That also implies not linking to the main OO.org website.
2. Source code for each extension should be easily available for download.
3. The process of submission should be open and responsive to the needs of the community. Perhaps a wiki is best for that end, or perhaps not.
bedipp bedipp
Reply | Threaded
Open this post in threaded view
|

Re: Extensions List suggestion

Hi Andrew, all,

AndrewT schrieb:

>
> I hope nobody is missing the point of my original post. My main concern here
> is that LibreOffice exemplifies free (as in freedom) software. Whatever
> consensus is reached by the LibO community about the details of a future
> extensions implementation, it should fulfill a few basic criteria:
>
> 1. Only free software extensions should be promoted. That also implies not
> linking to the main OO.org website.
> 2. Source code for each extension should be easily available for download.
> 3. The process of submission should be open and responsive to the needs of
> the community. Perhaps a wiki is best for that end, or perhaps not.

I did understand your point, but I think such a decision is not only
related to design (whether it would be user experience design or visual
design).

So please post your mail to the general discuss list
[hidden email] to get a broader reaction by the
LibreOffice community.

I don't think that this is a topic to be discussed by the Steering
Committee at this point, but the right place for such a request would be
the mailing list [hidden email].

I don't state my personal opinion here, because this would lead to
discussions in this small group, while they should lead to decisions in
the general community.

Best regards

Bernhard

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