Date: prev next · Thread: first prev next last
2022 Archives by date, by thread · List index

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:

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,

[1] [2]



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:

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.