Frameworks mailing list
thomas.friedrichsmeier at ruhr-uni-bochum.de
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 community.kde.org
> * 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?
> 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
> 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
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...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel