Frameworks mailing list

[Thomas Zander]

On Sunday 20 November 2011 12.49.46 Thomas Friedrichsmeier wrote:
> > 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.
[]
> > 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. 

We can't avoid  people objecting, and thats perfectly fine as we want the 
feedback from others. Nobody wants to silence al voices.
The line to be drawn is when the "I want my feature in" slipps from a simple 
opinion into a discussion. 

You can't work if every decision is reopened every time someone wants to 
challange it, and our community can't work if a decision is made without any 
means of giving feedback.
There has to be a balance.   The reality is that the amount of voices that can 
doubt a decision is many times greater than the amount that can defend it. So 
the balance has lean more towards those that do the work.

To keep K-C-D productive we should all be able to say that when a discussion 
has been had, has been closed and a decision is made by those that do the work 
it should be made easy to continue on that path and hard to diverge.
And currently k-c-d has the opposite effect, and has had for year.

> 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 agree this is an issue, and its a very real one.  And I agree that we can't 
really expect "the next guy" to take this responsibility.
 
> 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. 

I also agree with Aarons approach,  but I want to dream a bit and in that 
dream go one step further.

What if a group of 10 or 20 people that are on kde-core-devel quite often 
agree on one approach that keeps the balance between decisions made by a core 
and the feedback from the community at large.   With the bias as I wrote 
above.
A specific example I just came up with what we can do is this;
When a thread goes offtopic or a topic is started that essentially challanges a 
decision made in the past one person from that 20 answers with an email like 
this;
   "Dear X, thanks for your email on this topic. Its always good to hear from
   people that are impacted by our decisions.  The issue you have will be
   taken as a valuable measure-point to make sure we keep our past decisions
  actual.    In the mean time we will stay on course.
  Thanks!"

And just as important, the topic should be closed by the simple act of people 
not replying anymore.


Bottom line for me is that we move the responsibility of defending decisions 
and documenting them and gathering them up etc  from the people that made 
those decisions to the community at large.
-- 
Thomas Zander