Frameworks mailing list

[Aaron J. Seigo]

On Saturday, November 19, 2011 21:03:50 Thomas Friedrichsmeier wrote:
> 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

it worries me, too. we need to realize that it was our behaviour here on k-c-d 
for the last several years (and i mean _several_) that have led to this 
situation. that is the real issue, not that there are some discussions 
currently being held elsewhere. that's just a symptom.

> continue on one of those another lengthy meta discussions.

so let's make it into a discussion with value. let's identify real issues, 
derive real solutions we can possibly try out by implementing, and then do so. 
:)
 
> 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

i understand this 100% clearly and completely with no ambiguity.

people who are expressing discontent are indeed doing so because they want 
their features into a kdelibs release (not just in kdelibs itself) ASAFP 
despite there being a feature freeze. this goes against the very concept of 
freezes as part of our development cycles. it just so happens that kdelibs is 
currently in a non-six-month cycle to get some very important work done, and 
that is causing some people to chafe about it.

keep in mind: these features are welcome in kdelibs right now! they need to go 
into the frameworks branch, or if they are a new module (like ksecretservice 
or kactivities) into their own git repo. 

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.

as for the "doing the work" discussions being deferred, it doesn't matter if 
that's true or not. what matters is that people had that impression, and THAT 
is the issue we need to grapple with here.

> (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.

there are two sides of this. 

first: we have freezes all the time in kdelibs. twice a year, at a minimum, to 
be exact. this isn't radically new behaviour. some people are behaving like it 
is. ;)

second: it was announced and made very clear in a number of places what was 
happening. however, follow-up documentation was not handled as properly as it 
should have been, and that is something i will be helping to fix with others 
who are involved at the irc meeting which appears to be taking place on 
December 4th. 

i do not, however, enjoy how the goalposts get conveniently moved when people 
do discover that it was indeed announced and discussed. those who missed that 
ought to take personal responsibility for that miss and adapt to what they now 
know. 

i am taking personal responsibility for the lack of documentation since then, 
and that's, imho, the kind of positive productive behaviour we need to see 
more often: don't wiggle when you get caught out, just fix it.

> 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

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 didn't solve the root issue, however, which we need to deal with.

> > 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.

agreed.

> 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).

indeed ... 

> And among those some fairly well-known names.

yes, i agree that there is a difficulty in communicating here. perhaps in part 
because of the noise? probably in large part ...

> 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.

it's certainly being used an excuse by some, no doubt about that.

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

> 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.

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. yes, as 
normal humans with lots of distractions in life, we miss things sometimes. 
people can own up to it instead of complaining that their expectations no 
longer line up.
 
> > 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.

that's only part of it. bikeshedding needs to be nipped in the bud; non-
productive discussions need to have a request to take them elsewhere made; 
non-mailing-list meetings need to be set up when necessary. it's not just 
documenting decisions, it's creating an environment within which decisions can 
be made in the first place.

> 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

agreed ...

> Often, summarizing the result of a central discussion in a separate (non-

all good ideas that can be good parts of the solution ...

> 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

for individual points? no, it isn't that much work. imgine picking the one 
exception we make and then having to tell all the rest that the exception was 
an exception and they don't get their feature merged. it's not fair, it's 
unecessary and it doesn't work in the big picture.

i don't know how many times i need to repeat that. reality is not about to 
change just because someone asks it for the 10th time.

> much more work compared to bearing the recurring dicussions, 

let me blunt: the recurring discussions are a complete and utter pain in my 
ass. however, i do think that perhaps we can use this as an opportunity to 
understand what is not working well on k-c-d and find the will and means to 
improve things here.

i also will not be moved into making a bad decision for others just because 
people keep bringing up the topic. this is the "who scream loudest and longest 
gets their way" method that is not a sign of a mature community nor is it 
productive.

so i engage because i see the potential for a "greater good" result and 
because i really don't think we need more caving-in-to-the-loudest.

> and creating a
> new mailinglist (along with moderation, welcome message, individual
> developers subscribing and probably adding filter rules to the mail
> clients, ...)?

the mailing list is very, very low effort. less time than this one email i'm 
writing right now.

> 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?

ime: yes.

> (*) 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

not in the least. if that were the intention, it would never have been 
announced and kde-frameworks-devel would be a private list. no one is keeping 
anyone out of any loop. there is a difference between wanting a place where 
there isn't unreasonably high levels of noise and keeping people out of the 
loop. please let's not start confusing those two goals, otherwise we will 
never find a way to tame k-c-d because any time we attempt to do so we'll just 
get told by someone that we're "keeping people out of the loop" or "stopping 
valuable discussion", both of which are rubbish.

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?

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20111119/1ddd9199/attachment.htm>
-------------- 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/1ddd9199/attachment.sig>