Re: [board-discuss] Advisory Board Membership of Rubitech-Astra
Hi Sophie, thanks for your support. I also thank Paolo and Simon for their backing too. It would be great, if TDF could make a decision on this topic during this evening and create a statement. I think physical integrity, self-determination, freedom of expression are indispensable foundations of the LibreOffice community. And TDF doesn't want to be associated with any member / organization which is connected to violation of this foundations or with the breach of international law, attacks against other countries (e.g. the Ukraine) or war lords. Although TDF makes usually no political statements maybe there need to be an exception in this special case. Regards, Andreas Am 25.02.22 um 20:27 schrieb Sophie: Le 25 février 2022 14:29:06 GMT+01:00, Andreas Mantke a écrit : Hi, according to the TDF website (https://www.documentfoundation.org/governance/advisory-board/) LLC Rubitech-Astra is currently member of the TDF Advisoriy Board. I looked onto this wikipedia page: https://en.wikipedia.org/wiki/RusBITech. There is stated that their software is used for the Russian government and army. In my view TDF should reconsider the membership of Rubitech-Astra after breach of international law by Russia and the attack against the Ukraine Thanks Andrea for bringing this difficult topic, I support your request too. Cheers Sophie Regards, Andreas -- ## Free Software Advocate ## Plone add-on developer -- 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 -- ## Free Software Advocate ## Plone add-on developer -- 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] Advisory Board Membership of Rubitech-Astra
Le 25 février 2022 20:27:15 GMT+01:00, Sophie a écrit : > > >Le 25 février 2022 14:29:06 GMT+01:00, Andreas Mantke a écrit : >>Hi, >> >>according to the TDF website >>(https://www.documentfoundation.org/governance/advisory-board/) LLC >>Rubitech-Astra is currently member of the TDF Advisoriy Board. I looked >>onto this wikipedia page: https://en.wikipedia.org/wiki/RusBITech. There >>is stated that their software is used for the Russian government and army. >> >>In my view TDF should reconsider the membership of Rubitech-Astra after >>breach of international law by Russia and the attack against the Ukraine > >Thanks Andrea Oups sorry Andreas of course, was a long week :) Cheers Sophie -- 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] Advisory Board Membership of Rubitech-Astra
Le 25 février 2022 14:29:06 GMT+01:00, Andreas Mantke a écrit : >Hi, > >according to the TDF website >(https://www.documentfoundation.org/governance/advisory-board/) LLC >Rubitech-Astra is currently member of the TDF Advisoriy Board. I looked >onto this wikipedia page: https://en.wikipedia.org/wiki/RusBITech. There >is stated that their software is used for the Russian government and army. > >In my view TDF should reconsider the membership of Rubitech-Astra after >breach of international law by Russia and the attack against the Ukraine Thanks Andrea for bringing this difficult topic, I support your request too. Cheers Sophie > >Regards, >Andreas > >-- >## Free Software Advocate >## Plone add-on developer > > >-- >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 > -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté. -- 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
[board-discuss] Re: Draft document for TDF in-house developers proposal
On 25.02.22 15:43, Paolo Vecchi wrote: Hi Michael, thanks for your feedback. On 25/02/2022 10:22, Michael Meeks wrote: > In the graph above the committers have been grouped in Commercial > (companies specialised in selling LibreOffice development and > products), Corporate (companies and institutions contributing > voluntarily) I'm intrigued by this distinction; can you specify which entities are in which bucket and why ? The macro categories can be easily worked out but here they are: Commercial contributors: * Collabora * CIB->Allotropia Corporate contributors: * RedHat last i worked there, LibreOffice was a fully supported part of Red Hat Enterprise Linux that customers could and did file enhancement requests for. * Assigned (a bit of a mix but volumes don't change much the result) err, no: these are people who are not contributing as part of their employment, although they *may* be paid Google Summer of Code interns. the way it works is that or people who contribute at different times with different employers, their contributions for their employer are counted for their employer, while their contributions with no employer are counted as "Assigned". * NISZ * SIL * Munich Volunteers: * Unknown (no official affiliation) and TDF own contributions. > TDF has to develop a strategy which includes the employment > of internal developers which will both increase the speed of > development and will help with the on-boarding of new external > commercial, corporate and volunteer contributors. Why do you believe that in-house developers (vs. say mentors) will help with on-boarding new contributors if that is not their focus? My suspicion is that mentoring is hard and "doing it yourself" is superficially easy in the short term. As from previous answer: "Learning by doing (fixing bugs) will help those developers in helping others following the same path while getting rid of issues that commercial contributors and volunteers have overlooked." i think what Michael meant is: how do you get an experienced developer to spend 3 hours discussing a problem with a newbie spread across a longer time period and giving them hints to fix it and review their work, instead of simply fixing it themselves in a single session in half the time, if their job title is "developer" and not "mentor". > and the quantity of bugs, features and updates that may require > tendering or paid for services by the commercial contributors is > still so vast that it will not affect noticeably their income While it is true that there may be an inexhaustible amount of work and TDF will never reduce that by doing some of it, I'm not sure that is really relevant. Tendering has been used by TDF to help stimulate, diversify and sustain the commercial ecosystem around LibreOffice since the beginning. TDF has a fairly fixed amount of cash - if there is less of that to spend, that will have a non-trivial impact. The methods tested up to now to stimulate and diversify the number of more commercial contributors haven't brought the desired result as it seems like mostly 2 companies bid for those tenders so we'll have to work harder on it. how do you expect to grow the number of companies who bid for tenders if there are not more tenders? N companies bidding for a tender means that N companies spend significant time doing estimations, but N-1 companies get 0 income for that effort. Worse than that though is the possible for TDF to significantly harm the market for bug-fixing far in excess of any work it can do - by creating the idea that there is a "free" way to have issues addressed through political machination at TDF. I'm concerned by your comment as you seem to put in doubt the neutrality and the dedication to the wider community of TDF's team. Reading it in another way someone may even think that "political machination" tried to stop TDF to fully express its potential for serving the wider community. Naturally not many people came up with those thoughts so I guess they really aren't an area of concern for most. i guess you aren't familiar with the history of this project, but this was very common in OpenOffice.org times: when a beta was released, suddenly a bunch of people came out of the woodwork to complain very loudly on public lists why bug X or bug Y had not been fixed and how this could possibly be given that this bug is obviously so severe that the product is unusable. in many cases what happened then is that Sun fixed the bug before the release - a bug which was actually found by some enterprise user who deployed "free" OOo and paid a consultant to file the bug in IssueZilla and then make a noise about it, without paying any developer to actually fix the bug. -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems?
Re: [board-discuss] Advisory Board Membership of Rubitech-Astra
Hi Andreas, thanks for spotting this. While most Russian people and organisations have nothing to do with with the horrible ongoing conflict, RusBITech seems to be mostly engaged with the Russian military complex and we surely don't want to be associated with enablers of what is going on. Unfortunately this symbolic gesture won't help stopping the destruction and suffering but I agree with you that we should immediately suspend their membership pending further investigation in regards to their position. Ciao Paolo (The above is my own personal view) On 25/02/2022 14:29, Andreas Mantke wrote: Hi, according to the TDF website (https://www.documentfoundation.org/governance/advisory-board/) LLC Rubitech-Astra is currently member of the TDF Advisoriy Board. I looked onto this wikipedia page: https://en.wikipedia.org/wiki/RusBITech. There is stated that their software is used for the Russian government and army. In my view TDF should reconsider the membership of Rubitech-Astra after breach of international law by Russia and the attack against the Ukraine. Regards, Andreas -- ## Free Software Advocate ## Plone add-on developer -- 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
[board-discuss] Re: Draft document for TDF in-house developers proposal
Hi Michael, thanks for your feedback. On 25/02/2022 10:22, Michael Meeks wrote: On 23/02/2022 16:01, Paolo Vecchi wrote: Thanks to your comments I started writing a more structured proposal Thanks for doing that that - it helps. There are some good things about this proposal that are reasonable. I did my best to create a proposal that will allow TDF, the wider community and the various ecosystems to grow in an independent and meritocratic way. You can find the draft which starts outlining various concepts and lists some of the issues we have to address here: https://nextcloud.documentfoundation.org/s/fM8pCesPnF2JjN4 It's a bit sad it is a PDF, and without any heading numbering, so rather hard to interact with; an ODT that allowed comments / patching would be better. Instead I'll quote the text from the document as if you've mailed it here to comment on it. Until we have a Decidim instance running where we can test the best ways to collect feedback from the community, the mailing list seems to be the best way to collect and summarise the comments. I think my biggest concern is ultimately around managing the process of who decides what TDF should invest in - this is potentially extremely contentious and emotive over time, as are all ~zero sum resource decisions. Your proposal has: > The focus of the in-house developers will be set on specific areas > suggested for them by TDF’s team in consultation with the ESC and, > in case of unresolved conflicts, the board." Our current tendering process is open to everyone to make suggestions (although estimation bandwidth has to be provided by the ESC). It is ultimately approved (with the input of the ESC) by the elected board. I strongly prefer an open process like this that includes the community and is accountable to them. Of course it's great to have more input from the staff on priority areas - but I hope they're already well connected to the tendering process and the ESC. TDF's team is already participating to ESC meetings and with dedicated internal developers participating to those meetings they will add a different point of view to issues resolution and will be able to move faster on focus areas or small bugs, as they won't need to go through the tendering process, while at the same time verifying with ESC eventual overlaps. Many members of the ESC are employed by commercial contributors, are involved in proposing tenders to the board and are actually working on them when they win the bid so it will be easy to understand what overlaps and what doesn't. In contrast - the huge advantage of mentoring as an approach is that whomever wants to work on something gets help in proportion to their ability. That tends to solve the problem of working out what to do fairly - while giving some ability to steer via the creation of easy-hacks in specific areas etc. IMHO it isn't "in contrast", it's in addition to what is being done by TDF presently. As written in reply to Michael Weghorn: "Learning by doing (fixing bugs) will help those developers in helping others following the same path while getting rid of issues that commercial contributors and volunteers have overlooked." Then I have a few other points: > In the graph above the committers have been grouped in Commercial > (companies specialised in selling LibreOffice development and > products), Corporate (companies and institutions contributing > voluntarily) I'm intrigued by this distinction; can you specify which entities are in which bucket and why ? Looking at the raw data on the dashboard I wanted to understand a bit more about the trends and the composition of code contributors macro categories. The why is in the document: "Differentiating the type of committers is important as TDF’s developers will in general bring benefits to all but in some situations might be seen as being in competition against the commercial contributors so we need to evaluate what effect they may have on their business models while allowing TDF to grow." As you have noticed I took "the top 10 contributors over the past 5 full years" as it's the period when contributors numbers start to stabilise. The macro categories can be easily worked out but here they are: Commercial contributors: * Collabora * CIB->Allotropia Corporate contributors: * RedHat * Assigned (a bit of a mix but volumes don't change much the result) * NISZ * SIL * Munich Volunteers: * Unknown (no official affiliation) and TDF own contributions. I believe lots should be done to see if the "unknown" category could be better understood and find out how we can help groups of contributors in that macro category but that's something I still have to work as a separate project with the help of the team. > TDF has to develop a strategy which includes the employment > of internal developers which will both increase the speed of >
Re: [board-discuss] Advisory Board Membership of Rubitech-Astra
I support the request Andreas had make and ask the Board to act as soon as possible. S. On Fri, 25 Feb 2022, 13:30 Andreas Mantke, wrote: > Hi, > > according to the TDF website > (https://www.documentfoundation.org/governance/advisory-board/) LLC > Rubitech-Astra is currently member of the TDF Advisoriy Board. I looked > onto this wikipedia page: https://en.wikipedia.org/wiki/RusBITech. There > is stated that their software is used for the Russian government and army. > > In my view TDF should reconsider the membership of Rubitech-Astra after > breach of international law by Russia and the attack against the Ukraine. > > Regards, > Andreas > > -- > ## Free Software Advocate > ## Plone add-on developer > >
[board-discuss] Advisory Board Membership of Rubitech-Astra
Hi, according to the TDF website (https://www.documentfoundation.org/governance/advisory-board/) LLC Rubitech-Astra is currently member of the TDF Advisoriy Board. I looked onto this wikipedia page: https://en.wikipedia.org/wiki/RusBITech. There is stated that their software is used for the Russian government and army. In my view TDF should reconsider the membership of Rubitech-Astra after breach of international law by Russia and the attack against the Ukraine. Regards, Andreas -- ## Free Software Advocate ## Plone add-on developer -- 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] Re: Draft document for TDF in-house developers proposal
On 24/02/2022 15:56, Paolo Vecchi wrote: On 24/02/2022 13:42, Michael Weghorn wrote: Regarding app stores (p. 5), IIRC, Michael (Meeks) suggested to separate that topic from the current discussion, which I think makes sense. I think it would make sense to focus on identifying non-controversial areas that should be worked on (e.g. what's listed as "Focus areas" from page 6 on) and then see how internal developers could help there, but also leave room to discuss potential alternative solutions. Agreed. once they are settled and productive we should consider fulfilling our mission for users I think arguing that our mission requires us to do something or other in app-stores is controversial, particularly for a fee: The proposal draft says: > As determined in the past months TDF has in-house competences that > would allow us to start publishing LibreOffice Community in the > Windows and Apple app stores at a nominal price. Even if it is the right thing to do - and I think strategically it is an important move to consider how the project gets income in this way I would not say that: The topic isn't that controversial as it has been discussed at length in public and within the board. discussing something at length normally is a good sign of it being somewhat controversial =) Last I heard there was still a significant push from some to make all software free of price in every forum. > Even if my preference is to have TDF running the app stores, so > that we can reinvest not only in development but also in other > projects that help the wider community, I expect that all proposals here take into account the bigger picture of delivering improvements for LibreOffice; the differences being mostly over structure, control, jurisdiction etc. > there are still 2 proposals for business entities that would do just > that and the members of the ecosystem are perfectly fine with it. So - I see no necessity to make the proposal more controversial than it needs to be, by pre-deciding that TDF should employ resources to be focused on this: which could be seen to prejudice this decision in line with your preference. I would recommend removing that piece. Anyhow - otherwise, as I've said - modulo some deep concerns over decision making on how the new staff are deployed, and this unnecessary angle, I'm mildly supportive (for what it is worth). Regards, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- 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
[board-discuss] Re: Draft document for TDF in-house developers proposal
On 23/02/2022 16:01, Paolo Vecchi wrote: Thanks to your comments I started writing a more structured proposal Thanks for doing that that - it helps. There are some good things about this proposal that are reasonable. You can find the draft which starts outlining various concepts and lists some of the issues we have to address here: https://nextcloud.documentfoundation.org/s/fM8pCesPnF2JjN4 It's a bit sad it is a PDF, and without any heading numbering, so rather hard to interact with; an ODT that allowed comments / patching would be better. Instead I'll quote the text from the document as if you've mailed it here to comment on it. I think my biggest concern is ultimately around managing the process of who decides what TDF should invest in - this is potentially extremely contentious and emotive over time, as are all ~zero sum resource decisions. Your proposal has: > The focus of the in-house developers will be set on specific areas > suggested for them by TDF’s team in consultation with the ESC and, > in case of unresolved conflicts, the board." Our current tendering process is open to everyone to make suggestions (although estimation bandwidth has to be provided by the ESC). It is ultimately approved (with the input of the ESC) by the elected board. I strongly prefer an open process like this that includes the community and is accountable to them. Of course it's great to have more input from the staff on priority areas - but I hope they're already well connected to the tendering process and the ESC. In contrast - the huge advantage of mentoring as an approach is that whomever wants to work on something gets help in proportion to their ability. That tends to solve the problem of working out what to do fairly - while giving some ability to steer via the creation of easy-hacks in specific areas etc. Then I have a few other points: > In the graph above the committers have been grouped in Commercial > (companies specialised in selling LibreOffice development and > products), Corporate (companies and institutions contributing > voluntarily) I'm intrigued by this distinction; can you specify which entities are in which bucket and why ? > TDF has to develop a strategy which includes the employment > of internal developers which will both increase the speed of > development and will help with the on-boarding of new external > commercial, corporate and volunteer contributors. Why do you believe that in-house developers (vs. say mentors) will help with on-boarding new contributors if that is not their focus? My suspicion is that mentoring is hard and "doing it yourself" is superficially easy in the short term. > TDF could start with posting for job positions where experience in > a11y, RTL, CJK, CTL are to be considered desired skills to see > if we can already find specialists in areas that have been neglected > for a while This is at least a realistic approach if these are the areas to invest in - then hiring for a specific skill-set looks reasonably achievable. > There are many small bugs or small features that, if developed by > tendering the project, could cost as much as the yearly salary of a > good developer if adding together the effort of creating the > tender, the actual cost of the development and the verification of > the deliverables Clearly for small tasks - the costs and overhead of the tendering process are (apparently) grossly excessive. Why this is quite so bad is unclear to me (having not been involved) - the tenders often arrive pre-written by the community; the estimation is not done by TDF, only deciding on bids & procuring, but the flow seems very high latency and burdensome somehow. Perhaps with a more technical board this term that is easier to fix. > Commercial contributors confirm that tenders issued by TDF form a > negligible part of their income Collabora publishes numbers on this at the conference each year - between 0% and 5% of income depending; but still, 5% is not insignificant. > and the quantity of bugs, features and updates that may require > tendering or paid for services by the commercial contributors is > still so vast that it will not affect noticeably their income While it is true that there may be an inexhaustible amount of work and TDF will never reduce that by doing some of it, I'm not sure that is really relevant. Tendering has been used by TDF to help stimulate, diversify and sustain the commercial ecosystem around LibreOffice since the beginning. TDF has a fairly fixed amount of cash - if there is less of that to spend, that will have a non-trivial impact. Worse than that though is the possible for TDF to significantly harm the market for bug-fixing far in excess of any work it can do - by creating the idea that there is a "free" way to have issues addressed through political machination at TDF. That needs extremely careful framing and communication
Re: [board-discuss] Re: Draft document for TDF in-house developers proposal
On 25.2.2022 10.29, Paolo Vecchi wrote: Hi Ilmari, thanks for the feedback. On 25/02/2022 09:06, Ilmari Lauhakangas wrote: Indeed, interop is very far from a neglected topic. Would definitely not include it as a focus area. Ilmari Is the whole Interoperability area that is well looked after or just MSO? Any other file formats that need to be improved? I was also looking at https://www.documentliberation.org and wondering if that would/should be part of the interoperability area that needs more attention. Probably some non-MSO formats would fit the category of not being very active, but I don't perceive them as a high priority area based on what users talk about. Ilmari -- 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] Re: Draft document for TDF in-house developers proposal
Hi Ilmari, thanks for the feedback. On 25/02/2022 09:06, Ilmari Lauhakangas wrote: Indeed, interop is very far from a neglected topic. Would definitely not include it as a focus area. Ilmari Is the whole Interoperability area that is well looked after or just MSO? Any other file formats that need to be improved? I was also looking at https://www.documentliberation.org and wondering if that would/should be part of the interoperability area that needs more attention. 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 OpenPGP_signature Description: OpenPGP digital signature
Re: [board-discuss] Re: Draft document for TDF in-house developers proposal
On 25.2.2022 3.43, Thorsten Behrens wrote: Michael Weghorn wrote: Regarding interoperability with MSO (p. 6), I don't have the impression that this is in general a neglected topic that would necessarily need special attention from TDF side at this point (in addition to what's already happening e.g. via tenders). The link that you provided for the metabug seems to show that there are a couple of bugs or three that need some attention. Certainly! There is certainly enough work to engage a multitude of developers in this area (and others). My thought was that - other than other topics mentioned - it generally seems to be less of a "niche" area in which there is generally little interest from others at the moment. Indeed. The other areas both have a lot of bugs, and almost no fixing activity. For interop, there's a lot of bug filing (i.e. community/user interest), but also a lot of bug fixing going on. The query from Michael currently shows 1973 open, vs. 3055 fixed. So I agree that beyond the ESC-ranked focus projects, it appears no intervention from TDF is currently necessary there. Indeed, interop is very far from a neglected topic. Would definitely not include it as a focus area. Ilmari -- 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
