Hi, I'll start with the bottom of your mail, and only add some clarifications after that.
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? 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 necessary. 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 announcement. Anyway, that's covered by your summary, already. Regards Thomas
signature.asc
Description: This is a digitally signed message part.
