Plasma Team Communication & Development Practices [MUST READ]

[Martin Flöser]

Am 2017-10-08 11:38, schrieb Ben Cooksley:
> On Sun, Oct 8, 2017 at 10:02 PM, Martin Flöser <mgraesslin at kde.org> 
> wrote:
>> Am 2017-10-08 10:22, schrieb Ben Cooksley:
>>> 
>>> On Sun, Oct 8, 2017 at 9:00 PM, Martin Flöser <mgraesslin at kde.org> 
>>> wrote:
>>>> 
>>>> Am 2017-10-07 22:00, schrieb Ben Cooksley:
>>>>> 
>>>>> 
>>>>> On Sat, Oct 7, 2017 at 11:57 PM, Martin Flöser <mgraesslin at kde.org>
>>>>> wrote:
>>>>>> 
>>>>>> 
>>>>>> Am 2017-10-07 11:22, schrieb Ben Cooksley:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> *Pulls up a chair*
>>>>>>> 
>>>>>>> We need to have a talk. The way things are proceeding currently 
>>>>>>> in
>>>>>>> regards to how you (the Plasma folks) work with the rest of us is
>>>>>>> severely and fundamentally broken. Which means we need to fix it.
>>>>>>> 
>>>>>>> Lets start with development practices. Over the past few weeks, 
>>>>>>> there
>>>>>>> have been at least two instances where things have been 
>>>>>>> unbuildable,
>>>>>>> for several days, and have only been fixed after i've essentially
>>>>>>> hunted down the responsible developers. One instance is currently
>>>>>>> outstanding.
>>>>>>> 
>>>>>>> In one case code was introduced which depended on a new version 
>>>>>>> than
>>>>>>> was allowed. The other case was a failure to update the 
>>>>>>> dependency
>>>>>>> metadata.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Having had to do it a few times, I do not think there is currently 
>>>>>> a
>>>>>> workflow in place where one can follow it. It's not documented and 
>>>>>> if
>>>>>> one
>>>>>> actively asks for "what's on the CI system" one gets a reply like 
>>>>>> "it
>>>>>> depends" up to "look through the jobs". Having done this a few 
>>>>>> times I
>>>>>> don't
>>>>>> think you can expect developers to get this right.
>>>>> 
>>>>> 
>>>>> 
>>>>> In this case I was commenting on a straight up Qt issue - where 
>>>>> code
>>>>> was added which used features that weren't available in Qt 5.7 (the
>>>>> current target for Frameworks)
>>>>> 
>>>>>> 
>>>>>> If I would have to do it right now, I would not:
>>>>>>  * know where to find the documentation
>>>>>>  * know where to check which dependencies are available
>>>>>> 
>>>>>> So let's try to google: "kde developer update dependency", hmm 
>>>>>> nothing
>>>>>> on
>>>>>> first side, sorry.
>>>>>> 
>>>>>> And I'm probably the one developer being most aware of it due to 
>>>>>> the
>>>>>> mess
>>>>>> with xkbcommon.
>>>>>> 
>>>>>>> 
>>>>>>> Some might say these issues are minor. Apart from the fact 
>>>>>>> they're in
>>>>>>> Frameworks which means they have repercussions on everyone else 
>>>>>>> who
>>>>>>> develops software using KDE Technology. The fact they've also 
>>>>>>> been
>>>>>>> ignored for *days* is also not great either.
>>>>>>> 
>>>>>>> Now on to communication. As above I mentioned developers were
>>>>>>> ignoring, or otherwise failing to take action on, notices that 
>>>>>>> these
>>>>>>> breakages were present in the above. Not cool!!
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> I hear of these issue for the first time. So where were the alarm 
>>>>>> clock
>>>>>> raised?
>>>>> 
>>>>> 
>>>>> 
>>>>> The people in question were poked on IRC.
>>>> 
>>>> 
>>>> 
>>>> There are two things which surprise me now:
>>>> 1.) Why are you addressing the Plasma team, while it was a 
>>>> Frameworks
>>>> issue?
>>>> Shouldn't you raise this to the Frameworks team?
>>>> 2.) Why are you addressing the whole team, while the issue was not 
>>>> known
>>>> to
>>>> all members due to the communication only happen on IRC?
>>>> 
>>>> It looks to me like a failure of individual people and not of the 
>>>> team.
>>> 
>>> 
>>> I've addressed the Plasma team because the problem only occurs in
>>> Frameworks whose development is principally driven by Plasma
>>> requirements. The changes in question were all made by Plasma team
>>> members.
>>> 
>>> The whole team is being addressed because i've had to chase down
>>> enough people (all in the Plasma team) that it's reasonable enough to
>>> assume the problem is team wide and as such should be addressed at
>>> that level.
>> 
>> 
>> This is totally uncool. That is Sippenhaft! The Plasma team is not as 
>> a
>> whole responsible for what people do! Especially not when they are 
>> part of
>> the frameworks team! Please address the frameworks team if there is a
>> problem in frameworks. Just because people have different roles 
>> doesn't mean
>> you can just blame the one team! This is absolutely uncool.
> 
> I have no idea what 'Sippenhaft' is.

https://en.wikipedia.org/wiki/Sippenhaft - apparently there is no 
translation for that word.

> 
> From my perspective you are all collectively responsible for the
> Product you release and reminding each other of appropriate
> development practices. This includes things like when freeze dates
> are, what version of Qt to depend on, and making sure the dependency
> metadata is kept up to date.

No the Plasma team is *NOT* responsible for this as a whole for two 
reasons:
* the report was only done on IRC
* it's frameworks not Plasma

I would not have a problem with what you write, if the communication 
would have gone through a mailing list. What I take offense at is that I 
as a team member should be responsible for not reacting to an IRC 
communication when I was not in the channel. That is absolutely not 
acceptable.

> 
> As I mentioned previously, these changes were all introduced by Plasma
> developers, for the benefit of Plasma. All the other Frameworks don't
> have any issues. I haven't assigned blame to the wrong team.

Sorry, but that's just not the case. If I work on frameworks I have a 
frameworks hat on. If I work on Plasma I have a Plasma hat on. We have 
multiple roles and this was frameworks, so address frameworks and not 
Plasma.

We as a community should allow mixing of the groups. What you do here is 
the exact opposite. A Plasma dev is a Plasma dev is a Plasma dev. No we 
are not!

Cheers
Martin