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.
signature.asc
Description: This is a digitally signed message part.
