2010/12/7 Aaron J. Seigo <ase...@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 <<
