Hi Paolo,
Paolo Vecchi <paolo.vecchi@documentfoundation.org> 於 2022年3月27日 週日 上午12:34寫道：
Hi Mark,
Hi Paolo,
The list is too long to follow. I have few questions here that I don’t find them addressed in the document:
Yes the discussion has been taking place over a long period of time and across many threads so it is difficult to get all the answers in an easy way.
To try to make it easier to follow a discussion and the various proposals the “Decidim startup proposal” has been presented for approval in the budget and I hope it will find a full consensus within the board to invest on it.
Is that hiring annualy or long term?
( Apologize if this is clear to others. But I don’t know how hiring is done in TDF. )
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.
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.
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?
Why the number is 2 instead of 1?
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.
- 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.
After hiring in-house developer, TDF might become a scapegoat directly, for not fixing users bugs.
What would the expected response be?
We do what we can with the resources that are made available by users/donors.
Whatever we do there will be complains but I think having the internal resources to tackle issues that otherwise would not progress is an important step forward.
What I hope is that people like you will notice that the proposal tries to create opportunities for better interaction and mutual support in tackling difficult issues.
I’ve read some of your and Shinji’s presentations and that’s one of the many reasons why native languages are at the top of the list of my proposal, together with a11y, as it seems like the vast majority of the global population isn’t yet well served by LibreOffice.
2 in-house developers will not solve all the problems for all the users especially when, as you and Shinji rightly pointed out in your presentations, you must be a native speaker to understand and fix some issues. The xkcd in page 8 of your AsiaCon 2019 presentation is spot on in this case as even having the top developers in-house there is a limited amount of fixes/algorithms they can push if they don’t have your support.
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 issues for 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 that tdf#75790 is a real feature gap for Japanese users. I tried to pick it up when I was available without good progress.
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.
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?
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.
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.
![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}