In-house developers proposal v 2.1

[PaoloVecchi]

Hi all,

after months of silence there is now an additional proposal for developers with focus on mentoring.
Confusingly the additional proposal hasn't been renamed yet but hopefully it will be done soon as it changes quite a lot the purpose of the "developers" and the controlling parties.

After having read the other proposal I have integrated some minor changes into v 2.1 that you can find here:

https://nextcloud.documentfoundation.org/s/sFtCk9wiMWbt2pB

Some of the changes implemented:
- added that TDF has increased its contributions also thanks to improved QA triage, UI and unit tests development
- moved the "app stores management" section under Focus Areas and removed the long rationale behind the proposed focus area as it should be by now clear to all. It might be seen as controversial but it is a natural evolution to have the apps managed directly by TDF
- removed the paragraph stating that tenders are a negligible part of commercial contributors income
- added that in-house developers should participate to events to present their achievements

It is important from my point of view that a strategic proposal of this type does not contain artificial limitations for TDF to express itself fully in achieving its goals set in its statutes. While TDF is committed to working with members of the commercial ecosystem in a mutually beneficial relationship it should be made clear that third parties and suppliers (commercial contributors) should not limit what a charitable organisation can do as that is against our statutes and the principles TDF was created with.

The ESC provides valuable contributions but it is well represented by commercial contributors and other external organisations which should not directly influence TDF's employees. Meetings with the ESC will provide useful exchange of information which will be evaluated by our mentors and our ED to take decisions as described in the proposal.

Ciao

Paolo

[Jan_Holesovsky1]

Hi Paolo,

Paolo Vecchi píše v Po 30. 05. 2022 v 13:44 +0200:

While TDF is committed
to working with members of the commercial ecosystem in a mutually
beneficial relationship it should be made clear that third parties
and
suppliers (commercial contributors) should not limit what a
charitable
organisation can do as that is against our statutes and the
principles
TDF was created with.

Can you please explain what concrete limitations do you mean? I'd be
very pleased to see how the Merged proposal can be improved to address
those.

The ESC provides valuable contributions but it is well represented
by
commercial contributors and other external organisations which
should
not directly influence TDF's employees.

I am a bit confused - are you concerned about the Board the same way?
If it contains commercial contributors the same way as ESC does, should
it not influence TDF staff either?

All the best,
Kendy

[Jan_Holesovsky1]

Hi all,

Paolo Vecchi píše v Po 30. 05. 2022 v 13:44 +0200:

After having read the other proposal I have integrated some minor
changes into v 2.1 that you can find here:

https://nextcloud.documentfoundation.org/s/sFtCk9wiMWbt2pB

Some of the changes implemented:
- added that TDF has increased its contributions also thanks to
improved
QA triage, UI and unit tests development
- moved the "app stores management" section under Focus Areas and
removed the long rationale behind the proposed focus area as it
should
be by now clear to all. It might be seen as controversial but it is
a
natural evolution to have the apps managed directly by TDF
- removed the paragraph stating that tenders are a negligible part
of
commercial contributors income
- added that in-house developers should participate to events to
present
their achievements

For the ease of review, here is the above document in editable form,
with the changes visible as tracked changes:

  https://nextcloud.documentfoundation.org/s/YNZyoL7Q39bMiCD

I've also rebased the Merged proposal on top of this; it is great to
see the amount of differences decreased, please see it here:

  https://nextcloud.documentfoundation.org/s/ggx9zJnN9yZSKc6

In case you want to edit it, you can do so directly in the shared
folder:

  https://nextcloud.documentfoundation.org/f/960049

If you are not a TDF Member, happy to incorporate your changes for you,
please send them as a reply to this ML.

All the best,
Kendy

[PaoloVecchi]

Hi Kendy,

I kindly ask you once more to rename your file and your proposal as it has nothing much to do with mine.

That is not a merged proposal is simply another proposal and what you are doing is only generating confusion.

Thanks

Paolo

[Jan_Holesovsky1]

Hi Paolo,

Paolo Vecchi píše v Út 31. 05. 2022 v 16:30 +0200:

That is not a merged proposal is simply another proposal and what
you
are doing is only generating confusion.

Does that mean that you have no interest in trying to find a middle
ground, and that we should decide for one or the other via a Board
vote?

If that is a misunderstanding, and you are actually interested in
finding a solution that fits all, please point out concrete sentences
in the Merged proposal you have problem with (like Michael W. has
done), I am more than happy to explain, rephrase, or amend.

All the best,
Kendy

[michaelweghorn]

Hi Paolo, Kendy, all,

After having read the other proposal I have integrated some minor changes into v 2.1 that you can find here:

https://nextcloud.documentfoundation.org/s/sFtCk9wiMWbt2pB

Thanks for this, Paolo. Some comments:

Some of the changes implemented:
- added that TDF has increased its contributions also thanks to improved QA triage, UI and unit tests development
- moved the "app stores management" section under Focus Areas and removed the long rationale behind the proposed focus area as it should be by now clear to all. It might be seen as controversial but it is a natural evolution to have the apps managed directly by TDF

As written in my reply to Kendy [1] already: With the fact that the BoD has already decided that TDF will publish apps in the app store by itself, it seems to be less controversial to me to have that in the proposal as a potential target area/task for an internal developer.

It is important from my point of view that a strategic proposal of this type does not contain artificial limitations for TDF to express itself fully in achieving its goals set in its statutes. While TDF is committed to working with members of the commercial ecosystem in a mutually beneficial relationship it should be made clear that third parties and suppliers (commercial contributors) should not limit what a charitable organisation can do as that is against our statutes and the principles TDF was created with.

The ESC provides valuable contributions but it is well represented by commercial contributors and other external organisations which should not directly influence TDF's employees. Meetings with the ESC will provide useful exchange of information which will be evaluated by our mentors and our ED to take decisions as described in the proposal.

Is that directed at Kendy's proposal?
I either don't fully understand or don't share your concern that ESC would have too much influence there, since the "Selecting Target Areas" section in there says that each TDF member can suggest target areas. The ESC ranks those, but it's ultimately the BoD that decides. Given the BoD ultimately decides on the target areas, it's unclear to me how ESC would directly influence TDF's employees.

Can you possibly explain that in a bit more detail?

Looking at the diff between the 2 proposals: While there seem to be different approaches in some bigger questions (like management, tasks of developers), some seem to be more of a cosmetic nature.
Without knowing how the process works exactly:
While I don't really expect that there will be a consensus in all aspects, I'm wondering whether trying to minimize the diff between the proposals before doing a vote would be reasonable, so there's consensus in as many aspects as possible.

Best regards,
Michael

[1] https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00617.html

[webmink]

Hi!

Thanks for your calm reflections, Michael.

On Tue, Jun 7, 2022 at 3:30 PM Michael Weghorn <m.weghorn@posteo.de> wrote:

Looking at the diff between the 2 proposals: While there seem to be
different approaches in some bigger questions (like management, tasks of
developers), some seem to be more of a cosmetic nature.
Without knowing how the process works exactly:
While I don’t really expect that there will be a consensus in all
aspects, I’m wondering whether trying to minimize the diff between the
proposals before doing a vote would be reasonable, so there’s consensus
in as many aspects as possible.

Just to amplify this, I have been trying to contribute to this activity but having two (complicated) documents makes it hard to make contributions. Kendy made a merged version and shared it with us all and it would be really good if contributors could stick with improving that one and getting it to a state where there’s maximum consensus between the directors (and hopefully the rest of us who are contributing but obviously Board agreement needs to be the priority. It’s really a waste of time to cherry-pick and update a legacy document instead of the one multiple people have been working on.

Cheers

Simon

–

[PaoloVecchi]

Hi Simon,

Kendy made a merged version and shared it with us all...

No, once again he took my document and copy/pasted bits of Michael Meeks proposal on it to completely change the logic of the proposal.

That proposal doesn't really fit with the budget planned, senior developers mostly focused on mentoring are very difficult to find and very expensive, and anyone with basic HR skills would never let employees be managed by a committee in which third party companies have can have so much influence as seen in recent minutes.

It's really a waste of time to cherry-pick and update a legacy document instead of the one multiple people have been working on.

The "legacy document" has actual contributions from many people of the community and TDf's team, the document on which Kendy pasted some text has only contributions from Michael Meeks and you (BTW please remove your only contribution as it names a potential supplier).

Ciao

Paolo

[cornouws]

Hi Paolo,

Kendy made a merged version and shared it with us all...

No, once again he took my document and copy/pasted bits of Michael Meeks proposal on it to completely change the logic of the proposal.

I assume if the 'logic changed', that is to reflect contributions in the discussion that were not added in your file.

That proposal doesn't really fit with the budget planned, senior

I think there is room to look to the budget for next year again, if needed.

developers mostly focused on mentoring are very difficult to find and very expensive, and anyone with basic HR skills would never let employees be managed by a committee in which third party companies have can have so much influence as seen in recent minutes.

This is unhelpful framing. Influence is (apart from statutory limitations to participation from entities) from participating, which is done in the best traditions of open source development, which in the case of LibreOffice is broadened deliberately - I was at the discussion - to more than 'just' coding.

The "legacy document" has actual contributions from many people of the community and TDf's team, the document on which Kendy pasted some text has only contributions from Michael Meeks and you

Kendy made efforts to include comments and ideas from all sides. Very useful to come to a proposal with the broadest possible support respecting as much ideas as possible.

greetings,
Cor

[PaoloVecchi]

Hi all,

Hi Paolo,

Kendy made a merged version and shared it with us all...

No, once again he took my document and copy/pasted bits of Michael Meeks proposal on it to completely change the logic of the proposal.

I assume if the 'logic changed', that is to reflect contributions in the discussion that were not added in your file.

That is a copy/paste from a text the general manager of a commercial contributor sent the 23/05, his employee and member of the board copied the 25/06 on a document he called a merge and the same general manager practically imposed to the ESC part of his project.

The way the proposal wants to manage "suggestions" for tendering, the focus on mentoring and control of TDF's employee have been already described as very bad ideas.

That proposal doesn't really fit with the budget planned, senior

I think there is room to look to the budget for next year again, if needed.

As this is, as agreed, a strategic project that has been taken out of the budget planning that we have done not long ago then we are still on time to review this budget.

developers mostly focused on mentoring are very difficult to find and very expensive, and anyone with basic HR skills would never let employees be managed by a committee in which third party companies have can have so much influence as seen in recent minutes.

This is unhelpful framing. Influence is (apart from statutory limitations to participation from entities) from participating, which is done in the best traditions of open source development, which in the case of LibreOffice is broadened deliberately - I was at the discussion - to more than 'just' coding.

We should check with an employment laws expert if they consider if "unhelpful framing".

The "legacy document" has actual contributions from many people of the community and TDf's team, the document on which Kendy pasted some text has only contributions from Michael Meeks and you

Kendy made efforts to include comments and ideas from all sides. Very useful to come to a proposal with the broadest possible support respecting as much ideas as possible.

Kendy replaced text to reflect the ideas of a commercial contributor not to include comments.

greetings,
Cor

Ciao

Paolo

[mmeeks]

Hi Paolo,

That is a copy/paste from a text the general manager of a commercial contributor sent the 23/05

  It is not the greatest vote of confidence in your position that you critique the source of a counter-proposal rather than the proposal itself: please play the ball not the man.

  You then go on to (again) mis-characterize Kendy's merged proposal, something you've repeatedly done and been corrected on:

developers mostly focused on mentoring are very difficult to find and very expensive, and anyone with basic HR skills would never let employees be managed by a committee in which third party companies have can have so much influence as seen in recent minutes.

  The proposal contains this:

  "The Executive Director shall direct day to day management for
   the Targeted Developers to ensure they effectively focus on the
   Target Areas."

  Line management is up to the ED - that is explicit. I suspect that they will not direct management by a committee - but it's up to them =)

  Attempting to exclude targetted developers from attending the ESC call and reporting on what they're up to - as they become respected peers alongside others working on the code seems extraordinary.

  Again your understanding of how LibreOffice development and the ESC works seems weak as I've outlined before[1].

  Regards,

    Michael.

[1] - https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00557.html

[PaoloVecchi]

Hi Michael,

I prefer to avoid going into details as people should draw their conclusions by looking at timing and people involved by looking at the ESC meeting minutes and your proposal.

Hi Paolo,

That is a copy/paste from a text the general manager of a commercial contributor sent the 23/05

It is not the greatest vote of confidence in your position that you critique the source of a counter-proposal rather than the proposal itself: please play the ball not the man.

Actions have been performed by people, in this case you and Kendy.

As I've been told off for stating facts and not naming people so I guess I have to make it clear who did what and when.

A sequence of events/coincidences show that some proposals are more equal than others and clear objections that make your proposal more complicated, expensive and much less effective have not been addressed at all.

You then go on to (again) mis-characterize Kendy's merged proposal, something you've repeatedly done and been corrected on:

developers mostly focused on mentoring are very difficult to find and very expensive, and anyone with basic HR skills would never let employees be managed by a committee in which third party companies have can have so much influence as seen in recent minutes.

The proposal contains this:

"The Executive Director shall direct day to day management for
     the Targeted Developers to ensure they effectively focus on the
     Target Areas."

Line management is up to the ED - that is explicit. I suspect that they will not direct management by a committee - but it's up to them =)

Our ED has already plenty of things to do and micromanaging in-house developers should not be part of his job.

Please re-read the rest of my proposal as it states how things should be run to avoid overwhelming our ED. Our ED will evaluate things only if there are issues between the team and the ESC.

Attempting to exclude targetted developers from attending the ESC call and reporting on what they're up to - as they become respected peers alongside others working on the code seems extraordinary.

Nowhere in my proposal is being said that the ESC will be excluded.

Please re-read my proposal.

Again your understanding of how LibreOffice development and the ESC works seems weak as I've outlined before[1].

I'm slowly learning about it thanks to the good comments from Adreas that pushed me to look into it even if development is not my main focus and it is only one of the various areas LibreOffice is made of.

I've seen a very nice way to cooperate between developers in a way that seems to take in consideration the best way to deal with code and find good solutions to issues

Your intervention in the ESC meeting the 26/05/2022 and the 02/06/2022 had absolutely nothing to do with code and a lot to do with politics and undue influence in a committee that now cannot be seen as a neutral ground.

Regards,

Michael.

Ciao

Paolo