Re: [board-discuss] Further questions on the attic proposal
Hi Andreas, all, Andreas Mantke wrote: > But you didn't consider the mental aspects. > I did, but I still believe that's quite minor compared to the actual development effort. The policy as it stands now is a compromise between a number of needs (and people's ideas), where there's some barrier for moving a project into the attic, and a corresponding barrier for getting it back. Additionally, there were requests that new projects from commercial players should come with certain commitments (and those naturally transfer over into de-atticization). Beyond actually showing development (and finding support at TDF), most of the more burdensome prescriptions in the policy are merely advisory. So the ESC and/or the board can make pragmatic decisions, should an obvious case be brought forward. > But if you fork a Github repo you could make a pull request to the > upstream project. This will be blocked for an attic project by the > proposal. > Sure. But you said not being able to create pull requests leads to insurmountable barriers for new development. I dispute that; and the meta-pullrequest (which this policy specifies) is to submit a git repository hosted & developed outside the TDF realm, via the de-atticization process. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Further questions on the attic proposal (was: [VOTE] Approve the attic proposal)
Hi Thorsten, all, Am 28.03.22 um 21:21 schrieb Thorsten Behrens: (..) The developers which work on that project need to organize their work inside that new environment. They will already organize their workflow and communication channels. The easiest (and for many developers, most convenient & accustomed) venue for that are gitlab or github. To me, that is zero obstacles. You can even give both platforms a remote git repo to clone from, that's, like, two clicks and a paste. that is only the manual part. This may be not very difficult (e.g. if it happens in [nearly] the same environment). But you didn't consider the mental aspects. Why should a developer / a group of developers take their work / their freedom back under the control of the ESC / TDF and had potentially to frighten the attic process again (especially if they work as volunteers in their spare time)? And thus the question pops up, why they should invest their (volunteer) work time to ask for moving the project onto TDF resources, change their workflow etc. and transfer everything onto TDF resources and under the hat and control of TDF. My personal take is - that is very little effort, compared to actually developing. But of course it helps if there's community interest, in pushing/advocating the re-opening. In the past at least, there was interest in having projects hosted at TDF. It comes with good name recognition, and a large and diverse community. I suspect the positive marketing effects would be noticeable, when reviving an atticised project, and therefore (as a developer myself) don't see a problem here. I'd recommend not to gear about towards the past. I'd have a look on the LOOL process and you get the opposite. Thus if TDF moves a project to the attic a steel door is locked behind it with a lot of locks. It will be unlikely that such a project will get back to live inside the TDF environment. I don't think that follows at all (and in fact has very little to do with realities out there - every github project would then be essentially locked, since one needs to fork it to be able to commit). But if you fork a Github repo you could make a pull request to the upstream project. This will be blocked for an attic project by the proposal. Regards, Andreas -- ## Free Software Advocate ## Plone add-on developer ## My blog: http://www.amantke.de/blog -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Translation as part of the attic policy
Hi Sophie, sophi píše v Po 28. 03. 2022 v 21:55 +0200: > Would that mean that each time a l10n team resign for whatever > reason > (UK currently in my mind and heart), it will be atticized and need > at > least 3 contributors who use something else than Weblate to > demonstrate > their contributions to be accepted again in the LO community? >From my point of view, you don't have to worry at all: 1) 'The “attic” is a special area [...] not being actively developed, *can* be stored.' (emphasis mine) => it is up to the l10n community to propose to ESC and Board to atticize something, not that it would go there automatically. If it fits you better not to atticize (eg. there is no risk when incomplete translations are used for production, etc.), I don't think anything forces you to put the particular language to the attic. 2) 'A sufficient number of developers [2] have committed changes', where the [2] says: '1 for small, 3 for medium, and 6 developers for a large project' => if the l10n community decide to atticize something, best if they define the size they'd like to target for the de-atticization. To me, 'small' sounds reasonable for one language. Hope this helps? All the best, Kendy -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] New draft of the proposal for in-house developers
Hi Mark On 27/03/2022 08:34, Mark Hung wrote: Hi Paolo, Paolo Vecchi 於 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
Re: [board-discuss] Translation as part of the attic policy
Hi all, I guess that the definition of what goes in the "attic" needs to be reviewed: "The “attic” is a special area of TDF's infrastructure where part of the code/documentation/translations, which is not being actively developed, can be stored." So should "/documentation/translations," be removed from there it the original meaning was to deal only with code? Ciao Paolo On 28/03/2022 23:45, Thorsten Behrens wrote: Hi Sophie, sophi wrote: Would that mean that each time a l10n team resign for whatever reason (UK currently in my mind and heart), it will be atticized and need at least 3 contributors who use something else than Weblate to demonstrate their contributions to be accepted again in the LO community? Can't speak for the board, but at least my own idea of the attic proposal was - it is entirely focused on code. The l10n project always had their own rules when to include or retire a language (percentage of strings translated), and refined that over the years. My take would be, to let the project continue to self-govern there. [beyond that, the attic process has a git repo as the smallest artifact to turn read-only. So technically, we can't simply atticize a language, which are subdirectories in the helpcontent2 and translation git repositories] Cheers, -- Thorsten -- 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 OpenPGP_signature Description: OpenPGP digital signature
