[VOTE] Approve procurement policy and development agreement, revoke previous technical budgeting procedure

Hi Florian, hi all,

-1

I suggest to fix the most unacceptable mistakes, i.e. if

1.4 “Developer shall compensate FhG for all damages that result directly or indirectly from the termination of the agreement”

FhG means Fraunhofer-Gesellschaft, this version is not better, than the previous one.

Thanks for your review!

Best regards,
László

Ah - so this is meant to be TDF ? Reading again it seems the intention is to demand to compensate consequential (indirect) damages that’s a huge ask - many insurers explicitly exclude consequential damages from their cover.

Which make me look at clause 12 Insurance - also unacceptable; the requirement for Policies to name TDF are incredibly burdensome in administrative time, and this is normally struck from an agreement.

Almost all agreements we sign hard limit liability at the value paid in the agreement in question; that’s a normal part of such things.

There is/was some hope that the referred to but not presented / templated:

shall maintain insurance coverage throughout the entire term of the Agreement as described in the attached Exhibit B with insurance companies acceptable to The Document Foundation. The limits set forth in Exhibit B are …

might limit liabilities - but apparently the text says the opposite - and of course Exhibit B is not present in the document.

Punch line - this looks like a pre-negotiation template contract - which is fine; ask for the sky. It doesn’t look like something that can be agreed to by a responsible person - at least not without some huge risk premium which is not in TDF’s interest.

If TDF wants people to contract for it - it should set out to treat them fairly; a take-it-or-leave-it approach is possible I guess - but not with this extreme position - lets hope it gets fixed.

P.S. The list of mistakes discovered by the public review which seems to be unacceptable also for the initial version, but they seem easy to fix:

– Missing deadline for the next version (2025-12-31?);

– Missing deadline for publishing the details of Ranking by the Community evaluation, which not covered by the previous deadline (“Details for this ranking will be published in a separate procedure or a next update of this Technical Budgeting Procedure.”);

– Bad or non-explained terms or actors: “compensate FhG for all damages” without definition of “FhG”;

– Missing parts: “attached Exhibit B” is not attached;

– Redefinition of “affiliate” with a different meaning in the same policy;

Fixing these e.g. next week, I can support the initial version to test the viability of the improved policy as soon as possible.

Otherwise I strongly agree with the other opinions: it’s worth to spend a few weeks to consider and avoid the risk that a development agreement imposing unachievable requirements on small and individual developers, or every previous successful bidder, will deprive the ESC, our oldest and most professional body to help to remove the biggest barriers to future development, also it will deprive our whole community to achieve anything by the upcoming Ranking by the Community process. (By the way, I’ve checked Linux version of WPS Office a few weeks ago, and yes, it has got a wonderful SmartArt replacement, WPSArt – otherwise it’s not a real competitor of LibreOffice yet, because of lack of language support – Hunspell is used only for en_US and en_CH spell checking, there is no hyphenation [like in Google Docs and online version of Office 365] etc.)

Best regards,
László

The Board of Directors at the time of voting consists of 7 seat holders (not including deputies). In order to be quorate, the vote needs to have 1/2 or more of the Board of Directors members, which gives 4.

A total of 6 Board of Directors members have participated in the vote.

The vote is quorate.

A quorum could be reached with a simple majority of 4 votes.

Result of vote:
6 approvals: Paolo, Italo, Eliane, Osvaldo, Sophie, Simon; deputy Mike supports the motion as well
0 abstain
0 disapprovals (Laszlo’s disapproval was sent shortly after the voting period ended.)

Decision: The proposal has been accepted.

Should there be some minor glitches in the document, I am sure the board will address them in an updated version soon.

I think it’s important to have the principles on the policy agreed and shared in public. A previous board voted for tenders worth a huge amount of money at a pace that we would have had one tender approximately every one and a half weeks. This is not a rate that TDF can sensibly handle, especially in light of the discussions during the hiring of inhouse developers and areas they should keep out of.

The ESC budgeting process failed for various reasons last year. Therefore it’s important to have proper processes and roles in place ahead of the budget to not repeat these mistakes. TDF must be in a position to verify deliverables on all it tenders, and people in the various roles must be prepared.

I second Italo’s thoughts. There is a reason why we need a sound and solid procurement policy in place, and it obviously lies in what happened during past board terms.

The discussion around the word “affiliate” is quite interesting - if the changes are rather trivial, why insist so much on having them?

Hi Florian,

Can you check that you sent a mail on 2024-11-11 15:38, containing “The vote runs 72h from now.”, please? This was the only notification about the vote, what I noticed, and I had no reason to doubt that the voting started earlier than the e-mail claimed, and then I voted within 72 hours.

Thanks,
László

Hi Laszlo,

I checked the facts within mails from the board-discuss list/forum. The mail from Florian got the time stamp Nov., 11, 15.38. Your vote mail got the time stamp Nov., 14, 15.47.

i’m not a mathematician by education but from my job-related knowledge it is obvious that the deadline ended on Nov., 14 at 15.38.
Thus your vote didn’t meet the deadline.

Regards,
Andreas

Although Laszlo email was late, it contains a few remarks which are worth considering. The same applies to other messages in the thread. Apart from the “affiliate” definition, which I do not think could be changed without incurring in legal issues, there are indeed some glitches in the text that should be corrected as soon as possible with a version 1.1.

Hi Andreas, hi all,

Thanks for checking! I was noticed by the e-mail, but I voted on the web page at Nov. 14. 3:37 PM, before the deadline. You can check the time stamp by clicking on the small gray time on the right top corner of my vote here:

Best regards,
László

Discourse does not send the e-mails in realtime, but in regular intervals, from what I remember.
If you look at the time of the posting (indeed, the small gray time on the right top corner of the message), I see:

  • my vote posting: “11. Nov. um 15:28
  • your -1 reply: “14. Nov. um 15:37

So that -1 arrived a few minutes after the voting deadline.

For the avoidance of doubt, here are the screenshots, where I marked the time code in red:

and

This is the stuff of conspiracy theory, it has been patiently explained here before.
IANAL but the name of any well defined term is not legally relevant in this context - so it should indeed be a trivial change. Also the defined term here is far from the normal meaning of Affiliation (as we now see from the far more normal Fraunhofer definition).

Why insist on an odd name & avoid a trivial change? Political reasons? Perhaps some - apparently eager to exclude even more ecosystem participants from TDF’s governance - might like to have a new, very expansive definition of Affiliate in the statutes.

Again - I think Italo’s approach of separating concerns to make progress & build consensus is a good one. Perhaps you share the view that pushing more of the ecosystem away is a good thing - but please don’t tangle that up, alongside other unnecessary & controversial statements on the foundation’s purpose by fighting simple helpful changes of these documents.

Hi Florian, hi all,

It seems for me, this is a technical problem, which was unforeseen for the previous board, when it’s decided to allow Discourse for board-discuss and voting. Discourse’s latency was the only reason, why my vote has been ignored the first time, but the validity of my vote is not affected, because the official e-mail (containing [VOTE] in its header) was about 15:38 starting time, see [VOTE] Approve procurement policy and development agreement, revoke previous technical budgeting procedure - #24 by nemeth

The previous board, including me didn’t know about any latency (it can be 10 minutes or more now?), and if I right remember, for a while, it was not possible to vote in e-mail, and if the time had been more visible in Discourse (it was only “3d”) I would have noticed, but I would have had to rely on the original e-mail notification, and voting based on that in Discourse.

The board decision was fortunately not affected by this mistake now, but in the future we should rule out any such technical problems, without creating uncertainty for voters. We can limit Discourse latency, considering also e-mail notifications about the starting time, allowing to vote in e-mail again, too (where all timestamps visible in the e-mail header and received by everyone).

Thanks,
László

I don’t know what the previous board had envisioned when the migration of the board-discuss mailing list to a Discourse forum has been decided.

What I know is that in the aftermath, during the previous board’s term, one elected board member’s postings to this forum has been edited by another board member and a posting has been hidden.

These actions confirm that, in any case, the board decided for a forum, not for a mailing list, because on a mailing list you cannot retroactively edit postings or remove an e-mail. A forum is technically different from a mailing list.

As you see from my screenshots, by a simple click on the message, the day and time is visible in our forum. This even works when you are not logged in, I just verified that.

The e-mail cannot be determining, as the vote started on a forum, not on a mailing list.

Hi Laszlo and all,

we receive periodical notifications via email that something has been posted on Discourse which contain in the subject, I presume is the same for everyone, the tags [TDF Community] [Board Discuss].

While with emails containing just [VOTE] it’s clear what the start date and time is as it’s a direct email, those that contain in the subject [TDF Community] [Board Discuss] [VOTE], and have the layout of messages coming from Discourse, are a delayed notification that a vote has been posted in the public forum so the effective date and time for the start of the vote is the post’s date and time which you can see as shown by Florian.

I don’t think we ever discussed this in the board but as you raised the issue I hope this clarifies the matter for you.

Ciao

Paolo

Furthermore, the e-mail is a setting every user can configure individually and also turn off, as by design of Discourse. This way, we have no influence if or when an e-mail is received, so it cannot be determining for the deadline.

Additionally, I sent a (non-mandatory) information to the BoD chat group on 15:28, the very minute the forum posting went out.

It appears the confusion comes from the fact that ”$N hours from now” is ill-defined. Does the clock start ticking when the keypresses are registered? When the sender presses the Send button (apparently what Florian meant)? When the post enters TDF infra? When the voters are notified (apparently what Laszlo thought)? Something in between?

Fortunately this doesn’t affect the outcome of this particular vote, but I would suggest spelling out the voting deadline in the future to avoid confusion. IIRC I showed the previous the board that Discourse has support for polls which can configured to close at a certain time and where only a given group can vote. That could be a technical solution to the issue.

FWIW email is and always has been a high latency protocol. As a sender one cannot control when precisely a mail will show up in the recipient’s inbox. There are various technical reasons which can delay that (grey listing, DNS glitch, temporary delay by the recipient’s MTA due to overload, etc). I recall this causing issues in the past when someone sent a nomination literally seconds before the deadline.

Discourse delays mail sending by 10 min to give the sender a chance to edit their post, and that’s been like that since day one. It’s arguably a bug that the email’s Date field doesn’t reflect the timestamp shown in the web interface, but anyway Discourse’s email notifications cannot be authoritative. The header also suggest you are the only recipient which is obviously not the case, and for various reasons (recent activity in the web interface, personal settings, etc.) you might not a receive a mail at all. I believe these shortcomings were spelled out when the previous board decided to migrate board-discuss here.

1 Like

Not only one.

Members of the board can still see in Discord’s moderation logs that mostly a couple of former directors censored, edited and deleted posts of many members of the board of trustees.

That’s the most sensible proposal - and it plays to the strength of the new tool, instead of trying to adjust an old process, designed for a different tool (email).

1 Like

It appears the confusion comes from the fact that ”$N hours from now” is ill-defined. Does the clock start ticking when the keypresses are registered? When the sender presses the Send button (apparently what Florian meant)? When the post enters TDF infra? When the voters are notified (apparently what Laszlo thought)? Something in between?

For e-mail we rely on the date information in the header and for the forum we rely on the time listed next to the posting. Both can diverge in theory - the e-mail client can be misconfigured (headers can help though), and due to slow internet connectivity the posting can take one minute to be sent. Last minute actions are always risky, like in the example you used regarding the candidacy that arrived seconds before the deadline.

Fortunately this doesn’t affect the outcome of this particular vote, but I would suggest spelling out the voting deadline in the future to avoid confusion. IIRC I showed the previous the board that Discourse has support for polls which can configured to close at a certain time and where only a given group can vote. That could be a technical solution to the issue.

If we spell out a concrete deadline, if someone wants to challenge that, they can say it was a bit shorter or a bit longer than 72h hours (e.g. drafting the message and then sending it five minutes later), so that doesn’t provide accuracy as well. We also had repeated discussions on what +1, 0, -1 means and what non participation in the vote means, if conditional votes exist etc., so I expect all sorts of challenges. Note that I speak in general, these are examples that happened over the years from various people, I am not refering to anyone individually.

That’s why the poll feature sounds interesting indeed. What worries me is that this forum has been in the past (ab)used to delete board member’s postings or even modify them. I don’t want to end up in a situation that a future board follows that pattern again. The e-mail notification provides some safety, as it is sort of immutable when the e-mail is out, if the modification happens after the mail was sent.

How is that via a poll? Are there e-mails sent when someone votes? Is the vote immutable from the Discourse UI, so such modifications are not possible unless someone has direct access to the box, or can people with moderator/admin rights modify a poll too?

Of course, also with a poll, someone can try to click five seconds to the deadline and then be too late - but, see above, last minute actions can be risky. That’s why e.g. tax offices have postbox with integrated clocks, and at midnight a layer is added automatically. What’s on the other side of the layer has not been received in time.