Hi all,
[if you want to skip reading the motivation for my vote just scroll to the end]
in theory I should be pleased as, regardless of how it has been done, another one of the big step forward I wanted for TDF is finally being voted on.
OTOH in a few lines it manages to put together what I agreed with Jan that should NOT be there and what also the legal consultation advised against.
In the specific:
- who will report to the ED as a regular team member, and consult weekly
with the ESC, which will oversee the technical direction of the work;
That part has been discussed at length with Jan as he also wanted the ESC to decide on all technical matters without recourse.
The Board can accept/refuse members or even disband it but the ESC is still a committee with no legal power (and liabilities) over TDF's members of staff.
Stating the ESC "will oversee the technical direction" implies a decisional power which affects the developers work in a direct way.
As the ESC cannot impose anything other members, that could even be affiliated with other companies following their own interests, it cannot demand that TDF's staff follow any of their directions being technical or not.
Jan seemed to have agreed on that and we compromised on these sentences:
"The in-house developers will participate to the weekly ESC calls to discuss their achievements and exchange ideas/experiences with other members. The in-house developers will also exchange ideas in relation to the best ways to tackle issues in the Focus Areas.
The in-house developers will have the same rules, rights and conditions as any other volunteer or corporate contributors. Overlaps or prioritisations that find no clear conclusion between the team and the ESC will be evaluated by our Executive Director with the support of our mentors and reported to the Board of Directors for the final decision."
With that formulation TDF's staff can report back things they might not agree with and get directions from the relevant bodies.
The concept was further clarified with the following sentence:
"While in-house developers will participate also in voting sessions they will not be bound by any vote result or decision taken by the ESC. Only TDF’s team together with our Executive Director will decide, through consultation with the Board if necessary, which tasks the in-house developers will perform."
Jan was not too keen in making things this crystal clear and stated in a note that can be read in version 3:
"Not acceptable in this form, all the developers (corporate, volunteer, in-house) have to have the same rights, otherwise the balance in the community will be lost.
If tasking is the concern, it is handled separately, in the “Selecting development areas”."
If the ESC takes a decision that TDF's staff believes is against TDF's best interests, goals and mission then they can't act the way the ESC says, they will have to report to the relevant bodies and a decision will need to be taken or they will put their job at risk. I'm sure other organisations with their members of staff in the ESC would pretend to do the same.
It is a shame that this part of the analysis, that has been also subjected to legal consultation, hasn't been in taken in consideration for the sake of a KISS which will create many issues down the line.
Then this one is interesting:
- for whom as the initial areas of work, the board identifies
improving RTL/CTL writing support and accessibility for LibreOffice;
as well as mentoring new volunteers in these specific areas.
After that, depending on skills available, Writer tables, Base,
general regression fixing, Draw, and Math are the next focus areas;
Jan tried to impose the following limitation in other ways and even resigned over it:
"TDF in-house developers will not compete with commercial contributors and will not develop alternative implementations of Open Source projects actively maintained by LibreOffice volunteer or corporate contributors – like Collabora Online, mdds, or cppunit"
To avoid mentioning Collabora Online only specific specific areas have been mentioned leaving out all the rest.
It's crafty but it naturally creates it own issues.
I won't comment on the range of technical/development limitation the construction of that sentence creates as others can do a better job than me at that.
Jan and I agreed that in-house developers will contribute fixes and support for improving LibreOffice presence on the app stores, I guess it will need to be done by someone else then.
In the now ditched proposal was also agreed that the in-house developers would have played an important role in helping out with the technical evaluation of the items that have been passed on for tendering and in the evaluation of the deliverables. So it seems like this isn't a role they will be involved with any more with great loss for efficiency and accountability.
Then there is also the small issue of Article 8.
Having Thorsten, Gabor and Cor declared an "interest" on the matter but regardless of that rammed through this proposal and voted +1 on it, doesn't it make it quite problematic in terms of potential/perceived conflict of interests?
Because of my bad habit of pointing out issues and trying to fix them I'm being put in a condition of not being able to perform my role of director in these matters so I have little hope that those issues will be solved.
I only hope that new boards will evaluate things in a more comprehensive way and avoid pushing forward decisions that down the line will create issues and debates, as I believe this will bring.
Considering the above and hoping that somehow fixes will be implemented if this vote passes, I abstain.
Ciao
Paolo
