Port KAnimatedSystemTray into KSystemTray

[Aaron J. Seigo]

On Sunday 14 September 2008, Friedrich W. H. Kossebau wrote:
> Am Sonntag, 14. September 2008, um 04:36 Uhr, schrieb Aaron J. Seigo:
> > On Saturday 13 September 2008, Friedrich W. H. Kossebau wrote:
> > > Please, don't hide the fact that that guide is _not_ an official guide.
> >
> > it's as close as we have for the core kde libraries, though. i don't know
> > why people are so allergic to the idea of consistency
>
> People are rather allergic to all-or-nothing proposals.

even when they don't affect them in any way shape or form? why does nobody 
complain about the kdepim style guide these days, which is rigorously 
enforced? because it doesn't affect us. it only impacts those working on 
kdepim, and they've come to a conclusion for themselves.

this is no different with kdelibs.

> And things that get
> pushed forwards without a real general consens.

of the top 10 contributors by commit count to kdelibs, i know that 7 are very 
much in favour of it. this includes the top few people who are responsible for 
a remarkable % of the work that went into kdelibs in the last two years (the 
top committer has ~3x the number of commits of the #2 person, and the top  3 
combined account for 50% of the combined top 10 commit count; but more on that 
later).  one person in the top 10 has expressed the desire to do some minor 
tweaks to it, though that didn't happen after they aired their proposal. of 
the remaining two people, i don't know what their opinion is off hand. (should 
be easy to find out, of course =)

if we extend that to the top 20, it's pretty much identical, right down to one 
more person wanting some small tweaks.

of the people who objected to the idea of a coding style guide or to the 
current one in substantive ways (so not small issues, but big ones) ~0% of 
them appear in that top 20 (or even futher) committers.

the issue was raised at trysil in person which was attended by those most 
involved with kdelibs at the time; it was raised again a couple times on this 
list.

if that isn't consensus then heaven help us because consensus is 
unnattainable.

> I guess nobody is allergic to consistency in style for a given code block,
> it's just for the kind and scope of the style.

to be frank, what kind of guide is not your concern unless you are a signficant 
contributor to $PROJECT. if you're a casual "patch here and there" person or 
not a contributor to $PROJECT at all, i don't think it's really up to you.

example: i have actually contributed to kdepim in a rather insignificant but 
consistent fashion for probably 5 years (or maybe a bit more than that even). 
i worked on the smtp ioslave, did the fancy headers still used in the reader 
window (which i now think looks very dated; it was cool at the time though ;), 
worked on the visuals in the kontact sidebar, did some work on the little 
calendar widget in korganizer, etc... but let's face it: i'm really not a 
significant contributor to kdepim. =) so i don't feel like i have any say or 
concern in the style guide they use.

they who code decides, and i don't see kdelibs as any different which is why i 
used $PROJECT in the above rather than "kdelibs" directly.

as for the scope, it is quite tightly constrainted to just kdecore, kdeui, 
kio, kdeutils and kfile. other projects may opt to use it if they wish, but 
that is 100% up to each project and there is no expectation of adoption or 
penalty for not doing so.

> > it's
> > not like i go around telling people in kmail (to pick a random example)
> > what style to use or complain about their style.
>
> They might care because they are open to contribute there, have a look at
> some parts, and even have modules in the works which are a candidate for
> inclusion there. :) And so they might care for entry barriers, and this
> includes such representatives nitpicks as where-braces.

a) the effort to ensure consistency such as where braces go are near zero 
compared to actually writing the code in the first place.

b) if you are wanting to contribute to a project, you contribute to it and 
that means cooperating with certain things like licensing or code style or 
portability requirements or ... we have far more onerous issues in kdelibs 
than braces, you know.

c) if coding style is really a barrier to entry, i'd like you to explain the 
constant suppy of patches we get for plasma from new contributors, many of 
whom end up sticking around for more patches, where we're much more strict 
about code style than we are in kdelibs. (plasma is probably "sexier", but 
that's already visible in the involvement difference between plasma and 
kdelibs). we could also look at kdepim which has a strict style guide as well; 
they need more hands, so i don't think a styleguide alone is enough either.

> Also, please for KDE being a community project normalize contribution a
> little by time to spend, not everybody is lucky to earn his money by this
> and can go fulltime.

let's look at the KSystemTrayIcon patch in question. there were several actual 
problems with it. i spent a good amount of time reviewing and providing 
possible solutions to those real problems, and about 10s dealing with style 
issues. the coder probably spent an additional 15s touching up those braces, 
several minutes reworking the actual issues and probably even more time 
waiting for it to compile and link libkdeui.

what this says is that it's not a time issue for the contributor in this case.

moreover, in the several years i did kde development on my own time, i 
provided patches to, e.g., kdepim that does have a strict style guide. i went 
through reworking my patches for style for them. i disliked how hard it was to 
get patches in there some years ago, but that had nothing to do with the style 
issue: it's really easy to get patches into kdepim and the style guide 
remains.

so i know from personal experience that it is not the style guide that matters 
when it comes to getting patches in as a volunteer. it's completely how open, 
responsive and helpful the maintainers are.

we (kdelibs devs) used to be really concerned about the number of people 
working on kdelibs: it was mostly people who had been with the project for 
years with very little "new blood". we talked about possible reasons why 
extensively, and what we might be able to do about it. we didn't have a style 
guide, so that wasn't it ;)

today, in the top 10 commiters for the last ~2 years i see three new-to-libs 
names (even more if we extend to top 20) and those people are not paid to do 
so. there has been more activity and care in kdelibs recently than there was 
through much of kde3. we can do even better yet and get even more people 
contributing and doing great things with kdelibs ... but things are improving 
here, at least according to the numbers i have so far (once Pauls' db is 
available i'll be able to do a lot better reporting in this area) ... 

you have made 9 commits to the kdelibs covered by the style guide in the time 
span covered by my data. 5 to kdecore and 4 to kdeui. 33 others are in the 5-9 
commit range; a total of 156 people are in the <10 commits range. so there are 
significant numbers of occasional commiters: 67.2% of contributors in fact. 
they account for 6.6% of total commits. the top 4.3% (aka "the top 10") 
account for 43.1% of commits. the next 4.3% account for 20.3%, meaning the top 
20 account for 63.3% of commits. it's not unusual for a foss project, though a 
little more top heavy than some.

(i really wish this data had line change data as well; i'm hoping Paul's db 
will)

so when optimizing for involvement, there are a few different aspects to take 
into consideration here:

* those doing the bulk of the work should be allowed to work easily

* new developers should have a low barrier to entry, including:
    * the code should approachable (consistency helps; it's one thing we've 
heard numerous times from would be contributors and was part of the motivation 
for the style guide; clarity and documentation are even more important though)
    * clear direction on how to contribute (the more clearly process is 
defined, the more confident someone can be they are doing the "right thing", 
something that is disproportionately important to most technical people)
    * time to contribute must be kept low (which is a combination of a few 
factors; one of them can be if the process is too complex or strict)

* code should be easy to pass on from generation to generation of developers

it's satisfying to me that we have a way to work that is agreed upon by those 
who do the bulk of the work, that we continue to see large numbers of "casual" 
developers (small numbers of commits over time) and that with a consistent 
style the code is a bit more maintainable and transferable.

so what i'm saying here is that i share your concern for contribution to 
kdelibs. it's a real issue for us and one that some of us, myself included, 
have spent time and energy on.

it matters enough to me that i take time out of my sunday to write this very 
long email =) 

my motivation is that i'd like people to give the kdelibs project the same 
respect and understanding they give any other project in KDE. i think they 
might if we had an actual visible and official maintainer / maintainence team 
for kdelibs, but we don't.

> Understandable motivation?

i understand what you are saying, but respectfully disagree with it. the ideas 
presented are not held up by actual practice and i really find it "not very KDE 
like" to have people who aren't contributing significantly to these libraries 
tell those of us who are how to work. i appreciate feedback in general, but 
this one has been heard many times over now.

kdelibs development is not exactly "vibrant" right now, but it is rather 
better than it was a few years ago imho. those of us working on it care and 
are doing what we can to make it more vibrant.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080914/40221117/attachment.sig>