Frameworks mailing list

Thomas Friedrichsmeier thomas.friedrichsmeier at
Sun Nov 20 11:49:46 GMT 2011


I'll start with the bottom of your mail, and only add some clarifications after 

On Saturday 19 November 2011, Aaron J. Seigo wrote:
> so .. to summarize:
> * k-c-d needs more active guidance, and that guidance needs the support of
> core members of the community
> * decisions need to be documented in a timely manner in a place people know
> where they can check; probably both in a summary posting to the list and in
> cases of bigger results on
> * we need to encourage and protect positive discussion here on k-c-d so
> that discussion that is currently being taken elsewhere will return
> sound ok?

yes, absolutely.

> so, if we're very honest with the situation, what some people are actually
> asking for is their feature to be released sooner, freeze and devel plans
> non- withstanding. well, yes, we'd all like to see our work released
> sooner rather than later. and that's what i'm trying to help ballance
> here: everyone's features and everyone's needs in a reasonable time frame.
> that means compromise sometimes and a push towards a consensus position
> that is then respected because that is _how we work_. we already have a
> consensus position, we already have defined our compromise points ... we
> need to work on the respect.

True. I wasn't trying to _justify_ that sort of discussion. But the point is: 
Transitions like this *are* painful, and some people *are* going to yell about 
it. That's just a fact of life. It can be mitigated to some degree, but in 
general, whatever you do, you will not be able to silence this sort of 
fruitless discussion, entirely. And in particular, "running away from the 
problem" (to a different mailing list) does not help with this at all.

And to point out one more problem of working in a crowd: Those discussions 
tend to pop up in a thread that starts with a suggestion of some feature, then 
turn into a debate of why that feature can't be released in a kdelibs 4.8, 
then into a flame war of how this is all completely intolerable. You can't 
blame contributors who are only lightly involved, and who are not directly 
interested in the initial topic, for skipping such threads right at the start. 
In thus, other words: If you've knocked sense into one person, it doesn't mean 
you've educated all others at the same time. And so the next guy will not be 
much more to blame for bringing up the same old topic again.

I think your conclusions, above, are a good approach at mitigating this. But 
again: It is important to understand that the problem *will* remain to some 
degree. It's the very nature of a transition like this. And it's not a 
terribly good excuse for neglecting k-c-d.
> but it hass absolutely worked for kde-frameworks-devel. all the "endless
> threads" are here, not there. so just how illusional was it, when it
> achieved precisely what it set out to? (namely, high signal.)

It may have helped "marking" the signal. But, as long as you are subscribed to 
both lists, it has not helped the SNR at all. Also, for those who are 
subscribed to k-c-d, only, it has decreased the SNR. For those who simply want 
to find out about the most important status information and goals for kdelibs 
at some point of time, it is another increase of the search space, and that 
translates into a worsened SNR, too.

As Alexander has pointed out, the effect of "marking the signal" could have 
been achieved with a subject-prefix "KF5", too. (My point isn't to blame 
anybody, here, but to highlight this suggestion as an idea for similar cases 
in the future).

> also note that this is not the only instance of discussion moved elsewhere
> due to k-c-d's increasing noise level.

I know. I wouldn't have put as much energy into this, if I perceived this as a 
one-time issue.
> i have previously listed all the places this was announced well in advance.
> multiple, well-known, well-read places. due to the spread of the
> information and how it was repeated, this is simply not a valid reason to
> offer.

As to the validity of this excuse: You have a point, but it's not a black-or-
white issue. Information can be present, but still much harder to find than 

You see, it's particularly this point which bugs me: Extensive information 
exists, but it is spread over half a dozen+ places. You can't expect casual 
contributors to follow (or to search through) all those well-known, well-read 
places, or in fact to follow more than just the bare minimum. I believe, that 
bare minimum, at this moment, for a kdelibs contributor, is most likely k-c-d. 
And I do think, right here, on k-c-d, it sorely lacked a reasonably visible 

Anyway, that's covered by your summary, already.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the kde-core-devel mailing list