Re: [board-discuss] Draft text: an "attic" proposal - version 2.0
Hi, Thorsten Behrens wrote on 14/03/2022 21:20: Caolán McNamara wrote: I tend to agree. I don't think making it trivial to deattic something by applying a set of superficial commits to a very large code base which don't achieve meaningful change while f.e. unaddressed security issues mount up, creating a sort of zombie would be a good idea. Indeed, the proposal had a large project (like core or online) in mind. wrt the proposals exact number of devs and commits, I could imagine that on getting atticed a project is categorized into small, medium, large with 1, 3, 6 devs required to de-attic if there is genuine concern about the proposed bar being too high vs a new from scratch project. I like this idea. It nicely addresses the problem. Ah you already made an nice proposal on this matter, Caolán. Sorry I missed that early in the evening :) Cor -- Cor Nouws, member Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: http://www.documentfoundation.org/imprint GPD key ID: 0xB13480A6 - 591A 30A7 36A0 CE3C 3D28 A038 E49D 7365 B134 80A6 mobile : +31 (0)6 25 20 7001 skype : cornouws blog: cor4office-nl.blogspot.com jabber : cor4off...@jabber.org -- 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] Draft text: an "attic" proposal - version 2.0
Hi *, Caolán McNamara wrote: > I tend to agree. I don't think making it trivial to deattic something > by applying a set of superficial commits to a very large code base > which don't achieve meaningful change while f.e. unaddressed security > issues mount up, creating a sort of zombie would be a good idea. > Indeed, the proposal had a large project (like core or online) in mind. > wrt the proposals exact number of devs and commits, I could imagine > that on getting atticed a project is categorized into small, medium, > large with 1, 3, 6 devs required to de-attic if there is genuine > concern about the proposed bar being too high vs a new from scratch > project. > I like this idea. It nicely addresses the problem. The other option, at this stage (we're discussing a substantially unmodified proposal here since almost three months!), would be to first ratify the atticisation part of the text. Those bits have not received tangible input in a while, and we could finally get the online repo out of its undefined state. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Draft text: an "attic" proposal - version 2.0
Hi Jan, On 14/03/2022 19:43, Jan Holesovsky wrote: Hi Paolo, Paolo Vecchi píše v Po 14. 03. 2022 v 17:07 +0100: I have to agree with you that the process seems to be too cumbersome and it would very likely lead to the end of the project, so may as well delete it, or to forks that will never come back. Interestingly when I've read the de-atticization part of the attic proposal, I had the feeling it goes well with your proposal that when a commercial entity wants to contribute a project, they have to go through extra scrutiny? What has changed, please? Nothing has changed at all. As already explained also to Allotropia in regards to their WASM project I asked if they could officially present their project to TDF in a page or 2 where they also state what part of the project hosted at TDF will be made available for free to the community in full respect of our statutes and mission to lead by example and show that commercial contributors are very welcome, we don't want to complicate things but the relationship should be clear from the beginning to protect each others interests. That's the same thing that should have happened with LOOL to clarify what type of relationship was there between TDF and the commercial contributor but the commercial contributor decided to clarify it in its own way. As plenty of time has passed by since LOOL has been forked I would even propose to just re-open the repository and let the community decide if they are actually interested in contributing to it. With my developer hat on (ie. not Board, not Collabora), I'd like to point out that you should consider the implications of potential or real security issues. How do you want to force the community to fix those? [I mean, who will be the actual people actually fixing those?] What if the re-opened repo gets a CVE? A bit of a shame that LOOL's repository was blocked when we had a bug bounty going on as maybe it would have discovered other security issues but yes we are all aware that there are CVE present in there and it would be up to those that start working on it to look at them and fix them. We may discover that the community is actually interested in contributing to a LOOL which is unlikely to reach features parity with other similar products but that is good enough for some use cases where basic features and a lightweight component is needed. Still with my developer hat on, I think you underestimate the complexity of the Online editing problem; the programming was just completely different 25 years ago (I think you said you used to be a developer then?). I used to be a developer and stopped about 25 years ago as I fancied taking on new challenges. It's true that through the 80s and 90s software development was different but I can assure you that there were levels of complexity that aren't that different from today's systems and the tolerance for errors were probably a lot narrower. The problems that the Online has to sort out are complex; like extremely complex; like nobody-25-years-ago-could-imagine-how-much complex: Lots of asynchronous communication, performance implications (on many levels - in C++, in C++/JS combination, in JS, on the network), limitations of JavaScript, limitations of various browsers, and more. And solving these problems is painful, there are no good tools to debug the C++ / JavaScript combination, developers who love C++ hate JS & the other way around, etc. I bet there are quite a few older developers that would tell you that 25/30 years ago we could imagine those level of complexities as in substance nothing much has changed. I would go as far as saying that you have a lot more tools and information that we had back then and that it was probably much more difficult to handle communication and code optimisation, when we had to deal with X.25 networks, modems and a few MB of RAM, than it is now. So, yes, I do fully understand what you are talking about. In other words, from the development point of view, there is no "basic features and a lightweight component" possible for the approach that COOL / LOOL is using. Maybe a small number of passionate and capable developers will be able to fix the CVEs and bring LOOL to a state where it could work well with the features left since the fork for those that don't need new fancy features. The point is that we don't know until we open the repository and let people know that is available with all the relevant warnings. If no one will take on the challenge within 12 months then we will know that there is no even point to put it in an "attic". All the best, Kendy 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] Draft text: an "attic" proposal - version 2.0
hi Andreas, On 14.03.22 18:36, Andreas Mantke wrote: and with the proposal the Android Viewer had to be put the attic and wouldn't currently get the chance to get out of this state (because only one developer looking for it). that's a bad example: the Android Viewer is in the core.git repository. there is no practical way to "move it to the attic" - in the hypothetical case, i'm pretty sure it would be considered too much effort to disentangle a dead project from core.git and there would just be a commit that deletes the code, as has happened for multiple large pieces of obsolete code in the past (just this year i happily deleted 2 WebDAV UCPs). -- 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] Draft text: an "attic" proposal - version 2.0
Hi Paolo, Paolo Vecchi píše v Po 14. 03. 2022 v 17:07 +0100: > I have to agree with you that the process seems to be too cumbersome > and > it would very likely lead to the end of the project, so may as well > delete it, or to forks that will never come back. Interestingly when I've read the de-atticization part of the attic proposal, I had the feeling it goes well with your proposal that when a commercial entity wants to contribute a project, they have to go through extra scrutiny? What has changed, please? > > As plenty of time has passed by since LOOL has been forked I would > even > propose to just re-open the repository and let the community decide > if > they are actually interested in contributing to it. With my developer hat on (ie. not Board, not Collabora), I'd like to point out that you should consider the implications of potential or real security issues. How do you want to force the community to fix those? [I mean, who will be the actual people actually fixing those?] What if the re-opened repo gets a CVE? > We may discover that the community is actually interested in > contributing to a LOOL which is unlikely to reach features parity > with > other similar products but that is good enough for some use cases > where > basic features and a lightweight component is needed. Still with my developer hat on, I think you underestimate the complexity of the Online editing problem; the programming was just completely different 25 years ago (I think you said you used to be a developer then?). The problems that the Online has to sort out are complex; like extremely complex; like nobody-25-years-ago-could-imagine-how-much complex: Lots of asynchronous communication, performance implications (on many levels - in C++, in C++/JS combination, in JS, on the network), limitations of JavaScript, limitations of various browsers, and more. And solving these problems is painful, there are no good tools to debug the C++ / JavaScript combination, developers who love C++ hate JS & the other way around, etc. In other words, from the development point of view, there is no "basic features and a lightweight component" possible for the approach that COOL / LOOL is using. 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] Draft text: an "attic" proposal - version 2.0
Hi, Andreas Mantke wrote on 14/03/2022 18:36: and with the proposal the Android Viewer had to be put the attic and wouldn't currently get the chance to get out of this state (because only one developer looking for it). Fair point. One could think of a way that the activity/nr of devs asked, has a relation with the initial project/project from the past. Emiliano, Thorsten, what do you think? I created two projects for TDF infra in 2011 (and two further in 2012 and 2013). If you'd ask for the same commitment to start / run this so that's not the aim, as I explained. projects as for de-attic a project, this projects wouldn't have been supported / used by TDF. Cheers, Cor -- Cor Nouws, member Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: http://www.documentfoundation.org/imprint GPD key ID: 0xB13480A6 - 591A 30A7 36A0 CE3C 3D28 A038 E49D 7365 B134 80A6 mobile : +31 (0)6 25 20 7001 skype : cornouws blog: cor4office-nl.blogspot.com jabber : cor4off...@jabber.org -- 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] Draft text: an "attic" proposal - version 2.0
Hi Cor, all, Am 14.03.22 um 17:34 schrieb Cor Nouws: Hi Andras, Andreas Mantke wrote on 13/03/2022 16:12: the quintessence of he proposal would be that a project will at 99,9% or more wouldn't get out of the attic state inside the TDF resources. The barriers to de-attic a project and make it an active project inside TDF are much higher than setting up / starting a new project. That is true. On the other hand: is it reasonable to compare a new project with one that is in attic state? For a new project - and I think TDF will adopt projects all too swift - you create a stage so that there is a place to grow, prove oneself. When a project has been paused at some moment, that will not have been done without thinking, consideration, extra efforts to avoid etc. as well. So based on this, one not make conclusions on the current proposal by 'comparing' the cases. For me the clear demands in the proposal are to prevent a situation where projects restart without a good change on success, which is IMO quite relevant for TDF's good name. and with the proposal the Android Viewer had to be put the attic and wouldn't currently get the chance to get out of this state (because only one developer looking for it). I created two projects for TDF infra in 2011 (and two further in 2012 and 2013). If you'd ask for the same commitment to start / run this projects as for de-attic a project, this projects wouldn't have been supported / used by TDF. Thus I'm happy that never used TDF resources for the source code of my projects and could fork and further develop this projects without explicit permission of TDF. I don't think the attic proposal will help TDF to save it's reputation. It's a clear statement of setting further barriers to volunteer work. 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] Draft text: an "attic" proposal - version 2.0
On Mon, 2022-03-14 at 17:34 +0100, Cor Nouws wrote: > For me the clear demands in the proposal are to prevent a situation > where projects restart without a good change on success, which is IMO > quite relevant for TDF's good name. I tend to agree. I don't think making it trivial to deattic something by applying a set of superficial commits to a very large code base which don't achieve meaningful change while f.e. unaddressed security issues mount up, creating a sort of zombie would be a good idea. wrt the proposals exact number of devs and commits, I could imagine that on getting atticed a project is categorized into small, medium, large with 1, 3, 6 devs required to de-attic if there is genuine concern about the proposed bar being too high vs a new from scratch project. -- Caolán McNamara, 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 -- 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] Draft text: an "attic" proposal - version 2.0
Cor Nouws wrote on 14/03/2022 17:34: Hi Andras, Andreas Mantke wrote on 13/03/2022 16:12: the quintessence of he proposal would be that a project will at 99,9% or more wouldn't get out of the attic state inside the TDF resources. The barriers to de-attic a project and make it an active project inside TDF are much higher than setting up / starting a new project. That is true. On the other hand: is it reasonable to compare a new project with one that is in attic state? For a new project - and I think TDF will adopt projects all too swift - will _not_ - that should read of course. you create a stage so that there is a place to grow, prove oneself. When a project has been paused at some moment, that will not have been done without thinking, consideration, extra efforts to avoid etc. as well. So based on this, one not make conclusions on the current proposal by 'comparing' the cases. For me the clear demands in the proposal are to prevent a situation where projects restart without a good change on success, which is IMO quite relevant for TDF's good name. Cheers, Cor -- Cor Nouws, member Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: http://www.documentfoundation.org/imprint GPD key ID: 0xB13480A6 - 591A 30A7 36A0 CE3C 3D28 A038 E49D 7365 B134 80A6 mobile : +31 (0)6 25 20 7001 skype : cornouws blog: cor4office-nl.blogspot.com jabber : cor4off...@jabber.org -- 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] Draft text: an "attic" proposal - version 2.0
Hi Andras, Andreas Mantke wrote on 13/03/2022 16:12: the quintessence of he proposal would be that a project will at 99,9% or more wouldn't get out of the attic state inside the TDF resources. The barriers to de-attic a project and make it an active project inside TDF are much higher than setting up / starting a new project. That is true. On the other hand: is it reasonable to compare a new project with one that is in attic state? For a new project - and I think TDF will adopt projects all too swift - you create a stage so that there is a place to grow, prove oneself. When a project has been paused at some moment, that will not have been done without thinking, consideration, extra efforts to avoid etc. as well. So based on this, one not make conclusions on the current proposal by 'comparing' the cases. For me the clear demands in the proposal are to prevent a situation where projects restart without a good change on success, which is IMO quite relevant for TDF's good name. Cheers, Cor -- Cor Nouws, member Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: http://www.documentfoundation.org/imprint GPD key ID: 0xB13480A6 - 591A 30A7 36A0 CE3C 3D28 A038 E49D 7365 B134 80A6 mobile : +31 (0)6 25 20 7001 skype : cornouws blog: cor4office-nl.blogspot.com jabber : cor4off...@jabber.org -- 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] Draft text: an "attic" proposal - version 2.0
Hi Andreas, thanks for your feedback. I have to agree with you that the process seems to be too cumbersome and it would very likely lead to the end of the project, so may as well delete it, or to forks that will never come back. The point here is also to try to understand what the scope of the "attic" would be, apart from locking out LOOL as we haven't got a list of other projects that we could/should archive. During the first discussion the Android Viewer has been proposed for archival to then discover that mostly one developer (Michael Weghorn) is actually looking after it so we have a good example that some may take interest on a project if it's open for contributions. Probably before we decide to put a project in the "attic" it would be a great idea to understand which projects we are hosting and then decide what to do as the rules should be the same for all and we should avoid another LOOL situation without clear rules in place. As plenty of time has passed by since LOOL has been forked I would even propose to just re-open the repository and let the community decide if they are actually interested in contributing to it. We may discover that the community is actually interested in contributing to a LOOL which is unlikely to reach features parity with other similar products but that is good enough for some use cases where basic features and a lightweight component is needed. If a community starts forming around it then we could compile it and make it available with the relevant warning of not being commercially supported as it planned before it was forked. If within 12 months we see that there is no interest at all then we may as well tarball LOOL and make it available for download for historical reference. Ciao Paolo On 13/03/2022 16:12, Andreas Mantke wrote: Am 08.03.22 um 22:54 schrieb Emiliano Vavassori: Dear community members, Following the discussion on the first revision of the "Attic" proposal, posted here by Thorsten Behrens on December 17th, 2021, gathering the input we received from the community (thanks for the invaluable help provided by everyone who participated!) and as anticipated in the last Board meeting (yesterday, March 7th), Thorsten and I tried to condense the discussion in a new 2.0 version, which I post below for further discussion. Of course, we are available to further clarify the proposal, if needed, and we eagerly await for your input on this following version. the quintessence of he proposal would be that a project will at 99,9% or more wouldn't get out of the attic state inside the TDF resources. The barriers to de-attic a project and make it an active project inside TDF are much higher than setting up / starting a new project. You ask for at least 3 devs with a lot of very valuable commits to start the process. But in comparison with the hurdles to run a new project / idea inside TDF resources there is no balance. A lot of (software) projects starts and run with only one (or maybe two) developers. If you put the same burden on them they would never get a go from TDF. I think a lot of volunteer work for and around LibreOffice would have been running on TDF resources if you took this criteria as a basis. The proposal is the start to stop any (volunteer) initiative to revive of - temporarily - not actively developed / worked on projects. Everyone who wants to work on such a project from the attic needs to use resources outside of TDF and I expect the development will stay there (and will not moved to TDF resources later). Thus in my opinion it is contrary to TDF's mission. Regards, Andreas -- ## Free Software Advocate ## Plone add-on developer ## My blog: http://www.amantke.de/blog -- 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] [DECISION] Approve version 1.3.2 of the CoI policy
Hello, The Board of Directors at the time of voting consists of 7 seat holders (not including deputies). In order to be quorate, the vote needs to have 1/2 or more of the Board of Directors members, which gives 4. A total of 6 Board of Directors members have participated in the vote. The vote is quorate. A quorum could be reached with a simple majority of 4 votes. Florian Effenberger wrote on 04.03.22 at 13:30: as discussed in https://listarchives.tdf.io/i/nUXiQDLatIR_Od6g63A08xU3 and in the last board call, the following VOTE is proposed on the recently published draft update to the CoI policy [1], to modify our Rules of Procedure [2] - such that we reference version 1.3.2 of the CoI policy: --- Preamble In addition to § 7, (5) of the statutes, the Board of Directors hereby agrees on the following rules of procedure. Notwithstanding any regulations in the statutes, this document defines board processes, decision making, as well as sharing and delegation of board tasks. Binding part of these Rules of Procedure is the Board’s Conflict of Interest Policy: https://wiki.documentfoundation.org/images/6/6e/BoD_Conflict_of_Interest_Policy_ver1_3_2.pdf Should elements of the Rules of Procedure be in collision with the Conflict of Interest Policy, the rules of the Conflict of Interest Policy always shall prevail. --- According to § 1, 2. of said Rules of Procedure, this vote runs for one week, until March 11, 2022. After approval, the amended Rules of Procedure will be published and enter into immediate effect. [1] https://wiki.documentfoundation.org/images/6/6e/BoD_Conflict_of_Interest_Policy_ver1_3_2.pdf [2] https://wiki.documentfoundation.org/TDF/BoD_rules Result of vote: 6 approvals, 0 abstain, 0 disapprovals. One deputy supports the motion. Decision: The proposal has been accepted. Florian -- Florian Effenberger, Executive Director (Geschäftsführer) Tel: +49 30 5557992-50 | Mail: flo...@documentfoundation.org 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 -- 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