Objective: Postponing Hiring TDF-Developer To 2024 or Later?

[andreasma]

Hi all,

I follow the thread(s) about hiring two in-ho use developers by TDF for
some month yet. I got the impression that there are some TDF members
which might have no real interest in getting this task done. They are
asking only questions and didn't submit any solutions or proposals for
solutions. And once all valuable input from TDF members had been
incorporated in the document the beforehand mentioned members try to
start the whole process with a new proposal.

It seemed there is a approach behind this behavior: postpone the whole
topic as far as possible. And try to frustrate the members who try to
drive this topic forward. And prevent this project in the end or to vary
it that it will not disturb own interests or support them.

In my opinion the whole process and the behavior of beforehand mentioned
members is not in the interest of TDF. If that would be the way how
members will work together during the current board term the future of
TDF will not be bright.

Regards,
Andreas

[michaelweghorn]

Hi Andreas, all,

I follow the thread(s) about hiring two in-ho use developers by TDF for
some month yet. I got the impression that there are some TDF members
which might have no real interest in getting this task done. They are
asking only questions and didn't submit any solutions or proposals for
solutions. And once all valuable input from TDF members had been
incorporated in the document the beforehand mentioned members try to
start the whole process with a new proposal.

It seemed there is a approach behind this behavior: postpone the whole
topic as far as possible. And try to frustrate the members who try to
drive this topic forward.

I agree that it is frustrating to see what is going on and to get the impression that it seems to be impossible to work together on a common proposal.

Obviously, I am not able to judge what each one's motivation is.

However, from following the discussion so far, I don't think it is fair to blame only "one side" for the state of affairs.

While I am generally in favor of Paolo's proposal, I share the impression that various concerns or suggestions have not been dealt with adequately so far.

For example: Michael has asked for an ODF version of the proposal so that he could suggest changes and he pointed out some specific issues he saw in the proposal e.g. in [1].
Unless I'm missing something, he didn't receive any reply to that (at least none on the public mailing list) and at a quick glance, (most of) the mentioned passages are still unchanged in the current version of the proposal.

Obviously, I can't speak for him, but I could at least understand to some extent in case he felt unheard and that doing an own counter-proposal would be the only way of his suggestions not just being ignored completely...

My impression is that there seems to be no clear process of how to work together on a proposal, how to suggest changes,...

Doesn't the BoD have any defined process for doing so?

(If somehow working together on the ODF version or talking to each other in person is no option: From a developer's perspective, having the proposal as plain text in a git repo and then allowing people to suggest changes and the "proposal owner" reviewing those sounds like one way that would allow to keep track of suggestions, but that may not be easily usable for non-developers. Having a plain text version being discussed on the mailing list and the proposal owner answering there and integrating changes into the authoritative version sounds like an alternative that might work instead, while having some more overhead. But there are probably other ways...)

In my opinion the whole process and the behavior of beforehand mentioned
members is not in the interest of TDF. If that would be the way how
members will work together during the current board term the future of
TDF will not be bright.

Again, I wouldn't limit that to the "beforehand mentioned members", but to the (at least perceived) inability to work together constructively when there are different opinions.

Quoting from a previous email of mine in one of the threads [2]:

In my previous email, I wrote: "Assuming members in the involved
LibreOffice/TDF bodies found a way to work together constructively, my current
impression is that this approach could be for the benefit of all."

I admit that this will probably be very hard if members of the involved
LibreOffice/TDF bodies don't find a way to work together constructively, but
rather "fight against each other". But I think that's a problem on a completely
different level, and I don't see how TDF can properly serve it's purpose then
anyway, regardless of the specific question around TDF-internal developers
being discussed here...

Best regards,
Michael

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

[thb]

Hi Andreas, all,

Andreas Mantke wrote:

It seemed there is a approach behind this behavior: postpone the whole
topic as far as possible. And try to frustrate the members who try to
drive this topic forward. And prevent this project in the end or to vary
it that it will not disturb own interests or support them.

I don't think that's a fair conclusion of what's happening.

To me, Michael Weghorn's explanation appears much closer to the
truth. After all, whatever proposal will be there to vote on, needs
the backing of as many board members as possible - it is therefore
very important to work out a consensus.

And I'm sure we can get there, if we all work together.

Cheers,

-- Thorsten

[PaoloVecchi]

Hi all,

Hi Andreas, all,

I follow the thread(s) about hiring two in-ho use developers by TDF for
some month yet. I got the impression that there are some TDF members
which might have no real interest in getting this task done. They are
asking only questions and didn't submit any solutions or proposals for
solutions. And once all valuable input from TDF members had been
incorporated in the document the beforehand mentioned members try to
start the whole process with a new proposal.

It seemed there is a approach behind this behavior: postpone the whole
topic as far as possible. And try to frustrate the members who try to
drive this topic forward.

I agree that it is frustrating to see what is going on and to get the impression that it seems to be impossible to work together on a common proposal.

Obviously, I am not able to judge what each one's motivation is.

However, from following the discussion so far, I don't think it is fair to blame only "one side" for the state of affairs.

While I am generally in favor of Paolo's proposal, I share the impression that various concerns or suggestions have not been dealt with adequately so far.

For example: Michael has asked for an ODF version of the proposal so that he could suggest changes and he pointed out some specific issues he saw in the proposal e.g. in [1].
Unless I'm missing something, he didn't receive any reply to that (at least none on the public mailing list) and at a quick glance, (most of) the mentioned passages are still unchanged in the current version of the proposal.

You are right, I did not provide Michael Meeks an ODF version as I wanted this process to be transparent for all.

I've asked from the beginning for everyone to make their proposals in board-discuss so that everyone would see what changes were being requested.

You may have noticed that there are still calls by some to create a small group within the board to discuss changes behind closed doors. I'm still wondering why as no rationale has been provided on board-discuss or within the board.

Obviously, I can't speak for him, but I could at least understand to some extent in case he felt unheard and that doing an own counter-proposal would be the only way of his suggestions not just being ignored completely...

As you can see if Michael Meeks wants to propose something he can do it even without having an ODF at hand.

Regarding his suggestions he may have not noticed that in page 10 there the proposal has been updated nearly 2 weeks ago:

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

You may also notice that Michael Meeks didn't propose improvements to the current proposal, he is actually proposing get rid of the developers from the proposal.

Someone may wonder why does he needed the ODF of the proposal with a full rationale for it if the aim was to say don't employ developers but just a mentor.

We have already 2 mentors, which are doing an excellent job, but the underlying issues described in the proposal will not be fixed by adding another mentor IMHO.

My impression is that there seems to be no clear process of how to work together on a proposal, how to suggest changes,...

Doesn't the BoD have any defined process for doing so?

There are processes we follow for some areas. Other areas can and should be in the open so that the community can participate and see how the proposals are being influenced.

Some, for odd reasons, seem to be less keen in putting their proposals under the community's scrutiny.

Eg. I've asked the board several times to publish on board-discuss the proposal for a QA Analyst before it got put in the budget so that the community could express its opinion about it.

My requests have always been ignored by the author of the proposal.
He may have missed my emails but I suppose that our chairman, which is also his direct superior at work, could have made him notice that he overlooked some emails from a fellow member of the board.

Also my question on why the job description says that "the most important part" is that the QA Analyst should inform the ESC/BoD about tenders hasn't received any answers from the author.

So it seems like some internal processes relating to providing rationales behind some proposals and full transparency are not really working.

(If somehow working together on the ODF version or talking to each other in person is no option: From a developer's perspective, having the proposal as plain text in a git repo and then allowing people to suggest changes and the "proposal owner" reviewing those sounds like one way that would allow to keep track of suggestions, but that may not be easily usable for non-developers. Having a plain text version being discussed on the mailing list and the proposal owner answering there and integrating changes into the authoritative version sounds like an alternative that might work instead, while having some more overhead. But there are probably other ways...)

As above it seems like some processes are not working as they should and we haven't yet implemented the right tool for this specific job which should give a voice also to non developers.

In my opinion the whole process and the behavior of beforehand mentioned
members is not in the interest of TDF. If that would be the way how
members will work together during the current board term the future of
TDF will not be bright.

Again, I wouldn't limit that to the "beforehand mentioned members", but to the (at least perceived) inability to work together constructively when there are different opinions.

If there are different opinions/interests then, IMHO, the best thing to do is to make them public so that our community can express their own opinions.

Now we can clearly see that a member of our community and representative of a commercial contributor prefers to have mentors instead of developers.

I have the impression that the wider community prefers to have actual developers so, which voice should we follow?

Quoting from a previous email of mine in one of the threads [2]:

In my previous email, I wrote: "Assuming members in the involved
LibreOffice/TDF bodies found a way to work together constructively, my current
impression is that this approach could be for the benefit of all."

I admit that this will probably be very hard if members of the involved
LibreOffice/TDF bodies don't find a way to work together constructively, but
rather "fight against each other". But I think that's a problem on a completely
different level, and I don't see how TDF can properly serve it's purpose then
anyway, regardless of the specific question around TDF-internal developers
being discussed here...

On some topics we work constructively together while in others it looks like some changes are being violently pushed back by some.

The rationale for opposing some changes is generally not expressed in full but, reading a recent comment, some community members seem to be forming a clear opinion about it.

Best regards,
Michael

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

Ciao

Paolo

[thb]

Dear list,

Paolo Vecchi wrote:

He may have missed my emails but I suppose that our chairman, which is also
his direct superior at work, could have made him notice that he overlooked
some emails from a fellow member of the board.

Just to clarify - Gabor does not receive orders or instructions from
me with regard to his role as a deputy director, and is free to decide
on his own, according to his personal views & opinions.

@Paolo: the best way to resolve issues like the one you mentioned, is
to talk to the person(s) involved directly. If you like, we should
always be able to find a few minutes during board calls, to get this
sorted out interactively.

Cheers,

-- Thorsten

[Jeremy_Allison]

Paulo,

As a result of this email I have made a complaint about you violating
the Document Foundation code of conduct.

https://www.documentfoundation.org/foundation/code-of-conduct/#:~:text=Please%20be%20helpful%2C%20considerate%2C%20friendly,exemplary%20behaviour%20by%20all%20participants.

Specifically, "Please be helpful, considerate, friendly and respectful
towards all other participants."

Your emails are full of passive aggressive insinuations about other
Board and Document Foundation members. Examples include:

------------------------------------------------------------------------------------
"Some, for odd reasons, seem to be less keen in putting their proposals
under the community's scrutiny."

"On some topics we work constructively together while in others it looks
like some changes are being violently pushed back by some.

The rationale for opposing some changes is generally not expressed in
full but, reading a recent comment, some community members seem to be
forming a clear opinion about it."
------------------------------------------------------------------------------------

If you have evidence of mal-intent, please present it directly with
the names of the people you are accusing.

I respectfully request you stop behaving in such a way. If you
persist, I will request a sanction on your participation on this list.

A community is defined by what behaviors they allow. I do not accept
your behavior on this list.

Regards,

Jeremy Allison.
Document Foundation Advisory Board member.

[andreasma]

Hi Andreas, all,

I follow the thread(s) about hiring two in-ho use developers by TDF for
some month yet. I got the impression that there are some TDF members
which might have no real interest in getting this task done. They are
asking only questions and didn't submit any solutions or proposals for
solutions. And once all valuable input from TDF members had been
incorporated in the document the beforehand mentioned members try to
start the whole process with a new proposal.

It seemed there is a approach behind this behavior: postpone the whole
topic as far as possible. And try to frustrate the members who try to
drive this topic forward.

I agree that it is frustrating to see what is going on and to get the
impression that it seems to be impossible to work together on a common
proposal.

Obviously, I am not able to judge what each one's motivation is.

However, from following the discussion so far, I don't think it is
fair to blame only "one side" for the state of affairs.

While I am generally in favor of Paolo's proposal, I share the
impression that various concerns or suggestions have not been dealt
with adequately so far.

For example: Michael has asked for an ODF version of the proposal so
that he could suggest changes and he pointed out some specific issues
he saw in the proposal e.g. in [1].
Unless I'm missing something, he didn't receive any reply to that (at
least none on the public mailing list) and at a quick glance, (most
of) the mentioned passages are still unchanged in the current version
of the proposal.

Obviously, I can't speak for him, but I could at least understand to
some extent in case he felt unheard and that doing an own
counter-proposal would be the only way of his suggestions not just
being ignored completely...

I have worked together with a group of people on documents during the
last 1.5 year. The documents were not in an editable (e.g. ODF) format.
But everyone, who want to improve one of the documents, was able to
contribute and improve the documents. The format of a document didn't
hinder anyone to submit a valuable proposal / addition.

I want to add that this group was not made out of developers, but common
office workers.

My impression is that there seems to be no clear process of how to
work together on a proposal, how to suggest changes,...

It seemed to be a new territory to work on a proposal / document in
public on a mailing list.

Doesn't the BoD have any defined process for doing so?

(If somehow working together on the ODF version or talking to each
other in person is no option: From a developer's perspective, having
the proposal as plain text in a git repo and then allowing people to
suggest changes and the "proposal owner" reviewing those sounds like
one way that would allow to keep track of suggestions, but that may
not be easily usable for non-developers. Having a plain text version
being discussed on the mailing list and the proposal owner answering
there and integrating changes into the authoritative version sounds
like an alternative that might work instead, while having some more
overhead. But there are probably other ways...)

If you discuss about addition to the document on the mailing list and
add them to a document in another place, you have a media segregation.
This makes a work on the document not easy and some will loose track and
will quit to contribute further.

And if you'd use git for such a document you will only cover a small
part of the LibreOffice/TDF community. The non-devs will likely not able
to submit their input within a git repo.

Regards,
Andreas

[andreasma]

Hi,

Hi Andreas, all,

Andreas Mantke wrote:

It seemed there is a approach behind this behavior: postpone the whole
topic as far as possible. And try to frustrate the members who try to
drive this topic forward. And prevent this project in the end or to vary
it that it will not disturb own interests or support them.

I don't think that's a fair conclusion of what's happening.

No problem: you could think so. But it looks in my  opinion different if
you are not group insider.

To me, Michael Weghorn's explanation appears much closer to the
truth. After all, whatever proposal will be there to vote on, needs
the backing of as many board members as possible - it is therefore
very important to work out a consensus.

It seemed that there is suddenly a new constrative approach on the
mailing list. Thus the board needs to first clarify, if it really wants
to hire two in-house developers or another developer mentor.

I see no initiative from the leadership of the board to active work on a
consensus about the approach and the document. Maybe there are a lot of
activity behind the scene.

Regards,
Andreas

[webmink]

Thanks for this, Jeremy.

Since this is not the first time this user has behaved in a manner detrimental to the discourse on the list, including displaying the patterns of behaviour you describe towards me as well, I join you in your complaint and ask the Board to intervene.

Cheers

Simon

On Wed, May 25, 2022 at 7:15 PM Jeremy Allison <jra@google.com> wrote:

Paulo,

As a result of this email I have made a complaint about you violating
the Document Foundation code of conduct.

https://www.documentfoundation.org/foundation/code-of-conduct/#:~:text=Please%20be%20helpful%2C%20considerate%2C%20friendly,exemplary%20behaviour%20by%20all%20participants.

Specifically, “Please be helpful, considerate, friendly and respectful
towards all other participants.”

Your emails are full of passive aggressive insinuations about other
Board and Document Foundation members. Examples include:

---

“Some, for odd reasons, seem to be less keen in putting their proposals
under the community’s scrutiny.”

"On some topics we work constructively together while in others it looks
like some changes are being violently pushed back by some.

The rationale for opposing some changes is generally not expressed in
full but, reading a recent comment, some community members seem to be
forming a clear opinion about it."

If you have evidence of mal-intent, please present it directly with
the names of the people you are accusing.

I respectfully request you stop behaving in such a way. If you
persist, I will request a sanction on your participation on this list.

A community is defined by what behaviors they allow. I do not accept
your behavior on this list.

Regards,

Jeremy Allison.
Document Foundation Advisory Board member.

On Wed, May 25, 2022 at 2:54 AM Paolo Vecchi
<paolo.vecchi@documentfoundation.org> wrote:

Hi all,

On 25/05/2022 08:54, Michael Weghorn wrote:

Hi Andreas, all,

On 24/05/2022 23.09, Andreas Mantke wrote:

I follow the thread(s) about hiring two in-ho use developers by TDF for
some month yet. I got the impression that there are some TDF members
which might have no real interest in getting this task done. They are
asking only questions and didn’t submit any solutions or proposals for
solutions. And once all valuable input from TDF members had been
incorporated in the document the beforehand mentioned members try to
start the whole process with a new proposal.

It seemed there is a approach behind this behavior: postpone the whole
topic as far as possible. And try to frustrate the members who try to
drive this topic forward.

I agree that it is frustrating to see what is going on and to get the
impression that it seems to be impossible to work together on a common
proposal.

Obviously, I am not able to judge what each one’s motivation is.

However, from following the discussion so far, I don’t think it is
fair to blame only “one side” for the state of affairs.

While I am generally in favor of Paolo’s proposal, I share the
impression that various concerns or suggestions have not been dealt
with adequately so far.

For example: Michael has asked for an ODF version of the proposal so
that he could suggest changes and he pointed out some specific issues
he saw in the proposal e.g. in [1].
Unless I’m missing something, he didn’t receive any reply to that (at
least none on the public mailing list) and at a quick glance, (most
of) the mentioned passages are still unchanged in the current version
of the proposal.

You are right, I did not provide Michael Meeks an ODF version as I
wanted this process to be transparent for all.

I’ve asked from the beginning for everyone to make their proposals in
board-discuss so that everyone would see what changes were being requested.

You may have noticed that there are still calls by some to create a
small group within the board to discuss changes behind closed doors. I’m
still wondering why as no rationale has been provided on board-discuss
or within the board.

Obviously, I can’t speak for him, but I could at least understand to
some extent in case he felt unheard and that doing an own
counter-proposal would be the only way of his suggestions not just
being ignored completely…

As you can see if Michael Meeks wants to propose something he can do it
even without having an ODF at hand.

Regarding his suggestions he may have not noticed that in page 10 there
the proposal has been updated nearly 2 weeks ago:

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

You may also notice that Michael Meeks didn’t propose improvements to
the current proposal, he is actually proposing get rid of the developers
from the proposal.

Someone may wonder why does he needed the ODF of the proposal with a
full rationale for it if the aim was to say don’t employ developers but
just a mentor.

We have already 2 mentors, which are doing an excellent job, but the
underlying issues described in the proposal will not be fixed by adding
another mentor IMHO.

My impression is that there seems to be no clear process of how to
work together on a proposal, how to suggest changes,…

Doesn’t the BoD have any defined process for doing so?

There are processes we follow for some areas. Other areas can and should
be in the open so that the community can participate and see how the
proposals are being influenced.

Some, for odd reasons, seem to be less keen in putting their proposals
under the community’s scrutiny.

Eg. I’ve asked the board several times to publish on board-discuss the
proposal for a QA Analyst before it got put in the budget so that the
community could express its opinion about it.

My requests have always been ignored by the author of the proposal.
He may have missed my emails but I suppose that our chairman, which is
also his direct superior at work, could have made him notice that he
overlooked some emails from a fellow member of the board.

Also my question on why the job description says that “the most
important part” is that the QA Analyst should inform the ESC/BoD about
tenders hasn’t received any answers from the author.

So it seems like some internal processes relating to providing
rationales behind some proposals and full transparency are not really
working.

(If somehow working together on the ODF version or talking to each
other in person is no option: From a developer’s perspective, having
the proposal as plain text in a git repo and then allowing people to
suggest changes and the “proposal owner” reviewing those sounds like
one way that would allow to keep track of suggestions, but that may
not be easily usable for non-developers. Having a plain text version
being discussed on the mailing list and the proposal owner answering
there and integrating changes into the authoritative version sounds
like an alternative that might work instead, while having some more
overhead. But there are probably other ways…)

As above it seems like some processes are not working as they should and
we haven’t yet implemented the right tool for this specific job which
should give a voice also to non developers.

In my opinion the whole process and the behavior of beforehand mentioned
members is not in the interest of TDF. If that would be the way how
members will work together during the current board term the future of
TDF will not be bright.

Again, I wouldn’t limit that to the “beforehand mentioned members”,
but to the (at least perceived) inability to work together
constructively when there are different opinions.

If there are different opinions/interests then, IMHO, the best thing to
do is to make them public so that our community can express their own
opinions.

Now we can clearly see that a member of our community and representative
of a commercial contributor prefers to have mentors instead of developers.

I have the impression that the wider community prefers to have actual
developers so, which voice should we follow?

Quoting from a previous email of mine in one of the threads [2]:

In my previous email, I wrote: “Assuming members in the involved
LibreOffice/TDF bodies found a way to work together constructively,
my current
impression is that this approach could be for the benefit of all.”

I admit that this will probably be very hard if members of the involved
LibreOffice/TDF bodies don’t find a way to work together
constructively, but
rather “fight against each other”. But I think that’s a problem on a
completely
different level, and I don’t see how TDF can properly serve it’s
purpose then
anyway, regardless of the specific question around TDF-internal
developers
being discussed here…

On some topics we work constructively together while in others it looks
like some changes are being violently pushed back by some.

The rationale for opposing some changes is generally not expressed in
full but, reading a recent comment, some community members seem to be
forming a clear opinion about it.

Best regards,
Michael

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

Ciao

Paolo

–
Paolo Vecchi - Member of the Board of Directors
The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE
Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts
Legal details: https://www.documentfoundation.org/imprint

–
To unsubscribe e-mail to: board-discuss+unsubscribe@documentfoundation.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.documentfoundation.org/www/board-discuss/
Privacy Policy: https://www.documentfoundation.org/privacy

–

[michaelweghorn]

Hi Paolo,

thanks for your reply.

While I am generally in favor of Paolo's proposal, I share the impression that various concerns or suggestions have not been dealt with adequately so far.

For example: Michael has asked for an ODF version of the proposal so that he could suggest changes and he pointed out some specific issues he saw in the proposal e.g. in [1].
Unless I'm missing something, he didn't receive any reply to that (at least none on the public mailing list) and at a quick glance, (most of) the mentioned passages are still unchanged in the current version of the proposal.

You are right, I did not provide Michael Meeks an ODF version as I wanted this process to be transparent for all.

I've asked from the beginning for everyone to make their proposals in board-discuss so that everyone would see what changes were being requested.

[...]
As you can see if Michael Meeks wants to propose something he can do it even without having an ODF at hand.

Regarding his suggestions he may have not noticed that in page 10 there the proposal has been updated nearly 2 weeks ago:

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

Thanks for mentioning this once again, I hadn't read all emails in the threads once again before writing my previous email.

However, as far as I can see, even that version still doesn't address all of the aspects that Michael mentioned in his email [1].

For illustration what I mean, let me give two examples:

1) Even v2 still uses the different formulations throughout the document on how and by whom the developers are managed and tasked, as Michael Meeks pointed out in his email.
While I wouldn't say those are completely contradictory, unifying that across the document seems reasonable to help avoid potential confusion.

2) Michael wrote:

    Other pieces surprise me by still being there eg.

: "Commercial contributors confirm that tenders issued by TDF
: form a negligible part of their income"

which seems to refer to this from his previous email [2]:

"Collabora publishes numbers on this at the conference each year - between 0% and 5% of income depending; but still, 5% is not insignificant."

But still, the sentence is in v2 of the proposal just the same.

That was for illustration; I see no need to discuss these points in detail in this thread here. I think it makes sense to rather base further discussion on the diff between your version 2.0 and Kendy's suggested changes in what he called version 2.1. That "version 2.1" touches the above aspects as well. Whether it does so in the "correct way" is certainly something that is worth discussing if there is disagreement.

My impression is that there seems to be no clear process of how to work together on a proposal, how to suggest changes,...

Doesn't the BoD have any defined process for doing so?

There are processes we follow for some areas. Other areas can and should be in the open so that the community can participate and see how the proposals are being influenced.

My presumably too naive expectation was that there would already be a working process to work together on a proposal within the BoD (how modifications would be suggested and integrated,...), and it might be possible to do similarly in public as well, e.g. by just writing the emails discussing the proposal on the public mailing list (in addition) or sharing a link to an editable document or some tool with more people (maybe with just read permission for non-BoD members).

As above it seems like some processes are not working as they should and we haven't yet implemented the right tool for this specific job which should give a voice also to non developers.

Having a clear process for this that would allow everybody to contribute actually sounds like a huge step forward to me, seeing there was quite some confusion in the current discussion and it seems that there were different expectations even among BoD members on how contribution was supposed to take place. [3]

If there are different opinions/interests then, IMHO, the best thing to do is to make them public so that our community can express their own opinions.

I agree with that, and hopefully discussing the different opinions/proposals now will help everybody understand the underlying reasoning/motivation better.

Now we can clearly see that a member of our community and representative of a commercial contributor prefers to have mentors instead of developers.

I have the impression that the wider community prefers to have actual developers so, which voice should we follow?

As mentioned above, I think it makes sense to continue that discussion in the other thread on Kendy's so-called "merged proposal" (version 2.1).
I'll reply on that thread later.

Best regards,
Michael

[1] https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00357.html
[2] https://www.mail-archive.com/board-discuss@documentfoundation.org/msg05477.html
[3] https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00503.html

[drodriguez]

So, why no one raised their voices when members of the ecosystem gave their opinions in public interviews defaming TDF’s activities, huh?

El 28 de mayo de 2022 12:09:33 p. m. GMT-03:00, Simon Phipps simon@webmink.com escribió:

Thanks for this, Jeremy.

Since this is not the first time this user has behaved in a manner detrimental to the discourse on the list, including displaying the patterns of behaviour you describe towards me as well, I join you in your complaint and ask the Board to intervene.

Cheers

Simon

On Wed, May 25, 2022 at 7:15 PM Jeremy Allison <jra@google.com> wrote:

Paulo,

As a result of this email I have made a complaint about you violating
the Document Foundation code of conduct.

https://www.documentfoundation.org/foundation/code-of-conduct/#:~:text=Please%20be%20helpful%2C%20considerate%2C%20friendly,exemplary%20behaviour%20by%20all%20participants.

Specifically, “Please be helpful, considerate, friendly and respectful
towards all other participants.”

Your emails are full of passive aggressive insinuations about other
Board and Document Foundation members. Examples include:

---

“Some, for odd reasons, seem to be less keen in putting their proposals
under the community’s scrutiny.”

"On some topics we work constructively together while in others it looks
like some changes are being violently pushed back by some.

The rationale for opposing some changes is generally not expressed in
full but, reading a recent comment, some community members seem to be
forming a clear opinion about it."

If you have evidence of mal-intent, please present it directly with
the names of the people you are accusing.

I respectfully request you stop behaving in such a way. If you
persist, I will request a sanction on your participation on this list.

A community is defined by what behaviors they allow. I do not accept
your behavior on this list.

Regards,

Jeremy Allison.
Document Foundation Advisory Board member.

On Wed, May 25, 2022 at 2:54 AM Paolo Vecchi
<paolo.vecchi@documentfoundation.org> wrote:

Hi all,

On 25/05/2022 08:54, Michael Weghorn wrote:

Hi Andreas, all,

On 24/05/2022 23.09, Andreas Mantke wrote:

I follow the thread(s) about hiring two in-ho use developers by TDF for
some month yet. I got the impression that there are some TDF members
which might have no real interest in getting this task done. They are
asking only questions and didn’t submit any solutions or proposals for
solutions. And once all valuable input from TDF members had been
incorporated in the document the beforehand mentioned members try to
start the whole process with a new proposal.

It seemed there is a approach behind this behavior: postpone the whole
topic as far as possible. And try to frustrate the members who try to
drive this topic forward.

I agree that it is frustrating to see what is going on and to get the
impression that it seems to be impossible to work together on a common
proposal.

Obviously, I am not able to judge what each one’s motivation is.

However, from following the discussion so far, I don’t think it is
fair to blame only “one side” for the state of affairs.

While I am generally in favor of Paolo’s proposal, I share the
impression that various concerns or suggestions have not been dealt
with adequately so far.

For example: Michael has asked for an ODF version of the proposal so
that he could suggest changes and he pointed out some specific issues
he saw in the proposal e.g. in [1].
Unless I’m missing something, he didn’t receive any reply to that (at
least none on the public mailing list) and at a quick glance, (most
of) the mentioned passages are still unchanged in the current version
of the proposal.

You are right, I did not provide Michael Meeks an ODF version as I
wanted this process to be transparent for all.

I’ve asked from the beginning for everyone to make their proposals in
board-discuss so that everyone would see what changes were being requested.

You may have noticed that there are still calls by some to create a
small group within the board to discuss changes behind closed doors. I’m
still wondering why as no rationale has been provided on board-discuss
or within the board.

Obviously, I can’t speak for him, but I could at least understand to
some extent in case he felt unheard and that doing an own
counter-proposal would be the only way of his suggestions not just
being ignored completely…

As you can see if Michael Meeks wants to propose something he can do it
even without having an ODF at hand.

Regarding his suggestions he may have not noticed that in page 10 there
the proposal has been updated nearly 2 weeks ago:

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

You may also notice that Michael Meeks didn’t propose improvements to
the current proposal, he is actually proposing get rid of the developers
from the proposal.

Someone may wonder why does he needed the ODF of the proposal with a
full rationale for it if the aim was to say don’t employ developers but
just a mentor.

We have already 2 mentors, which are doing an excellent job, but the
underlying issues described in the proposal will not be fixed by adding
another mentor IMHO.

My impression is that there seems to be no clear process of how to
work together on a proposal, how to suggest changes,…

Doesn’t the BoD have any defined process for doing so?

There are processes we follow for some areas. Other areas can and should
be in the open so that the community can participate and see how the
proposals are being influenced.

Some, for odd reasons, seem to be less keen in putting their proposals
under the community’s scrutiny.

Eg. I’ve asked the board several times to publish on board-discuss the
proposal for a QA Analyst before it got put in the budget so that the
community could express its opinion about it.

My requests have always been ignored by the author of the proposal.
He may have missed my emails but I suppose that our chairman, which is
also his direct superior at work, could have made him notice that he
overlooked some emails from a fellow member of the board.

Also my question on why the job description says that “the most
important part” is that the QA Analyst should inform the ESC/BoD about
tenders hasn’t received any answers from the author.

So it seems like some internal processes relating to providing
rationales behind some proposals and full transparency are not really
working.

(If somehow working together on the ODF version or talking to each
other in person is no option: From a developer’s perspective, having
the proposal as plain text in a git repo and then allowing people to
suggest changes and the “proposal owner” reviewing those sounds like
one way that would allow to keep track of suggestions, but that may
not be easily usable for non-developers. Having a plain text version
being discussed on the mailing list and the proposal owner answering
there and integrating changes into the authoritative version sounds
like an alternative that might work instead, while having some more
overhead. But there are probably other ways…)

As above it seems like some processes are not working as they should and
we haven’t yet implemented the right tool for this specific job which
should give a voice also to non developers.

In my opinion the whole process and the behavior of beforehand mentioned
members is not in the interest of TDF. If that would be the way how
members will work together during the current board term the future of
TDF will not be bright.

Again, I wouldn’t limit that to the “beforehand mentioned members”,
but to the (at least perceived) inability to work together
constructively when there are different opinions.

If there are different opinions/interests then, IMHO, the best thing to
do is to make them public so that our community can express their own
opinions.

Now we can clearly see that a member of our community and representative
of a commercial contributor prefers to have mentors instead of developers.

I have the impression that the wider community prefers to have actual
developers so, which voice should we follow?

Quoting from a previous email of mine in one of the threads [2]:

In my previous email, I wrote: “Assuming members in the involved
LibreOffice/TDF bodies found a way to work together constructively,
my current
impression is that this approach could be for the benefit of all.”

I admit that this will probably be very hard if members of the involved
LibreOffice/TDF bodies don’t find a way to work together
constructively, but
rather “fight against each other”. But I think that’s a problem on a
completely
different level, and I don’t see how TDF can properly serve it’s
purpose then
anyway, regardless of the specific question around TDF-internal
developers
being discussed here…

On some topics we work constructively together while in others it looks
like some changes are being violently pushed back by some.

The rationale for opposing some changes is generally not expressed in
full but, reading a recent comment, some community members seem to be
forming a clear opinion about it.

Best regards,
Michael

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

Ciao

Paolo

–
Paolo Vecchi - Member of the Board of Directors
The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE
Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts
Legal details: https://www.documentfoundation.org/imprint

–
To unsubscribe e-mail to: board-discuss+unsubscribe@documentfoundation.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.documentfoundation.org/www/board-discuss/
Privacy Policy: https://www.documentfoundation.org/privacy

–

[michaelweghorn]

Hi Andreas,

I have worked together with a group of people on documents during the
last 1.5 year. The documents were not in an editable (e.g. ODF) format.
But everyone, who want to improve one of the documents, was able to
contribute and improve the documents. The format of a document didn't
hinder anyone to submit a valuable proposal / addition.

I want to add that this group was not made out of developers, but common
office workers.

Do you think that the workflow used there would be worth sharing in more detail as something that might help in the TDF context as well?

My impression is that there seems to be no clear process of how to
work together on a proposal, how to suggest changes,...

It seemed to be a new territory to work on a proposal / document in
public on a mailing list.

Doesn't the BoD have any defined process for doing so?

(If somehow working together on the ODF version or talking to each
other in person is no option: From a developer's perspective, having
the proposal as plain text in a git repo and then allowing people to
suggest changes and the "proposal owner" reviewing those sounds like
one way that would allow to keep track of suggestions, but that may
not be easily usable for non-developers. Having a plain text version
being discussed on the mailing list and the proposal owner answering
there and integrating changes into the authoritative version sounds
like an alternative that might work instead, while having some more
overhead. But there are probably other ways...)

If you discuss about addition to the document on the mailing list and
add them to a document in another place, you have a media segregation.
This makes a work on the document not easy and some will loose track and
will quit to contribute further.

And if you'd use git for such a document you will only cover a small
part of the LibreOffice/TDF community. The non-devs will likely not able
to submit their input within a git repo.

Very true. I'd be very interested to hear whether/how those problems were avoided when cooperating in the group of people you mentioned above.

Best regards,
Michael

[andreasma]

Hi Michael, all,

Hi Andreas,

I have worked together with a group of people on documents during the
last 1.5 year. The documents were not in an editable (e.g. ODF) format.
But everyone, who want to improve one of the documents, was able to
contribute and improve the documents. The format of a document didn't
hinder anyone to submit a valuable proposal / addition.

I want to add that this group was not made out of developers, but common
office workers.

Do you think that the workflow used there would be worth sharing in
more detail as something that might help in the TDF context as well?

the key were / are not magical tools (we use a messenger and regular
office file formats, e.g. pdf or odf etc.), but the people who drive it
forward. It was important that there are two / three group members which
lead the group and get the workflow running. This are managerial
functions which I expect e.g. from the chairman / -women of a group.

My impression is that there seems to be no clear process of how to
work together on a proposal, how to suggest changes,...

It seemed to be a new territory to work on a proposal / document in
public on a mailing list.

Doesn't the BoD have any defined process for doing so?

(If somehow working together on the ODF version or talking to each
other in person is no option: From a developer's perspective, having
the proposal as plain text in a git repo and then allowing people to
suggest changes and the "proposal owner" reviewing those sounds like
one way that would allow to keep track of suggestions, but that may
not be easily usable for non-developers. Having a plain text version
being discussed on the mailing list and the proposal owner answering
there and integrating changes into the authoritative version sounds
like an alternative that might work instead, while having some more
overhead. But there are probably other ways...)

If you discuss about addition to the document on the mailing list and
add them to a document in another place, you have a media segregation.
This makes a work on the document not easy and some will loose track and
will quit to contribute further.

And shortly after I wrote about this segregation issue it got real in
this context:
https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00558.html

And the discussion / process was back again behind closed doors. Seemed
you could kill transparency with such media segregation too (by accident?).

And if you'd use git for such a document you will only cover a small
part of the LibreOffice/TDF community. The non-devs will likely not able
to submit their input within a git repo.

Very true. I'd be very interested to hear whether/how those problems
were avoided when cooperating in the group of people you mentioned above.

See above. It's important to have one or more leaders in the group who
drive the process and manage the group and their communication.

And I want to add another point: you can not always discuss papers and
justify their text to the point where everyone is happy with it. You
could not postpone decisions. It is better to decide promptly.

Unanimity is not the key in the decision making process!

Regards,
Andreas

[michaelweghorn]

Hi Andreas, all,

Do you think that the workflow used there would be worth sharing in
more detail as something that might help in the TDF context as well?

the key were / are not magical tools (we use a messenger and regular
office file formats, e.g. pdf or odf etc.), but the people who drive it
forward. It was important that there are two / three group members which
lead the group and get the workflow running. This are managerial
functions which I expect e.g. from the chairman / -women of a group.

Thanks for sharing your experiences from another context.

And I want to add another point: you can not always discuss papers and
justify their text to the point where everyone is happy with it. You
could not postpone decisions. It is better to decide promptly.

Unanimity is not the key in the decision making process!

I generally agree, but still think it makes sense to try to find consensus where possible, even if some controversial aspects will remain and not everybody will be happy with every single aspect of the final decision in the end.

Best regards,
Michael