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

List:       kde-devel
Subject:    Re: Thoughts from a former KDE, currently Mozilla developer
From:       Benoit Jacob <jacob.benoit.1 () gmail ! com>
Date:       2010-12-08 14:22:05
Message-ID: AANLkTi=h2PTKo4YTn2z6jEK+rjOToFhr+uPaDmEdf6q8 () mail ! gmail ! com
[Download RAW message or body]

2010/12/7 Aaron J. Seigo <aseigo@kde.org>:
>> *****
>> 2. Can one tell volunteers contributors what they should be working
>> on? (KDE: no, Mozilla: yes)
>
> a nice bit of philosophy. imho:
>
> should we communicate what is needed to be worked on? yes.
> should we make it "cool" to work on what is needed by offering support and
> positive reinforcement? yes.
> should we tollerate those who refuse to do so? yes.
> do we always know what is needed? no.
> can we always know what is needed? no.
>
> several projects within kde do engage in both guidance as well as group agenda
> setting. in that specific way, it's not quite the kde of 5 years ago.
>
> "However, KDE could do more to communicate what actually needs to be done"
>
> do you have some concrete applicable suggestions?

Some ideas.

You could introduce a notion of 'blocking bug' where if such a bug
isn't fixed in time for the release, the buggy feature must be
dropped. This allows to keep the time-based schedule. Example: if a
feature makes an app crash on startup for a significant number of
users, that should block it. If a feature is only half-baked, that
fact is a bug (user disappointment) that should block it.

You could then regularly advertise the remaining list of blocking
bugs, and at some late point in the release process, you could accept
only commits that fix blocking bugs.

>> *****
>> 3. QA, Unit-testing, continuous testing (KDE: very little, Mozilla: a lot)
>>
>> Let's face it, KDE has always been deficient in the QA department. In
>> order to ensure good QA, it needs:
>>  * a lot more unit tests than it currently has
>
> agreed. care to donate some resources? :)

Sorry, I'm too busy to do anything but being a self-appointed advice giver.

> and in some ways, Mozilla has a far, far easier task and so can benefit from
> things that we can probably only dream about. :/

The only thing here (crash reports) that makes Mozilla's task far
easier is that it distributes binaries. If really that's necessary to
get good crash reports on linux, then it should still be possible for
you to get the same by working with distros (they are your provider of
binaries).

>> top-class experience; but I hope very, very much that you keep KHTML
>> around, possibly as an optional non-default-install component. Indeed,
>
> that isn't up to "us", that's up to the KHTML team. they continue to work on
> it, and as long as they do then it will remain around, probably in future as
> an optional component as you described.
>
>> you'll get new people into KDE development, second you might find that
>> in several years KHTML is revived. I estimate that 50 dedicated
>> developers people is the minimum to get a modern web engines going.
>
> you know what they call someone who does the same thing over and over
> expecting the results to be different?

I don't think that's doing the same thing over and over again. KHTML
has been a neglected part of KDE for as long as WebKit started to look
like the obvious choice. I realize that's up to the KHTML developers
but was hoping to reach them too on this list. Guys, even if WebKit
does displace KHTML as KDE's main/default/standard web engine, your
own project remains a huge opportunity for prospective contributors.
So why don't you blog and try to attract new contributors? Why keep
passively waiting as KHTML gets more and more forgotten? Note: maybe I
missed recent developments, I would love to be proven wrong.
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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