[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Missing ODF features -- bugs or wishes
From:       Cyrille Berger <cberger () cberger ! net>
Date:       2010-03-25 10:26:37
Message-ID: 201003251126.37358.cberger () cberger ! net
[Download RAW message or body]

On Thursday 25 March 2010, Thomas Zander wrote:
> On Thursday 25. March 2010 10.25.56 Cyrille Berger wrote:
> > On Thursday 25 March 2010, Thomas Zander wrote:
> > > On Thursday 25. March 2010 09.22.38 Inge Wallin wrote:
> > > > > to get that 3rd party development going we can't mix ideas that can
> > > > > only be done by us with ideas that can be done by everyone.
> > > > 
> > > > This is where we disagree. I do think we can.  But we can certainly
> > > > make it  clear by e.g. comments in the bug that we think that
> > > > something is possible to build externally.
> > > 
> > > Then the question becomes why do you value having control over these
> > > wishes so much?
> > 
> > Why do you think we control them ? It is more about having a central
> > place where you can find everything.
> 
> Because bugs in bugzilla are owned by the people they are assigned to,
> thats control.
This is why I suggested a separate product, using the koffice-bugs-null 
assignement indicating that the bugs are not owned by anyone.

> Because bugs in bugzilla can only be edited by people that have rights to
> do so.
I think it is a minor issue, rights can be given, and anyone can comment.

> Because having external feature requests mixed with internal feature
> requests (ones that need access to the koffice sourcecode) means its the
> same thing to any external person.
> Because we are talking right now about me having the ability to close
> wishlists that should be managed not by me or Inge, but by a community at
> large. Thats koffice having control we should not have.
Assign it to koffice-bug-null and to the koffice-extensions product, it is even 
better workflow, since users would come to bugs.kde.org to make request, then 
if you think it is not a feature you want to implement yourself or see shipped 
with koffice, with an external website, you have to manually copy all 
information to the website, with using a different product, all you have to do 
is change the product to koffice-extensions, and reset the assignement.

> Think about it; which requests-for-flake-shapes do you leave open and which
> do you close?
none. (well except request for a close source plugin)

> Would you leave one open that requests integration with a
> for-pay website to browse and download their clipart?
yes.

> Would you close a feature request for an mp3-plugin if it was created and
> shipped by the Fraunhofer as closed source and with build in royalty
> payments?
yes, and I don't want a link from koffice.org to a website that would encourage 
development of closed source feature.

> > > Letting it flourish outside of the main project is certainly much
> > > healthier.
> > > 
> > > Its a proven method, why change that?
> > 
> > I do not think that scattering information is a proven method,
> 
> Limiting a projects goals and scope is. This gives a clear delimiter to
> what we intend to do inside of KOffice and thus gives a clear signal to
> contributors what they can do without us shipping our own version in the
> next release. Think about it, would you write your own blur filter for
> Krita if you see its already on the wishlist for Kritas core developers?

This is why I suggest a separate product.

> > furthermore,
> > it seems KDE has been doing the opposite and is working on centralizing
> > information on a few website.
> 
> Thats a good point, actually. The information you refer to is centralized
> on a limited set of sites which all are read/write by everyone. The
> 'writable by everyone' here is really important since that means there is
> no clear owner. Which is exactly the point I've been making here.
> 
> As I've been living through the whole thing of making Qt more accessible
> and hackable by outsiders I've talked to a lot of people and heard reports
> from even more people. Their common and repeated comment is that its all
> about (perceived) control.
> 
> Having those feature requests on out bugzilla with our ability to close
> them is repeating the mistakes that Qt made in the past.
There is a difference between having control and using it. Many police officer 
have the power to shoot you, do you feel threaten by them ? No, because you 
know they won't use that power. In other word, as long as you have a power and 
use it reasonably (aka to kill spam), people won't care whether you have a 
control or not. Similary, we have application maintainer, they have the power 
to reject a feature, therefor they have control over what goes in and what 
does not, in many application where the maintainer shows a reasonable use of 
his control, the contributions are flourishing, showing that someone having the 
control does not matter as much as someone making good use of that control.

-- 
Cyrille Berger
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]