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

List:       koffice-devel
Subject:    Re: Missing ODF features -- bugs or wishes
From:       Thomas Zander <zander () kde ! org>
Date:       2010-03-25 9:48:19
Message-ID: 201003251048.19380.zander () kde ! org
[Download RAW message or body]

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.
Because bugs in bugzilla can only be edited by people that have rights to do 
so.
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.

Think about it; which requests-for-flake-shapes do you leave open and which do 
you close? Would you leave one open that requests integration with a for-pay 
website to browse and download their clipart?
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?

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

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

I am getting curious if the people saying loudly they need these reports under 
their own control have a good reason to share on why to do that.
I've provided several acceptable alternatives which shows I'm willing to 
compromise. But its a bit one way so far, why is that?

-- 
Thomas Zander
_______________________________________________
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]