Hi Mark
On 27/03/2022 08:34, Mark Hung wrote:
Hi Paolo,
Paolo Vecchi paolo.vecchi@documentfoundation.org 於 2022年3月27日 週日 上午12:34寫道：
Hi Mark,
It’s a long term employment project, that’s why I asked the board
to not consider it as a budget line (like tenders) but as a long
term strategic investment.
I wonder if other alternatives have been considered. Ex, tender for a dedicated developer ( to a company or a person ) that under TDF’s board/ ESC command, for 1-2 year term, or other forms of one-time development
service. ( I’m not sure if this is legally feasible. ) The way seems less risky to me.
Expert support is not excluded and it might be necessary for complex items where there local expertise like with CJK is necessary.
A short term one can still be strategic move to make TDF contribute more code and spend more money on development.
I advice to take the short term approach if the risk can not be managed.
Our ED and the rest of the team will help in evaluating the risks and I’m sure they’ll be able to make them manageable.
At the end everything we have been doing involves risks and up to know we managed quite well
The similar question is about the number of developer hired in the rationale section.
If TDF have more money next year, will the number increased? If we need more, can the fund be raised?
These are ideas that have been circulating and can be developed further.
Once the developers settled in and structured their work for themselves in collaboration with the rest of the team we could look at marketing campaigns to attract further funding so that we could even include freshly graduated students/interns that could learn how to work on a complex project like LibreOffice.
Why the number is 2 instead of 1?
Because 2 is the first prime number and a good start to create a development team.
Only 1 developer could find himself/herself overwhelmed but 2 could start exchanging ideas, tasks and processes to improve their productivity.
What’s the lost / cost to TDF if someday the board or future
board want to dismiss the developer, in case something bad
happens or it doesn’t work out?
The cost to TDF could be 0 or quite a lot, like in any
organisation, depending on why the board would want to dismiss an
employee.
Employment contracts allow for “trial periods” as far as I know,
not an HR expert, where if we see that the new employee doesn’t
fit with the organisation he/she can be fairly dismissed while if
the new employee and TDF are both happy then I don’t see why there
should be any issue with a long term employment.
Bad things like
- The newly hired developer do not get well with other core
developers or contributors, being toxic to the community, or
turning other developers or contributors away.
That would mean those developers won’t finish their trial period. We need team players with passion and not primadonna.
- The performance or capability doesn’t meet the expectation, the
number of bug fixes is low, or the developer unable to handle
multiple unrelated areas.
may happen.
The important thing is the process and the attitude they show in problem solving. Some may be more productive in an area more than another and it will be our task to get the best out of them. If things don’t work out then we’ll see that quite quickly.
Could you suggest action points and priorities that I can add to
the proposal so that we can see how to tackle together some of the
issues that are stopping you from contributing and further
improving CJK support?
I’ve fixed most of the issues that I felt important and go back to review tdf#83066 from time to time. I did not fix all of CJK issuesfor various reasons. Ex, I don’t agree with some expected results. Some issues seem to be corner case or document specific. I assume other people can also contribute if they think the unresolved issues important. Personally, I feel thattdf#75790 is a real feature gap for Japanese users. I tried to pick it up when I was available without good progress.
Then we should work together to see how we can make progress happen with the new developers and/or by using specialists that can unblock the situation and allow you to keep contributing.
Is there any preventive measure for the unfair situation
mentioned by Michael Stahl[1],
in which enterprise users who deployed for free, and eventually
they don’t contribute, then endanger the sustenance of the project?
[1]
https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00290.html
It is unfair that millions of LibreOffice users that have the luck
of being able to contribute don’t do it as they don’t seem to
appreciate the efforts that each one of us put into the community.
It would be even more unfair if we weren’t contributing to
LibreOffice for the hundreds of millions of users that are not so
lucky and would have no other options.
To be more specific, my concern is the possiblity of turning contributors away.
Besides the situation aforementioned, I would not have become a contributor, if someone had fixed CJK issues for me 8 years ago.
But there are still many areas where contributions have been lacking for various reasons including the fact that they may be too complex to be tackled by a single volunteer. Also in this case the volunteers could help us in identifying how to unblock the situation and allow them to keep contributing.
What if you add two developers but lose more or get less?
What if you want to fix more bugs but the number of bug fixed become less?
We already have fewer developers contributing to fix a range of bugs so adding 2 may help in reducing complexity for some issues and get more to start contributing.
Adding more resources to development and fixing issues that are stopping hundreds of millions of users from using effectively LibreOffice should lead to more users and possibly more contributors.
I felt these should be addressed.
Of course unfortunately there will be cases where some try to
abuse the system and it would be great if we spot all those cases.
Most will be spotted while others will go through but hopefully
they will be benefiting the majority of users and not specific
business cases where companies/institutions could have contributed
to it.
Your question lead also to other questions:
What about the tenders we pay for with donors money which could
also fix enterprise issues/features?
I’m ok if the main focus is the general public or focus areas in foavor of the disadvantages.
Should we reject tenders that are not fixing bugs and features
that are clearly not for a personal use of LibreOffice?
I assume the selection of the tender is oversee by the ESC and the board. It should be transparent and benefit the general public or focus areas in favor of the disadvantages instead of enterprises who have the ability to pay for themselves.
I do agree but sometimes it seems some “enterprise” features slip through the net of the proposed tenders.
AFAIK there is no fixed rule for it.
Should we consider that Japan is a quite wealthy country so
language issues should be funded by local enterprises and
institutions?
No, we don’t do that based on whether a country is wealthy or not.
Japanese community as a whole should be treated as the general public.
OTOH, requests from the enterprises should be conidered carefully.
Whether the issue is under CJK category is not the only thing needs to be considered.
Judgement is needed in order not to be abused, that is independent of the country or the language.
I agree with you.
As you see the issue could become much more complex than just
having a few fixes slipping through the net.
Our Next Decade Manifesto does not take in consideration the
capacity to contribute of each individual, LibreOffice is free of
charge for all without distinction.
Funding TDF so that we can all invest in many areas, in and with
many communities, is essential and I’m sure that by giving TDF
more internal resources to help each others we will also increase
the willingness of people to donate (in many ways, not just money)
and with a larger user base many organisations will see that is
better also for them to invest in improving and supporting
LibreOffice and its community.
Sincerely,
Mark
Please do come to the Board meetings to ask more questions and provide your feedback.
Ciao
Paolo
