Hi Paolo, Paolo Vecchi <paolo.vec...@documentfoundation.org> 於 2022年3月27日 週日 上午12:34寫道：
> Hi Mark, > > On 25/03/2022 23:39, Mark Hung wrote: > > 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. > 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 > > > Ciao > > Paolo > > > Paolo Vecchi <paolo.vec...@documentfoundation.org> 於 2022年3月23日 週三 > 下午10:09寫道： > >> Hi all, >> >> following the initial consultation in regards to the first draft I've >> included some of the recommendations and comments received. >> >> You can find the new version here: >> >> https://nextcloud.documentfoundation.org/s/d5fF4eCK4JHtpHj >> >> The changes are in italic. >> >> Some of the comment received included preferences for mentors instead of >> developers or to further outsource some tasks. >> Those preferences will be covered by duly prepared proposals written by >> the proponents so they will not be covered in the document I shared. >> >> Other comments received, also from fellow members of the board, stated >> that my proposal lacked of clear developers and project management >> procedures so I've added in page 10 what I see, at least initially, as >> the simplest approach but suggestions for improvements are very welcome. >> >> Please do remind me if I forgot to include your constructive feedback! >> >> Ciao >> >> Paolo >> >> -- >> 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: https://www.documentfoundation.org/imprint >> >> > > -- > Mark Hung > > > -- > 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: https://www.documentfoundation.org/imprint > > -- Mark Hung
