Frameworks mailing list

[Thomas Friedrichsmeier]

Hi,

I don't want to play the blame-game. But I'm really worried about this 
tendency to take essential discussions to side-channels. So I'm sorry to 
continue on one of those another lengthy meta discussions.

On Saturday 19 November 2011, Aaron J. Seigo wrote:
> On Thursday, November 17, 2011 18:17:30 Alexander Neundorf wrote:
> > If the signal to noise ratio here is considered too low, then having the
> > KF5 discussions here
> > * would have increased the signal, and thereby increased the SNR
> 
> this assumes that the tendency to noise on this list would not prevent
> attempts at high-signal communication. which is very probably what would
> have to hapenned.
> 
> the amount of time and energy i've spent on these topics here due to how we
> manage (or rather: do not manage) k-c-d is a good bit of evidence towards
> that.

I think this is based on a fundamental mis-understanding of why some people 
are unhappy about the current situation. The problem isn't people being 
unhappy that work is going on in frameworks. And I very much doubt that "doing 
the work" discussions about development within frameworks are the threads to 
suffer from major interference. The problem is that people can't get the 
features that *they* care about into kdelibs, ATM (and in the worst case, they 
only find out about that after they have invested a considerable amount of 
work, causing additional frustration). Now I really don't want to argue that 
point. I'm entirely convinced that this is a necessary evil. But it's still an 
evil, and it's completely natural that some people will take issue with it.

Add to that: Many contributors outside the inner circle will not find out about 
the effective freeze until they bump into it face first months after the fact. 
From that, it's perfectly clear that the topic will re-emerge time and again.

Well, I can feel the pain that this causes on your side, too. But the point 
is: It's absolutely illusional to think you can avoid those endless threads by 
taking frameworks-discussions elsewhere. On the contrary, this will simply 
increase the chance that it will *seem* to a contributor like you were 
actively keeping them out of the loop, trying to hide essential decision 
processes(*). And so you still get exactly the same discussions, only with a 
tad more accusation and bitterness.

> > * IMO would also have decreased the feeled need for the lengthy
> > discussions taking place now, since people would feel better informed,
> > which would decrease the noise, thereby increasing the SNR
> 
> the lengthy discussions here have had no bearing on anything that's been
> discussed on kde-frameworks-devel. in fact, the topics we've seen here were
> discussed on this very list months ago, making this entire aspect moot.
> 
> people were able to be informed simply by reading k-c-d because that's
> where the discussions were had. in spite of that the "lengthy discussions"
> took place here anyways.

Well, attention is a difficult beast, particularly in a crowd of cats. Evidently 
a good number of people did not catch it, or at least not all of it (such as 
the existance of kde-frameworks-devel). And among those some fairly well-known 
names.

It's naive to assume that keeping the discussion to this list would have 
solved that, completely. But it's quite reasonable to assume that moving the 
discussion elsewhere has contributed towards making the problem worse. Perhaps 
people would not really have been informed too much better, but at least, when 
finding out they have missed something, they would be much more likely to 
recognize that it was _their_ fault not to pay attention, rather than a 
secretive inner circle hiding information from them.

> essentially, we need to insist on a higher quality of discussion on k-c-d.
> that means actively discouraging long meta-discussions and actively
> encouraging productive interactions and contributions. someone needs to be
> able to perform this role consistently, without hesitation and with support
> of those who contribute to the kdelibs code.

I guess you are essentially right about that, except I'd give it a positive 
spin: Decisions need to be documented, clearly.

And I'm not talking about having some sort of near-consensus at the end of a 
lengthy mailing thread. I'm talking about a clear and visible notice of the 
outcome important decisions. Something that a "meta-moderator" (and their 
deputies) would actually be able to point to, without having to do much 
searching, themselves.

Often, summarizing the result of a central discussion in a separate (non-
threaded) post would probably be good enough, an eye-catching subject line 
would help, futher. In the current case, a notice to kde-cvs-announce would 
have been a good idea, too, IMO. I already lamented the lack of a central up-
to-date status information page for kdelibs contributions, a few days ago.

Well, those are wishes. I do realize that getting there means a considerable 
amount of work. But for some points, is it really that much work? Is it so 
much more work compared to bearing the recurring dicussions, and creating a 
new mailinglist (along with moderation, welcome message, individual developers 
subscribing and probably adding filter rules to the mail clients, ...)? And in 
fact, is it really more work than writing / blogging / given talks about it in 
other places, which may or may not be visited by those with an interest in kde 
core development?

Please keep kde-core-devel in the loop.

Regards
Thomas

-----------------

(*) And in fact, from what you have written about the motivation for kde-
frameworks-devel, you *are* trying to keep them out of the loop. Except it may 
not actually be the loop where the strategic decisions are being reached.
-------------- 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: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20111119/8d877b44/attachment.sig>