[board-discuss] Reminder: please be respectful & patient to each other! (was: ratify board communication best practices document)
Dear list, this email is a very generic reminder of how we as a board would like to communicate. It would be great, if we could also inspire everyone else on this list to follow our lead there. We strive to: - be inclusive, and patient - recognise each other as humans (with our different quirks & cultures), and don't assume we stand for our group, company, or nationality - try to resolve personal conflicts privately (if necessary by asking for moderation) - above all, we try to keep discussions focused on issues, not on persons involved. If we offend, we apologize - if we feel offended, we try to be generous - and if all else fails, we stop writing emails, and sort things out in a call Thanks a lot, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Paolo, all, Paolo Vecchi wrote: > On 27/05/2022 12:31, Thorsten Behrens wrote: > > Process-wise, my call to work out a proposal how to come to a joint > > text (in a small circle) is still open. > > I've asked many times but still no answer. Will you one day explain why you > keep wanting to have this process behind closed doors? > It was right there in one of my emails you were answering to; let me paste it: Thorsten wrote: > It is one option to make effective progress. As you state, it > appears that all people with an opinion have spoken up here; what's > now left to do, is to come up with a document, for which many (if > not all) directors can stand behind it. If community members like > Michael Weghorn or Michael Meeks would like to be part of that > working group, we should of course consider that, too. > What we ideally need, is *one* consolidated proposal. I'm grateful for Kendy taking the initiative, and starting one. > It's quite clear that there are 2 proposals now as the changes proposed > completely change the initial one. > Then lets please interact with the changes, such that we can iterate this to a single joint text. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Merged proposal for in-house developers at TDF
Hi Paolo, all, Paolo Vecchi wrote: > That document clearly contains another proposal which should go its own way > instead of trying to make it pass as a "merged" proposal. > The intention here (and I would very much like to support that idea), is to come up with a merged proposal, which then gets broad support. If there's changes you believe are problematic, please interact with them. Process-wise, my call to work out a proposal how to come to a joint text (in a small circle) is still open. Having the two sides that are apparently the furthest apart, telling each other the text is not ok for the foreseeable future - is not my idea of a working process. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Objective: Postponing Hiring TDF-Developer To 2024 or Later?
Dear list, Paolo Vecchi wrote: > He may have missed my emails but I suppose that our chairman, which is also > his direct superior at work, could have made him notice that he overlooked > some emails from a fellow member of the board. > Just to clarify - Gabor does not receive orders or instructions from me with regard to his role as a deputy director, and is free to decide on his own, according to his personal views & opinions. @Paolo: the best way to resolve issues like the one you mentioned, is to talk to the person(s) involved directly. If you like, we should always be able to find a few minutes during board calls, to get this sorted out interactively. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Proposal for in-house developers at TDF
Hi Paolo, all, Paolo Vecchi wrote: > On 25/05/2022 10:19, Thorsten Behrens wrote: > > To reiterate the question, is that something the two of you would be > > willing to collaborate on? > It seems like you missed my previous answer: > > https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00530.html > Indeed I saw your answer, but it very much sounded like a no to me (and we didn't find the time in a call yet to clarify). Since you bring it up here: > I've been willing to work together with anyone in a transparent and > public way. > So would you be ok to sit down with Kendy to work out a proposal for the _process_ of getting to a final document? > > The other option I see, is to select a small working group (board and > > perhaps community members) during the next board call, with the > > mission to synthesize a 3rd, new proposal from all input received so > > far. > > Why are you once again proposing a small group to do things behind closed > doors? > It is one option to make effective progress. As you state, it appears that all people with an opinion have spoken up here; what's now left to do, is to come up with a document, for which many (if not all) directors can stand behind it. If community members like Michael Weghorn or Michael Meeks would like to be part of that working group, we should of course consider that, too. But see above, for an alternative suggestion how we can move this forward. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Proposal for in-house developers at TDF
Hi Paolo, hi Kendy, I wrote: > Could I ask the two of you to work out a joint proposal, how to > finalize the document? > > It could be a working group or a shared, editable document, or > something else entirely - but would be great to see this finished > soonish, and with wide board support. > To reiterate the question, is that something the two of you would be willing to collaborate on? The other option I see, is to select a small working group (board and perhaps community members) during the next board call, with the mission to synthesize a 3rd, new proposal from all input received so far. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Objective: Postponing Hiring TDF-Developer To 2024 or Later?
Hi Andreas, all, Andreas Mantke wrote: > It seemed there is a approach behind this behavior: postpone the whole > topic as far as possible. And try to frustrate the members who try to > drive this topic forward. And prevent this project in the end or to vary > it that it will not disturb own interests or support them. > I don't think that's a fair conclusion of what's happening. To me, Michael Weghorn's explanation appears much closer to the truth. After all, whatever proposal will be there to vote on, needs the backing of as many board members as possible - it is therefore very important to work out a consensus. And I'm sure we can get there, if we all work together. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Hiring Targeted Developers ...
Hi Ilmari, all, Ilmari Lauhakangas wrote: > I'm thinking of what will be written in the job posting. If the > title contains "mentor" and mentoring will be central in the job > description, it will scare devs away. > Yeah, I agree that past job postings were perhaps over-specific there. The documents under discussion are our internal process- and requirement sheet. For the outbound message on job boards, we can certainly tweak the wording to be audience-specific. I could imagine putting 'senior' there would attract people who've mentored, on-boarded and levelled-up junior developers? Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Proposal for in-house developers at TDF
Hi Paolo, hi Kendy, all, Paolo Vecchi wrote: > > Hence my proposal for another approach, that can well result in a > > similar situation, but that you sadly didn't respond to for the third or > > fourth time. > > You stated that I should have answered questions, that in my opinion are > answered in page 10 and 11 of the proposal, but I haven't seen from you any > actual proposal for improvements. Could you point me to your proposals in > board-discuss just in case I missed them? > Can I repeat my request to get a small group (e.g. Paolo, Kendy as representatives of the two opposing sides here) to first agree on a workable process, to quickly iterate the proposal to something we can all support? The current approach via emails does not appear to get us closer to a final result. Thanks, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Proposal for in-house developers at TDF
Hi Paolo, hi Kendy, Jan Holesovsky wrote: > Paolo Vecchi píše v Čt 12. 05. 2022 v 14:29 +0200: > > I have received no additional constructive feedback from the board > > since > > the last published version so I assume that the proposal will be > > promptly approved as a new strategic project and the team will be > > kindly > > asked to prepare the job descriptions shortly after. > > I remember there was a Board working group to be set up to finalize the > proposal, for which I volunteered, to be able to further my feedback > there. > Could I ask the two of you to work out a joint proposal, how to finalize the document? It could be a working group or a shared, editable document, or something else entirely - but would be great to see this finished soonish, and with wide board support. Thanks a lot, -- Thorsten signature.asc Description: PGP signature
[board-discuss] Re: Question about tender proposal 'Unify Writer and Draw image'
Hi Regina, copying Armin, who did quite a bit of work in that area - Regina Henschel wrote: > you are the contact person for tender proposal > https://wiki.documentfoundation.org/Development/Budget2022#Unify_Writer_and_Draw_Images > The topic of this tender proposal is not very clear to me. Writer-images and > Draw-images have many differences. I have collected them in the document > https://wiki.documentfoundation.org/File:Comparison_WriterDraw_image.odt > Thanks, that's an excellent overview, and should IMO be a part of the requirements for a potential tender. > When working on 'Unify' it is necessary to know the final goal. It could be > A) Elimination of Writer-images. Writer uses only Draw-images same as all > other modules. > Yes, that's the intended final goal. > I understand it so, that the item 'extract Writer border rendering & frame > special code' would be a step for goal A, whereas items in regard to > 'rotated images support' would be a step for goal B. > Don't quite understand the second part - since obviously draw images can be easily rotated? But indeed there's slightly more work needed besides just the border support (e.g. contour polygons and other smallish bits and pieces from your comparison doc), to make Draw images powerful enough to support all Writer features. HTH, -- Thorsten signature.asc Description: PGP signature
[board-discuss] [DECISION] ratify board communication best practices document
Dear fellow directors, all, 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. Result of vote: 5 approvals, 1 abstain, 0 disapprovals. Additionally, three deputies support the decision. Decision: The proposal has been accepted. -- Thorsten signature.asc Description: PGP signature
[board-discuss] Re: [VOTE] ratify board communication best practices document
+1 from me. I wrote: > Dear fellow directors, > > having discussed this and incorporated your feedback, calling for a > vote, to: > > * ratify attached best practices as current board communication > guidelines > (verbatim copy from > https://nextcloud.documentfoundation.org/f/900757 as of 2022-04-12 > 1600 UTC) > > Vote runs the usual 72 hours, please answer with +1/-1/abstain to this > email. > > Thanks, > > -- Thorsten > # Best practices for board communication > > We believe that beyond common sense good manners, and the community > CoC, the TDF board bears the extra burden of leading by (excellent) > example when it comes to define interaction styles in the community. > > We therefore feel bound by the following board communication best > practices, to be used in all written board communication channels. > > Applies to: > - intra-TDF communication channels > (tdf-directors, working groups, direct emails, TDF matrix chat > rooms, MC- and staff-internal mailing lists) > - the public board-discuss email list > > ## Communication best practices we apply: > > - We are cognizant that people with whom we communicate are > located across the globe. We don't expect people to respond > immediately, they might not have the bandwidth beside their jobs > and private obligations to process all emails in a short time. > > We give them a chance to read and digest our text, form an > opinion and answer in their own time. If we find ourselves being > the only one sending a lot of messages in a short time frame, we > slow down. > - We always remember that the recipient is a human being whose > culture, language, and humor have different points of reference > from your own. We know that date formats, measurements, and > idioms may not travel well. We are especially careful with > sarcasm. > - We use smileys to indicate tone of voice, but use them > sparingly. We don't assume that the inclusion of a smiley will > make the recipient happy with what we say, or wipe out an > otherwise insulting comment. > - We wait overnight to send emotional responses to messages. No, > we don't answer immediately. > - We are brief without being overly terse. When replying to an > email, we include enough original material to be understood > but no more. It is extremely bad form to simply reply to a > message by including all the previous emails: we edit out all > the irrelevant material. Giving context helps everyone. We > delete irrelevant material and focus on what we want to comment > on. This makes for easier reading and takes up less space. > - We assume that individuals speak for themselves, and what they > say does not represent their organization (unless stated > explicitly). Conversely, we assume that while on the board, > what we write in public will certainly be attributed to TDF as > well! > - We keep messages brief and to the point. We don't wander > off-topic, don't ramble and don't send mail or post messages > solely to point out other people's errors in typing or spelling. > - If we should find ourselves in a strong disagreement with > another person, we make our responses to each other via private > messages rather than continue to send them to the list or the > group. If we are debating a point on which the group might have > some interest, we may summarize for them later. If we should > find even the private interaction hard, we ask a trusted peer > for help. > - We don't get involved in flame wars. Neither post nor respond > to incendiary material. > - We avoid "me-too" posts. It's wonderful to agree with each > other, but it's rare that pointing this out adds much to the > discussion. New information is always welcome; an echo chamber > is often less pleasant. > > In a word: we reply to messages only when we have something > substantive to contribute. "Good one, Joan" does not qualify as > substantive. > > That said, for discussions where checking support of opinions > is desirable, there should be an easy way for the _community_ to > give their feedback in a +1/-1 form, without running an official > vote. LimeSurvey or Nextcloud Polls could fit that purpose, and > in the hopefully not too distant future, Decidim can take over > that task. > - If we are caught in an argument, we keep the discussion focused > on issues rather than the personalities involved. Similarly, if > we inadvertently offend someone, we apologize quickly. > - If we feel that someone's response to one of our messages is > offensive, we take pains to reply generously rather than > defensively. "Taking the high road" will almost always diffuse > bad feelings. > - We resist taking a difference of opinion personally. Someone not > liking our position or the crazy thing we have done does not > mean that they dislike us. > - Not everybody will agree on everything. It's healthy to > recognise that differi
[board-discuss] [VOTE] ratify board communication best practices document
Dear fellow directors, having discussed this and incorporated your feedback, calling for a vote, to: * ratify attached best practices as current board communication guidelines (verbatim copy from https://nextcloud.documentfoundation.org/f/900757 as of 2022-04-12 1600 UTC) Vote runs the usual 72 hours, please answer with +1/-1/abstain to this email. Thanks, -- Thorsten # Best practices for board communication We believe that beyond common sense good manners, and the community CoC, the TDF board bears the extra burden of leading by (excellent) example when it comes to define interaction styles in the community. We therefore feel bound by the following board communication best practices, to be used in all written board communication channels. Applies to: - intra-TDF communication channels (tdf-directors, working groups, direct emails, TDF matrix chat rooms, MC- and staff-internal mailing lists) - the public board-discuss email list ## Communication best practices we apply: - We are cognizant that people with whom we communicate are located across the globe. We don't expect people to respond immediately, they might not have the bandwidth beside their jobs and private obligations to process all emails in a short time. We give them a chance to read and digest our text, form an opinion and answer in their own time. If we find ourselves being the only one sending a lot of messages in a short time frame, we slow down. - We always remember that the recipient is a human being whose culture, language, and humor have different points of reference from your own. We know that date formats, measurements, and idioms may not travel well. We are especially careful with sarcasm. - We use smileys to indicate tone of voice, but use them sparingly. We don't assume that the inclusion of a smiley will make the recipient happy with what we say, or wipe out an otherwise insulting comment. - We wait overnight to send emotional responses to messages. No, we don't answer immediately. - We are brief without being overly terse. When replying to an email, we include enough original material to be understood but no more. It is extremely bad form to simply reply to a message by including all the previous emails: we edit out all the irrelevant material. Giving context helps everyone. We delete irrelevant material and focus on what we want to comment on. This makes for easier reading and takes up less space. - We assume that individuals speak for themselves, and what they say does not represent their organization (unless stated explicitly). Conversely, we assume that while on the board, what we write in public will certainly be attributed to TDF as well! - We keep messages brief and to the point. We don't wander off-topic, don't ramble and don't send mail or post messages solely to point out other people's errors in typing or spelling. - If we should find ourselves in a strong disagreement with another person, we make our responses to each other via private messages rather than continue to send them to the list or the group. If we are debating a point on which the group might have some interest, we may summarize for them later. If we should find even the private interaction hard, we ask a trusted peer for help. - We don't get involved in flame wars. Neither post nor respond to incendiary material. - We avoid "me-too" posts. It's wonderful to agree with each other, but it's rare that pointing this out adds much to the discussion. New information is always welcome; an echo chamber is often less pleasant. In a word: we reply to messages only when we have something substantive to contribute. "Good one, Joan" does not qualify as substantive. That said, for discussions where checking support of opinions is desirable, there should be an easy way for the _community_ to give their feedback in a +1/-1 form, without running an official vote. LimeSurvey or Nextcloud Polls could fit that purpose, and in the hopefully not too distant future, Decidim can take over that task. - If we are caught in an argument, we keep the discussion focused on issues rather than the personalities involved. Similarly, if we inadvertently offend someone, we apologize quickly. - If we feel that someone's response to one of our messages is offensive, we take pains to reply generously rather than defensively. "Taking the high road" will almost always diffuse bad feelings. - We resist taking a difference of opinion personally. Someone not liking our position or the crazy thing we have done does not mean that they dislike us. - Not everybody will agree on everything. It's healthy to recognise that differing views can't always be reconciled. Often, we have to accept that someone else thinks differently and move on. If a particular list or topic is constantly leaving us irritable because of these kinds of issues, the message is
end-thread please (was: [board-discuss] [VOTE] approval of preliminary budget for 2022)
Hi Andreas, changing the subject, and the request to please move this tangential discussion at least into a separate thread. Andreas Mantke wrote: > Most things are usual in the most developed countries and logical by > good judgement. > That's not an appropriate comment. Our community calls from all parts of this world, and we should be welcoming instead of patronizing. Let's end-thread here. Thanks, Thorsten -- Thorsten Behrens, Director, Member of the Board The Document Foundation, Kurfürstendamm 188, 10707 Berlin, Germany Rechtsfähige Stiftung des bürgerlichen Rechts Legal details: http://www.documentfoundation.org/imprint signature.asc Description: PGP signature
Re: [board-discuss] Board process proposal feedback wrt. calendaring
Hi Florian, Florian Effenberger wrote: > Mike Saunders maintains an events calendar. This is embedded in the wiki on > https://wiki.documentfoundation.org/Events and directly accessible via > https://nextcloud.documentfoundation.org/apps/calendar/embed/WPAQ2UTYAJPRW84U/dayGridMonth/now > Is there a good way for members (who have a nextcloud account) to subscribe to that? The standard export url webcal://nextcloud.documentfoundation.org/remote.php/dav/public-calendars/WPAQ2UTYAJPRW84U/?export leads to slightly suboptimal results (at least here). Thanks a lot, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] [DECISION] Approve the attic proposal
Hi Daniel, all, Daniel A. Rodriguez wrote: > This all goes hand in hand with the refusal to hire developers within TDF. > I don't see where that should have happened. See also Paolo's answer. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Preliminary budget for 2022
Hi Simon, all, Simon Phipps wrote: > Can you tell is the voting details please? > The vote on the budget was unanimous, among the board members present. Best, -- Thorsten signature.asc Description: PGP signature
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] Translation as part of the attic policy
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 signature.asc Description: PGP signature
Re: [board-discuss] [VOTE] Approve the attic proposal
Hi Paolo, Paolo Vecchi wrote: > Abstaining from voting on it as while the text could be a starting point it > seems to make it clear that whatever goes in the "attic" will never come out > of it as explained very well by Andreas Mantke: > > https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00373.html > I've just answered Andreas, and I believe he's not describing a real-world problem, for actual developers of the kind of code hosted at TDF. Andreas has used github before, with forked repos from TDF's main ones, and gihub issues for bug tracking. It really does not seem to be a barrier. > Before anything is put in the "attic" we should make an analysis of what we > are hosting, open repositories for 12 months (if they have been frozen) and > promote them to see if anyone starts contributing and then, after the 12 > months period has expired, evaluate if the repositories should be archived > for good. > We should look at each request to atticize on its own merits. The vote on the process has just passed (it's the ESC's and the board's job to propose projects). An aside: let's please continue the discussion with a separate subject if there's a need; but ideally as a new thread. the vote here has concluded. Cheers, -- Thorsten signature.asc Description: PGP signature
[board-discuss] Further questions on the attic proposal (was: [VOTE] Approve the attic proposal)
Hi Andreas, all, let me address your questions as how I can summarise the intentions & discussions we've had, over the past months. Other board members can chime in and explain their take. Andreas Mantke wrote: > Thus it is not possible to make a contribution or a potential > contribution for such a project within TDF resources. > Not while the project is in the attic, no. That is the entire point for an attic - communicate to the world out there, that currently at least, this very project is not actively developed at TDF. The Readme as suggested in the proposal text gives some concrete ways how to get it out of there though! > Because it is not possible to make a pull request or to work on a branch > of the attic project on TDF resources, the work on that project has to > be done somewhere else. > Yes. Unmaintained projects are a risk to have in a software supply chain, so experiments to re-vitalise should happen on the side. If then still someone uses that in production, at least TDF is not the upstream source for it. > 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. > 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. > 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). For developers willing to revive a project, finding a place to host a repo is trivial. Doing the development work and getting up to speed in large code bases, is where the challenges lie. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] [VOTE] Approve the attic proposal
Hi Andreas, all, Andreas Mantke wrote: > Am 24.03.22 um 00:20 schrieb Thorsten Behrens: > > • Any repositories inside it will be made “read only”, so no “push” or > >“pull request” mechanisms will be available: this allows changes to > >the code to be shared as it was the last time it was “atticisized”; > > I'm curious why there is not only push function is disabled but also > pull function. Does this mean that there is no 'git clone' available too? > That seems to be a misunderstanding. A "pull request" in git(hub) lingo means asking an upstream git project to merge a change. A readonly clone is going to be available for atticized projects. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] [VOTE] Approve the attic proposal
I vote +1. I wrote: > Dear directors, > > calling for an email VOTE on the below final version of the Attic > Proposal. The vote runs for 72 hours, starting now. > > Changes since v2.1: > * corrected mistakes found during Monday board call > * light touch-ups for English > * aligned the readme text suggestions with the changes in the prose > above > > Best, Thorsten > > -%<-- > > ## Introduction > > It can happen, within a huge project like LibreOffice, that parts > of the project worked on by the community will become obsolete or > superseded by other projects. The following proposal will deal > with the need to let the code (and/or other forms of text related > to the code) be publicly available, while setting the correct > expectations around its availability, suitability for a > production environment, quality and security. > > ## What is the “attic”? > > 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. This will help to set the correct > expectations on its development status, while not losing its > fundamental trait of being open source (so its code must be > publicly available). > > In the present proposal, the “attic” would be a single host > inside TDF's infrastructure, available via HTTP/HTTPS protocols, > responding to a URI similar to: > https://attic.documentfoundation.org > > ## Specificity of the “attic” > > This “attic” space will have, at a minimum, the following characteristics: > > • It is supported by Git – the well known VCS developed initially by > Linus Torvalds and used to share the sources of the Linux > kernel. Being supported by Git will ease forking of the code > contained there; > > • Any repositories inside it will be made “read only”, so no “push” or > “pull request” mechanisms will be available: this allows changes to > the code to be shared as it was the last time it was “atticisized”; > > • Anonymous access to the repositories has to be made the default > access method: we want code present in the “attic” to be always > available to everyone; > > • It should have a recognizable URL – or internet address, less > technically: this allows for the code present to be clearly > separated by other actively-developed code; > > • A specific text explaining the nature of the code, its > “deatticization” requirements and how to get support for the code > inside the repository needs to be present in the README of every > repository. The text of these disclaimers and the deatticization > requirements will be discussed further on in the proposal. Regarding > contacts to get support, the idea is to provide quick and ready > information on who/where to ask for anything related to the code in > the repository. > > The proposed implementation of this space is by using git-http-backend [1]. > The proposal has already been evaluated by the infrastructure team, and > the overhead for maintaining such a solution will be “negligible”. > > ## Considerations about the approval procedure for atticization/deatticization > > As per the Statutes of the Foundation, the Board of Directors (BoD) should > be the ultimate decision-making body of the Foundation; thus it has > technically the last word on the approval or the refusal of an > atticization/deatticization proposal. > > If we analyse the matter at hand, we recognize that there is another codified > body inside TDF that is directly composed by the technical part of the > community and, as such, should have more insights and knowledge on the parts > of the project that are proposed to be atticized/deatticized; that body is > the Engineering Steering Committee (ESC). > > As such, a common and shared understanding of the political and technical > impacts of the atticization/deatticization proposal has to be reached by the > two bodies, all together, and this understanding should be condensed into a > unique, unambiguous preference towards approval or disapproval. > > The leanest approval process would then be: the ESC expresses its > preference, and the BoD agrees with the ESC. The proposal is then officially > accepted or refused by the BoD, according to the preference expressed. > > If this doesn't happen, a shared discussion in a public meeting with the > members of both bodies is highly recommended; the goal of such > consultations would be to understand and underline weaknesses and threats of > the proposal, and eventually to get to a unique preference. > > Whatever the means of the consultations are, and if there is no clear > preference for an outcome, but the BoD is called to decide anyway, it has to > provide an official written report on the merits of the decisions, the > decisions taken, and a mitigation plan for the hard blockers identified > during the discussion. > > ## Atticization process > > The Eng
[board-discuss] [VOTE] Approve the attic proposal
Dear directors, calling for an email VOTE on the below final version of the Attic Proposal. The vote runs for 72 hours, starting now. Changes since v2.1: * corrected mistakes found during Monday board call * light touch-ups for English * aligned the readme text suggestions with the changes in the prose above Best, Thorsten -%<-- ## Introduction It can happen, within a huge project like LibreOffice, that parts of the project worked on by the community will become obsolete or superseded by other projects. The following proposal will deal with the need to let the code (and/or other forms of text related to the code) be publicly available, while setting the correct expectations around its availability, suitability for a production environment, quality and security. ## What is the “attic”? 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. This will help to set the correct expectations on its development status, while not losing its fundamental trait of being open source (so its code must be publicly available). In the present proposal, the “attic” would be a single host inside TDF's infrastructure, available via HTTP/HTTPS protocols, responding to a URI similar to: https://attic.documentfoundation.org ## Specificity of the “attic” This “attic” space will have, at a minimum, the following characteristics: • It is supported by Git – the well known VCS developed initially by Linus Torvalds and used to share the sources of the Linux kernel. Being supported by Git will ease forking of the code contained there; • Any repositories inside it will be made “read only”, so no “push” or “pull request” mechanisms will be available: this allows changes to the code to be shared as it was the last time it was “atticisized”; • Anonymous access to the repositories has to be made the default access method: we want code present in the “attic” to be always available to everyone; • It should have a recognizable URL – or internet address, less technically: this allows for the code present to be clearly separated by other actively-developed code; • A specific text explaining the nature of the code, its “deatticization” requirements and how to get support for the code inside the repository needs to be present in the README of every repository. The text of these disclaimers and the deatticization requirements will be discussed further on in the proposal. Regarding contacts to get support, the idea is to provide quick and ready information on who/where to ask for anything related to the code in the repository. The proposed implementation of this space is by using git-http-backend [1]. The proposal has already been evaluated by the infrastructure team, and the overhead for maintaining such a solution will be “negligible”. ## Considerations about the approval procedure for atticization/deatticization As per the Statutes of the Foundation, the Board of Directors (BoD) should be the ultimate decision-making body of the Foundation; thus it has technically the last word on the approval or the refusal of an atticization/deatticization proposal. If we analyse the matter at hand, we recognize that there is another codified body inside TDF that is directly composed by the technical part of the community and, as such, should have more insights and knowledge on the parts of the project that are proposed to be atticized/deatticized; that body is the Engineering Steering Committee (ESC). As such, a common and shared understanding of the political and technical impacts of the atticization/deatticization proposal has to be reached by the two bodies, all together, and this understanding should be condensed into a unique, unambiguous preference towards approval or disapproval. The leanest approval process would then be: the ESC expresses its preference, and the BoD agrees with the ESC. The proposal is then officially accepted or refused by the BoD, according to the preference expressed. If this doesn't happen, a shared discussion in a public meeting with the members of both bodies is highly recommended; the goal of such consultations would be to understand and underline weaknesses and threats of the proposal, and eventually to get to a unique preference. Whatever the means of the consultations are, and if there is no clear preference for an outcome, but the BoD is called to decide anyway, it has to provide an official written report on the merits of the decisions, the decisions taken, and a mitigation plan for the hard blockers identified during the discussion. ## Atticization process The Engineering Steering Committee (ESC) of TDF, the Board of Directors (BoD) or one or more of its Directors can propose the “atticization” of a part of the project. That proposal will have to be voted on successfully by both the ESC and the Boa
[board-discuss] Final text: an "attic" proposal - version 2.1
Dear community, I've rolled all suggestions into this (near?) final version. I believe we're ready to vote on this now. Changes to v2.0: * added a half-sentence to clarify that the developers of the forked attic repo would need to want it back as active at TDF * rolled Caolan's small/medium/large project idea into both atticisation and de-atticisation text Cheers, Thorsten -%<-- ## Introduction It can happen, with a huge project like LibreOffice, that parts of the project worked on by the community will become obsolete or superseded by other projects. The following proposal will cope with the need to let the code (and/or other form of text related to the code) to be publicly available, while setting the correct expectations around its availability, suitability for a production environment, quality and security. ## What is the “attic”? The “attic” is a special area of TDF infrastructure where part of the code/documentation/translations can be parked, that is not anymore actively developed. This will help setting the correct expectations on its status of development, while not losing its fundamental trait of being open source (so its code must be publicly available). In the present proposal, the “attic” would be a single host inside TDF infrastructure, available in HTTP/HTTPS protocols, responding to a URI similar to: https://attic.documentfoundation.org ## Specificity of the “attic” This “attic” space will have, at minimum, the following characteristics: • It is supported by git – the well known CVS developed by Linus Torvalds initally and used to share the sources of the Linux kernel. Being supported by git will ease the forking of the code contained there; • Any repositories inside it will be made “read only”, so no “push” or “pull request” mechanisms will be available: this allows changes to the code to be shared as it was the last time it was “atticisized”; • Anonymous access to the repositories has to be made the default access method: we want the code present in the “attic” to be always available to everyone; • It should have a recognizable URL – or Internet address, less technically: this allows for the code present to be clearly separated by other actively developed code; • A specific text explaining the nature of the code, its “deatticization” requirements and how to get support on the code inside the repository needs to be present in the README of every repository. The text of these disclaimer and the deatticization requirements will be discussed further on in the proposal. Regarding contacts to get support, the idea is to provide quick and ready information on who/where to ask for anything related to the code in the repository. The proposed implementation of this space is by using git-http-backend [1]. The proposal has already been evaluated by the Infra team and the overhead for maintaining such a solution will be “negligible”. ## Considerations about the approval procedure for atticization/deatticization As per the Statutes of the Foundation, the Board of Directors (BoD) should be the ultimate decision-making body of the Foundation; thus it has technically the last word on the approval or the refusal of an atticization/deatticization proposal. If we analyse the matter at hand, we recognize there is another codified body inside TDF that is directly composed by the technical part of the community and, as such, should have more insights and knowledge on the parts of the project that are proposed to be atticized/deatticized; that body is the Engineering Steering Committee (ESC). As such, a common and shared understanding of the political and technical impacts of the atticization/deatticization proposal has to be reached by the two bodies all together, and this understanding should be condensed in a unique, unambiguous preference towards approval or disapproval. The leanest approval process would then be that the ESC expresses its preference and the BoD agrees with the ESC. The proposal is then officially accepted or refused by the BoD, according to the preference expressed. If this doesn't happen, a shared discussion in a public meeting with the components of both bodies is highly recommended; the goal of such consultations would be to understand and underline weaknesses and threats of the proposal, and eventually to get to a unique preference. Whatever the means of the consultations are and if there is no clear preference as outcome, but the BoD is called anyways to decide, it has to provide an official written report on the merits of the decisions, the decisions taken, and a mitigation plan for the hard blockers identified during the discussion. ## Atticization process The Engineering Steering Committee (ESC) of TDF, the Board of Directors (BoD) or one or more of its Directors can propose the “atticization” of a part of the project. That proposal will have to be voted
Re: [board-discuss] Draft text: an "attic" proposal - version 2.0
Hi Kendy, hi Paolo, a gentle reminder to please keep this discussion on-topic. There's a new proposal to address Andreas' initial concern. Please interact with that, instead of discussing a rather tangential & hypothetical topic. Thanks, -- Thorsten signature.asc Description: PGP signature
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] [VOTE] Approve version 1.3.2 of the CoI policy
Approve. Florian Effenberger wrote: > Dear board, > > 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 > > 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 > signature.asc Description: PGP signature
[board-discuss] Representation statement
I, Thorsten Behrens, elected member of the Board of Directors of The Document Foundation, hereby and until further notice, nominate the following deputies to represent me during board calls and meetings, in the order set forth below: 1. Gábor Kelemen 2. Ayhan Yalçınsoy 3. Gabriel Masei Best, Thorsten -- Thorsten Behrens, Director, Member of the Board The Document Foundation, Kurfürstendamm 188, 10707 Berlin, Germany Rechtsfähige Stiftung des bürgerlichen Rechts Legal details: http://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] Advisory Board Membership of Rubitech-Astra
Hi Andreas, thx a lot for bringing this up. Andreas Mantke wrote: > In my view TDF should reconsider the membership of Rubitech-Astra after > breach of international law by Russia and the attack against the Ukraine. > The board has just decided to suspend the AB membership. Best, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Re: Draft document for TDF in-house developers proposal
Hi *, 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. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] [DISCUSS] Proposed update for the CoI Policy: version 1.3.2
Hi Paolo, Paolo Vecchi wrote: > I believe no one in the current board has any problem with it or > wouldn't have ran for a board position. > That is in direct contradiction to my statement up-thread. So what follows is not a workable proposal. But let's hear what the rest of the board thinks. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] [DISCUSS] Proposed update for the CoI Policy: version 1.3.2
Hi Paolo, Paolo Vecchi wrote: > > Modifications are in sections 5.1 and 6.3. The changes were discussed > > in the legal group, and drafted by Mike. > > I had a look at my emails and the only reference I found about the changes > in the CoI by a member of the legal oversight team (me) said that the > changes in 6.3 were OK, but nothing about 5.1, and that as suggested by our > legal counsel we will use 1.3.2 as base for eventual future versions. > Can you point out where my initial statement was wrong? > Could you point me to emails from other members of the legal > oversight team stating that 1.3.2 was ready and accepted for > adoption? > Right now, the draft is up for discussion. The changes where discussed last year, but then elections and the Xmas break delayed matters. The change, as stated, was drafted by Mike, as part of the ongoing improvements and careful balancing work we did end of last year. Your email from Wed, 19 Jan 2022 16:47:58 (in that internal conversation) did not object to that modification. > Many called for unanimous consent for adoption of the CoI Policy so > I believe there should be also unanimous consent for changes to be > published and then adopted IMHO. > The initial, very controversial 1st version of the policy was anything but unanimously agreed on. So that is a very one-sided argument. How do you suggest we move this forward then? The current state of the policy is still considered not ok for some. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Decidim startup proposal
Hi Simon, Simon Phipps wrote: > So I still think it would be worth asking around to see if there is > another open source community using Decidim/Consul/LiquidFeedback in > their governance who can share their experiences. I can do that if > you want or there are others here who participate in the Open Source > Foundations mailing list who could do so. > Not speaking for Emiliano, but I would very much appreciate you trying to make those connections. TIA! I know Bjoern (in Cc) had some first-hand experience at least with LiquidFeedback, so perhaps he can also provide input. Cheers, -- Thorsten signature.asc Description: PGP signature
[board-discuss] Consolidated proposal needed (was: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs)
Hi *, looking at this thread, we start to run in circles. My understanding was, that Paolo volunteered to write-up a more detailed proposal, including goals (short-term and possibly long-term). I agree with several other directors (current and upcoming) that this would be very useful to have, to base a decision on. So lets wait for that document; in this sub-thread there was no new arguments in a while. I suggest we retire it. A few quick comments, no need to discuss further: Paolo Vecchi wrote: > On 16/02/2022 09:52, Jan Holesovsky wrote: > > The difference is that we already have a mentor (actually several > > mentors in several areas), while you suggest a strategic decision - > > We recently employed only 1 mentor. > No one else has been employed in that specific role. > TDF employed, and still employs, several mentors in various roles & overlapping responsibilities (including development). Those were, if my memory serves me well, unanimously wanted. > It would be great if members of the board of directors, with their > TDF hat on, would explain clearly why they seem to be opposed to > employing in-house developers. > The opposition seems to be about the process, and about putting the means before the end. There was BTW a constructive side-thread with some thoughts on how/where a salaried developer at TDF could be beneficial, with contributions from all sides of the aisle. Best, -- Thorsten signature.asc Description: PGP signature
[board-discuss] [DISCUSS] Proposed update for the CoI Policy: version 1.3.2
Dear board (current & new), *, there's another update to the board CoI policy now in draft status, I've uploaded it with enabled change tracking here: https://wiki.documentfoundation.org/images/e/e5/BoD_Conflict_of_Interest_Policy_ver1_3_2_draft_2022-02-15.pdf Modifications are in sections 5.1 and 6.3. The changes were discussed in the legal group, and drafted by Mike. I propose a brief discussion here (in case there's a need) and would subsequently then ask the new board if they would want to adopt it as the working policy on our first, inaugural board call. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Mike, all, Mike Saunders wrote: > So I don't know what the solution is, but as someone who's monitoring our > social media channels, Reddit and other things every day, I see a huge > number of feature requests. Many end up on Bugzilla as enhancement requests > too, of course. > Thx for that background & the link to Ilmari's writeup. It's clearly something we've pondered from the very early days on; the latest reasonably concrete plan around hosting our own bounty/crowdfunding platform was running this inside the planned business entity. Since bugfixing tends to be expensive, the proposal back then was to 'match' community funding with proceeds from e.g. app store sales; thus effectively steering money towards what users would prominently want (and also be willing to chip-in money for). Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Re: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi *, Cor Nouws wrote: > Paolo Vecchi wrote on 15/02/2022 12:47: > > > Now that we know we want in-house developers, the team and the ... > > It is recognized that in-house developers (...) may be a (partial) solution > some of the issues we face. > Yeah it is a bit annoying, having to repeatedly state this is an ongoing process. From the board call minutes just posted: + Proposal: discuss more, decide with strategy workshop? (Lothar) + could be interesting (Paolo) + a consensus from one side brilliant idea to have it + other side seems like its a better idea for the ecosystem to do that A "consensus from one side" is not a consensus, and not a decision. Currently, both the old and the new board are ranking all budget proposals. We will see what comes out top, if there's budget for it, and how the board & TDF can then execute on those items we want to do. And to conclude: the easiest way to convince me (and likely others) on the board that a proposal is a good idea - is to make your case properly with a well-researched writeup. Repeatedly claiming that all is clear, and why haven't we hired yet - is not convincing, to say the least. Cheers, -- Thorsten signature.asc Description: PGP signature
[board-discuss] Separating users/community/contribution? (was: Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs)
Hi Michael, [reordered for the sake of a linear argument] Michael Weghorn wrote: > and I remember that the importance of users was emphasized at some in-person > event I attended (probably Akademy) as well. > And I would agree. A user-facing project (opensource or not) that doesn't care about users in the aggregate is probably doing something wrong. > Just to mention it, the KDE Code of Conduct contains this: > > > Our community is made up of several groups of individuals and > > organizations which can roughly be divided into two groups: > > > > * Contributors, or those who add value to the project through > > improving KDE software and its services > > * Users, or those who add value to the project through their > > support as consumers of KDE software > I'm not sure KDE would have a fundamentally different view here, but happy to have that conversation & perhaps hear new, fresh perspectives. For a code of conduct, it makes of course sense to include users (conduct is about interactions), so if contributors interact with users, ground rules of kind behaviour should apply. To clarify what I mean (and why I think KDE's take is not so different), the KDE manifesto [1] has this: * End-User Focus to ensure our work is useful to all people I'm perfectly in-line with that mission statement, as a guiding principle. But I would not turn down a contribution because it doesn't meet that standard yet (and instead try mentoring and other ways to improve it over time). I would, though, dismiss user requests that don't meet community norms, and not bother mentoring everyone until they understand. For perspective: it is not a scalable task to care for 200 million users individually. It is though a priority for me (and I hope achievable), to care for all our contributors, individually. Thus, mentoring existing, and attracting new contributors will always have a higher priority to me, than fixing end-user bugs (with project resources). Of course, there's nuance. The areas you and others have mentioned, that would need special attention, are worth tackling. > Of course, one could try to make a distinction between users that > contribute something back and those who do not, but I don't know > whether that would be particularly helpful, or even easy. (E.g. is > a user that only uses the software for themselves not part of the > community, but one who recommends it to others is, because they > "spread the word"? - And maybe one of those starts getting active in > some "official" area in the LibreOffice project, or migrates their > company from a proprietary office suite to an LTS version from an > ecosystem company,...) > Perhaps it's a different meaning I ascribe to the term 'user' in this discussion. The moment someone starts contributing to the project, this person becomes a contributor to me (in contrast to a mere anonymous user). Let's gloss over grey areas, as in, when does a contribution start to 'count' - I think it doesn't matter for this discussion (and surely there's different yardsticks anyway for that, between TDF sub-projects considering someone to have merit, over to how the MC evaluates contribution). So yes, from your list, it would be a distinction to me. [1] https://manifesto.kde.org/ Best, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi *, with the lively discussion ensuing here, it is perhaps worth sharing my position ahead of the board call tomorrow: Paolo Vecchi wrote: > Enable TDF to contribute more code to LibreOffice with in-house developers > to address our donors specific needs > I think it is worth considering, whether TDF should employ dedicated developers. I'm not in general against it. It is putting the cart in front of the horse though, to start with: * we want TDF to contribute more code to LibreOffice and then follow with * therefore we must employ two developers I believe it is more productive to start thinking about what we want to achieve, in order to fulfill our mission. It is therefore encouraging to read some good thoughts about that (RTL/CTL, a11y, and other under-developed areas with little ecosystem contributions). The board can then ponder what is the best way to achieve those goals, relative to other demands. It is possible, but by no means certain, that actually hiring specialised staff is indeed the most economic way forward (e.g. for an area like a11y). It should be noted though, also to manage expectations, that mastering even a small area in LibreOffice takes many years to learn. So hiring for a role has long-term implications then on which kind of tasks, features or bugfixes can be done in-house. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Paolo, Paolo Vecchi wrote: > I was actually disagreeing with a statement saying that users are not part > of the community. > Then we have to agree to disagree. Sole users (i.e. without contributing anything to the community) are to my mind never part of a FLOSS project community. The rest of your answer are mostly unproductive jabs at various people, that I refuse to interact with. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi Olivier, Olivier Hallot wrote: > Other users express their happiness translating, adding linguistic stuff, > documenting and building culture in askbot, telegram channels and regional > meetings. > I would consider those users contributors. > I wonder who is actually listening to users. > I believe many of us do? It's just that in case of conflicting requirements, I would (almost) always prioritize contributors' needs over (non-contributing) user requests. That also creates incentives, for users to become contributors. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
Hi *, Paolo Vecchi wrote: > On 09/02/2022 15:57, Jan Holesovsky wrote: > > It is important to understand that "community" means "contributors"; as > > opposed to "users". "Users" are not part of the "community", until > > they start contributing; via code, QA, translations, marketing under > > the TDF umbrella, etc. > > I'm sorry but I have to strongly disagree with your statement. > In fact Paolo wasn't disagreeing so much, just stressed that users should be encouraged to become contributors. That's indeed a very important, and perhaps an under-used approach to increase overall contributions in the project! On the statement per se, that we (as in, TDF, and its board in particular) predominantly need to care and listen to our contributors, I would believe there's hardly any disagreement in the community. > I think that, as part of the on-boarding process, we should include a > session hosted by Florian and Mike Schinagl that clarifies to all why TDF > has been created, what its role is and what we should all keep in mind while > performing our duties as members of the board. > While it is important for the new board to know what TDF can, and cannot do (and in fact Paolo will find an email in his inbox, where Florian is announcing exactly such an onboarding), the role of the board is the opposite - to lead, within the limits of the charitable laws, where the community needs us to go. Looking at the reasons why TDF was started almost 12 years ago shouldn't be the sole guiding principle. Living in the past is not a good board strategy. I'll not comment on the quotes out of a press article, shown without much context and lacking a link to the original source (which would be good practice). The article (https://www.theregister.com/2020/07/16/libreoffice_ecosystem_beyond_utterly_broken/) was written in the context of the LOOL and MarComm plan discussions, and the fallout around the LibreOffice Personal / LibreOffice Community arguments. I recommend reading it in full. Finally, on the apparent contradiction between what Andreas (lawyer, TDF founder, long-term board member) and Paolo state on what TDF is permitted to do: this is part of an ongoing discussion with various experts. I would much prefer not discussing difficult legal matters on a public list. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs
sophi wrote: > > Do you have any insight into why the community has not chosen to fix the > > issue please? > > Reading through the bug (which was only an example) and other contributions, > I don't think we can say that the community has not chosen to fix their > issues. > Wasn't that meant to be tendered? Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Counterproposal to the "actization" of LibreOffice Online
Paolo Vecchi wrote: > > The evolving consensus in the board it > > seems (though of course I cannot speak for them), is that TDF should > > for the moment close the chapter of LibreOffice Online. > > More than a consensus I believe that we may have to resign to the fact that > we may have been left with not many options unless other members of the > board and the community come up with some practical options. > Which seems to be essentially the same conclusion. Let's end this thread here. If there's new ideas, or new, constructive input on Marco's proposal, that is of course welcome (ideally as a new thread, or as answers to the original email). Best, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Counterproposal to the "actization" of LibreOffice Online
Hi Marco, it's unclear if we're talking past each other - Marco Marinello wrote: > it's of course legit to ask people contributing here to comply with the > ML netiquette but I don't think closing the thread here is the solution. > This part of the thread is a conversation about the past, and as such has served its purpose. > In my opening message sent on January 9th I made a proposal consisting > of four points as an alternative approach to the current online > situation and although the ML is named "board-discuss", nobody from the > board commented on the merit of the proposal. > There were board people answering, I counted two immediate follow-ups: Paolo: msg-id a2501c6d-5ed1-49bb-ebef-1e5a56cb6...@documentfoundation.org Michael: msg-id b44f7c5d-968d-0904-703a-e0a03b18f...@collabora.com Plus a handful of good thoughts from community members, in the rather massive side-thread that evolved from there. > I'm geniunally interested in the opinion of who's currently driving the > foundation and I don't understand why you, Thorsten, as current and > future board member, are certainly following the thread but only asking > to close it, instead of giving your contribution. So please, as for > other board members, go back to my first mail here and reply to that. > Not directly answering on a controversial proposal, that is triggering quite emotional reactions, and has resulted in one of the longer navel-gazing & history re-telling threads of the recent past - is sometimes what is needed to not fuel the flames. I also had nothing substantial to add, beyond the two existing answers. I understand you frustrations & your motives, but I mostly agree with Paolo: claiming Collabora Online is still TDF's, and then distributing free binaries of it (which was the trigger for Collabora to leave in the first place) - is quite a hostile move. It would also be beyond tricky for TDF to message that to the general (FLOSS-affine) public. There are aspects of your proposal that are really good ideas though, c.f. the comments Simon made. The evolving consensus in the board it seems (though of course I cannot speak for them), is that TDF should for the moment close the chapter of LibreOffice Online. All the best, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Counterproposal to the "actization" of LibreOffice Online
Hi Paolo, Paolo Vecchi wrote: > In regard to your questions: > [references to earlier emails] > I'll follow up on the board list also with the proposal to look more > in detail at what we host and status and future of the Android > Viewer. > Thanks. So let's end-thread here. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Counterproposal to the "actization" of LibreOffice Online
Hi Andreas, hi Paolo, this thread has been going on for some time, and the subject is still "Counterproposal to the 'actization' of LibreOffice Online" I don't find any new input for that discussion. All points have been made already, most of them repeatedly. The irony of someone on the board at the time complaining that the board at the time made a mistake is not lost on me. So can we now finally turn this into something constructive? That would be, among other things: - concrete proposals what TDF should (or should not) do for future projects - fundamentally new or different ideas on how to deal with stale projects Everything else is badly off-topic on this thread (and very likely even on this list). For general discussions, please do move that over to our disc...@documentfoundation.org list. Cheers, Thorsten -- Thorsten Behrens, Director, Member of the Board The Document Foundation, Kurfürstendamm 188, 10707 Berlin, Germany Rechtsfähige Stiftung des bürgerlichen Rechts Legal details: http://www.documentfoundation.org/imprint signature.asc Description: PGP signature
Re: End-thread or divert into a call (was: [board-discuss] Counterproposal to the "actization" of LibreOffice Online)
Hi Marco, Marco Marinello wrote: > No. I started a new thread, as requested, not to be confused with *your* > thread regarding the actization proposal. > Indeed, sorry for the imprecise wording. Counter-proposal discussion here. ;) Cheers, -- Thorsten signature.asc Description: PGP signature
End-thread or divert into a call (was: [board-discuss] Counterproposal to the "actization" of LibreOffice Online)
Hi *, discussions that don't make progress towards agreement are a waste of everyone's time. If this is about personal gripes, the best way to sort things out is a phone or video call. Otherwise, let's please circle back to the topic at hand (atticisation of LibreOffice Online, and what to do about it - arguing over past events ain't gonna get us anywhere here). Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Counterproposal to the "actization" of LibreOffice Online
Hi Marco, Marco Marinello wrote: > I hope source-only projects will not happen again. > In fact, if you just count by the number of projects, almost all code that is hosted at TDF is source-only. There's a lot to discover and weigh here, and it's a challenge (in the wider context) that the entire FLOSS universe is struggling with since a number of years. I don't think we'll be able to solve that conundrum anytime soon. So again, I suggest we focus, and solve questions one by one. Next up is the general attic proposal. Let's move on with that. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Counterproposal to the "actization" of LibreOffice Online
Let's now stop this infighting. Nothing good will come from it. In particular: this is a public list, so let me remind everyone that our statutes suggest, and our code of conduct mandates: - that we behave respectfully towards all others, including those that are different or think differently from yourself - be helpful, considerate, friendly and respectful towards all other participants - we don't condone harassment or offensive behaviour Thank you all for considering, and let's move on! Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Charitable activities during the pandemic (was: Counterproposal to the "actization" of LibreOffice Online)
Hi Sophie, sophi wrote: > - partnering with CHATONS (or whoever) to offer LOOL instances when > teachers was in cruel lack of such resources > That's the one thing that probably would have been pretty contested, would we have done it - > - put a dedicated prominent help channel for things like PDF forms, how > to install LO on various tablets, Chromebook, phone (I know several > pupils doing their homework on phones during lockdown) > - approach other communities to put resources in common > - we know how to work on a remote mode, we could shared our knowledge > - what was the most lacking were collaborative tools like etherpad, > jitsi, etc. that we could have propose to some selected schools for example > Those are all great ideas. From where I stand, no reason at all why we shouldn't have done them. My recollection (from the board perspective) was indeed that we were up til our necks in internal debates (TDC, then followed by LOOL), with very little energy left for other bits. But is it necessary that all initiatives need to originate at the board? Many of the suggestions I think would be valuable even today, so why not start one or more? And more generically speaking, it would be great if the new board would both be more open (in where work and discussions take place), and also able to form smaller, more effective working groups. Such that we can further the many things we've left unfinished. I would personally love to draw from motivated community members - the board can certainly setup ad-hoc working groups, staffed with whoever cares & has time to work on specific topics. > I'm sure others have also a lot of ideas on what could have been > done by us as a community. > Is that something that perhaps further surveys could bring to light? I personally loved that initiative from the MC; one of the examples where good stuff happens on the foundation level, that is not originating from the board. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Looking forward, not backwards
Hi *, my first email with that subject wasn't really meant to start a discussion, but make a statement. I'll not debate individual points (or answer further in this thread); in the end we can agree to disagree (as long as we manage to pull together & towards shared goals). It is therefore encouraging to see that almost all participants on this collection of threads are trying to pull things together, and either try to convey wisdom and vision, or finding middle ground. Sadly, there's some divisiveness injected repeatedly. This has to stop, for the benefit of this project & its community. It is patently untrue that the board did everything right, and some hostile external forces were screwing us over. This is from the standard populist playbook, and I've had enough of it. We've all made mistakes, and mis-calculated (sometimes badly) here or there. Let's move on. Two things need a dedicated answer: First: > I would rather not stop looking at the past as it's only by learning > from the past that we create a better future. > Open Source in general, and this project (and its ancestors) in particular have a very rich history indeed, that is worth learning from. So let's not cherry-pick our stories, and acknowledge that a project of this size relies critically on a working commercial ecosystem. Second: > > There's definitely things that TDF can do much better than any > > ecosystem company. There's also definitely things that ecosystem > > companies are likely better suited for, than TDF. The same is true for > > our volunteer community > > True and that's why there is room for all to have fun and participate to > make LibreOffice and related project great. > > > (which is BTW not the same as TDF, the foundation!). > > This comment worries me a bit. > There is nothing to worry about. I'm stating here, that the goals of TDF (as enshrined in the statutes), and the shared goals of our community (all those contributing to LibreOffice) are not necessarily exactly the same. It is useful for all of us to remember, that TDF is there (and was founded) to serve the community, and not the other way around. My original comment was pointing to something else though, so this is again a tangent. What I said was, that there's three large camps (ecosystem, TDF, volunteer community), that ideally complement each other in what we do. Instead of eyeing each other with mistrust. And now - let's move on! Cheers, -- Thorsten signature.asc Description: PGP signature
[board-discuss] Looking forward, not backwards (was: Counterproposal to the "actization" of LibreOffice Online)
Paolo Vecchi wrote: > So, to conclude, this "distraction" has actually helped the board in dealing > with a situation which impaired its freedom to act in a well informed and > structured way and created a new situation where, thanks to important and in > some cases overdue work done by the board during this term, we know where we > stand, we know that we can do a lot more that some thought we could and we > can finally move forward and do more good things for the community. > I have a hard time reconciling the objective loss of a quite important project at TDF, with the above paragraph. Whatever the reasons (perhaps it was inexperience), the board managed to alienate an important corporate ecosystem member enough that they left with their project. I would really like to stop looking at the past now, and instead see how we all together can shape the future - with some impact. That means, keeping as many existing contribution, while attracting & growing more contributors in green fields (where there are plenty!). Personally, I'm not interested in playing zero-sum games (taking development away from the ecosystem, and re-patriating it into TDF). Instead, we need to work much more on creating win-win setups, and supplementing each other. There's definitely things that TDF can do much better than any ecosystem company. There's also definitely things that ecosystem companies are likely better suited for, than TDF. The same is true for our volunteer community (which is BTW not the same as TDF, the foundation!). In the past, we've been envied for actually striking a nice balance, and complementing each other. One obvious area where there's very little commercial incentive to do things is a11y. At the same time, that would be something very charitable to fund & further! If there's budget for funding internal development, a11y would be very high on my list of topics to focus on. Cheers, -- Thorsten signature.asc Description: PGP signature
[board-discuss] Charitable activities during the pandemic (was: Counterproposal to the "actization" of LibreOffice Online)
Hi Sophie, a bit sad to read your rather disappointed mail - sophi wrote: > I don't read only about products, but about sharing, empowering of > people, solidarity and creativity, all in the FLOSS spirit. TDF for me > is not only hosting a product, but has a culture, has a knowledge, has a > lot of creative people around, meaning we have a lot of resources, but > we have done nothing to share them during the critical period families > and students were fronting. > Beyond continued development & offering of LibreOffice - what could we have done in addition? I'm honestly interested in ideas & suggestions. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
Hi Paolo, Paolo Vecchi wrote: > On 12/01/2022 12:44, Thorsten Behrens wrote: > > That seems unlikely to repeat itself? > > You think no other commercial organisations are or will be hosting any > LibreOffice related projects with TDF or you think that the board in future > will surely spot that a project hosted at TDF with contributions mostly from > one organisation could create issues without having some rules set? > The latter. > > Your proposed text for the policy _does_ constitute a default, > > up-front requirement. Perhaps it needs rewording then, to better carry > > your intended meaning? > > I'm not sure if there is a language barrier here and/or I haven't yet > expressed the concept clearly enough. > The point is that the letter of your proposal does not match what you say. For a final policy, it doesn't matter what people state in an email discussion; what counts is what's in the policy text. So please update that text, for this conversation to remain effective. Best, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
Hi Paolo, Paolo Vecchi wrote: > Unfortunately it seems like the board didn't realise that a big issue was > brewing for quite a few years as clear rules were not set. > That seems unlikely to repeat itself? > > Putting this burden on everyone **up-front** and **by default** (with > > the added twist that people need to prove their contribution is not > > commercial), I believe is a terrible idea. TDF would be well-advised > > to have fewer, not more, hurdles for code contribution. > You may have missed that in my previous emails I clearly stated that the > "burden" is not up-front, is not by default and people do not need to prove > their contribution is not commercial. > > I actually said: "I'm not even suggesting that each individual proposing a > project should sign it, only when the project is being proposed by or it > becomes controlled mostly by a single company." > Great. So why do you want it in the policy then? As you point out, most projects start as individual initiatives. Your proposed text for the policy _does_ constitute a default, up-front requirement. Perhaps it needs rewording then, to better carry your intended meaning? Best, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
Hi *, Paolo Vecchi wrote: > That should be added in the "## De-atticization requirements. The form could > be along the line of: > > - If the parties involved in the development of the project are commercial > entities an agreement must be signed to make clear the final scope, the > benefits to the community and the eventual limitations in publishing it > following TDF's objectives. > It is notoriously hard to separate commercial from non-commercial activities. I believe putting up more barriers to entry for people wanting to contribute to TDF projects is not smart. But lets hear others' opinion on that on Friday. > "This agreement, to be drafted by our legal team in collaboration with TDF's > counsel, should be added to the proposal before voting as it should be part > of the on-boarding process for projects we intend to support." > > That is the same agreement we should prepare, and eventually adapt, for > "atticisided", current and new projects hosted by TDF. > Instead, the board can always decide on a case-by-case basis that more formalities are needed. Putting this burden on everyone **up-front** and **by default** (with the added twist that people need to prove their contribution is not commercial), I believe is a terrible idea. TDF would be well-advised to have fewer, not more, hurdles for code contribution. Let's discuss on Friday, all the best, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
I wrote: > So I'd like to call for a vote soon, unless there's concrete input for > edits. Let's give this two more days. > There were two concrete proposals to amend the policy, that we'll discuss during the board call on Friday. Thus, holding the vote for the moment. All the best, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
Hi Paolo, Paolo Vecchi wrote: > > Can I see the adjustments/changes to the proposal then please? > > The proposal, as stated in my previous emails, is related to the eventual > "de-atticisation" of the project. > Again, for this to be constructive, could you please suggest concrete changes to the proposed policy? > The proposal was meant to ask if your project would benefit from being > supported by TDF and in which ways. > Thanks. That is good to know. > Having articles stating "The LibreOffice team has been working on a > port to browser-hosted WebAssembly"(1) or the page you created on > TDF's wiki describing the WASM project(2) without specifying who > leads it and what could be the eventual distribution limitations, > may suggest to some that the project is hosted and developed by/for > TDF, that's the reading some may have of the "LibreOffice > team/developers/other variants", and that will be bound to TDF's > objective to make it "available for use by anyone free of charge". > Let's please finally decouple this discussion, Paolo. I'll refrain from answering in this thread, that repeatedly conflates many things. On the above: are you asking me to remove public documentation on how to build the WASM port, and what it is? A private answer is fine, and then we can continue this discussion (if there's anything left to clarify) else-thread. This really has nothing to do with the atticisation proposal. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
Hi Paolo, let's stay focused - Paolo Vecchi wrote: > > Do you have concrete suggestions on changing the actual > > proposal? > > Well, yes. That's what the rest of the email you replied to was about. > Can I see the adjustments/changes to the proposal then please? > I'm not even suggesting that each individual proposing a project should sign > it, only when the project is being proposed by or it becomes controlled > mostly by a single company. > That then seems entirely unrelated to a putative attic process? > Another example could be LOWA (LibreOffice WebAssembly), which is a > promising project developed mostly by Allotropia AFAIK. > > That's why months ago I've asked you to lead by example by officially > present the project to TDF in a couple of pages stating the objectives and > what TDF could expect to deliver to the community while Allotropia pursues, > rightly, its commercial interests. If you followed up we would have had > already a document on which to base the agreement we need to welcome other > projects. > Let's discuss that else-thread please. Again, new projects are a different area entirely. And as one of the people funding LOWA, I find it irritating that my contributions are met with demands, instead of gratitude. I've not yet asked TDF anything in return. Meanwhile, I'd be most happy if people interested in LOWA would come & join our FOSDEM talk about it: https://fosdem.org/2022/schedule/event/lowa/ Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
Hi Paolo, Paolo Vecchi wrote: > I would wait for an eventual vote until a few weeks after FOSDEM just in > case more questions and/or interest about the future of LOOL come up. > The attic proposal is only incidentally related to LibreOffice Online. Do you have concrete suggestions on changing the actual proposal? > This agreement, to be drafted by our legal team in collaboration with TDF's > counsel, should be added to the proposal before voting as it should be part > of the on-boarding process for projects we intend to support. > I very strongly suggest to *not* make that mandatory for every kind of project we'd be interested in adopting. It would otherwise completely kill the onboarding of that kind of small-but-useful tools we've taken up in the years past (cppunit, libcmis, odf toolkit etc). No volunteer in her right mind would sign binding, legal agreements of that kind. Instead, it can be left to the discretion of the board to ask for more formal commitments, if it sees a need. Best, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Draft text: an "attic" proposal
Hi *, quick comment on the below - Paolo Vecchi wrote: > Very brief summary of the events: > > Back in March 2020, other new board members and I, started making enquiries > in regards to why we weren't making available an up to date LOOL to the > community. We were clearly "advertising" LOOL on the website but it wasn't > in a easily usable state and I strongly believed we had to do our part to > help e.g. schools and non-profits coping with remote working when the > pandemic started hitting hard. After all, TDF has been created for the > public benefit, and in this new situation with the lockdown, what would have > been more beneficial to the general public than to support pupils, students, > volunteers in nonprofits by providing a platform and sharing our knowledge, > based on Free and Open Source Software? This would have allowed our > Foundation and us, as citizens, to perform our civic duty to help and it > would also have had a positive marketing effect for the members of the > ecosystem. Unfortunately that opportunity is now lost, mostly in favor of > proprietary vendors which just consolidate their position. It's sad. It's a > lost opportunity for TDF and for the ecosystem. > I agree it's an opportunity lost. In many ways indeed - losing LibreOffice Online's active developer base was not inevitable. That it did happen in the end, after many people tried to solve the brewing conflict, was to a considerable degree caused by part of the board persistently threatening with unilateral action. In terms of helping schools and non-profits, many things did happen (I know for certain that Free Software, including LibreOffice, gained noticeable user traction here in Germany). Regarding LibreOffice Online though, that wouldn't have been something that TDF could have hosted ourselves for the world at large. Implying then, that if only TDF had offered free downloads of the server RPMs, we would have managed to significantly dent the market share of the integrated cloud vendors - seems to be quite naive to me. I'd like to now decouple this discussion from the thread topic (which is about a general attic process). If there's a need for further discussion (I'd _much_ prefer forward-looking debates, rather than re-litigating the past!), please all, start a new thread, and I'll answer there. All the best, -- Thorsten signature.asc Description: PGP signature
[board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
Dear board, dear TDF members, all, this proposal has sparked interesting discussions, that we should continue. For the proposal at hand though, we've not received much if any actionable feedback. So I'd like to call for a vote soon, unless there's concrete input for edits. Let's give this two more days. All the best, Thorsten I wrote: > Dear board, dear TDF members, all, > > as mentioned a few times during board calls, Emiliano and me have been > drafting a proposal what to do with no-longer-active projects at TDF. > > Here's the draft we're both happy with: > > -%<-- > > ## Introduction > > It can happen, with a huge project like LibreOffice, that parts > of the project worked on by the community will become obsolete or > superseded by other projects. The following proposal will cope > with the need to let the code (and/or other form of text related > to the code) to be publicly available, while setting the correct > expectations around its availability, suitability for a > production environment, quality and security. > > ## What is the “attic”? > > The “attic” is a special area of TDF infrastructure where part of > the code/documentation/translations can be parked, that is not > anymore actively developed. This will help setting the correct > expectations on its status of development, while not losing its > fundamental trait of being open source (so its code must be > publicly available). > > In the present proposal, the “attic” would be a single host > inside TDF infrastructure, available in HTTP/HTTPS protocols, > responding to a URI similar to: > https://attic.documentfoundation.org > > ## Specificity of the “attic” > > This “attic” space will have, at minimum, the following characteristics: > > • It is supported by git – the well known CVS developed by Linus > Torvalds initally and used to share the sources of the Linux > kernel. Being supported by git will ease the forking of the code > contained there; > > • Any repositories inside it will be made “read only”, so no “push” or > “pull request” mechanisms will be available: this allows changes to > the code to be shared as it was the last time it was “atticisized”; > > • Anonymous access to the repositories has to be made the default > access method: we want the code present in the “attic” to be always > available to everyone; > > • It should have a recognizable URL – or internet address, less > technically: this allows for the code present to be clearly > separated by other actively developed code; > > • A specific text explaining the nature of the code, its > “de-atticization” requirements and how to get support on the code > inside the repository to be present in the README of every > repository. The text of these disclaimer, the de-atticization > requirements will be discussed further on in the proposal. Regarding > contacts to get support, the idea is to provide quick and ready > information on who/where to ask for anything related to the code in > the repository. > > The proposed implementation of this space is by using > git-http-backend1. The proposal has already been evaluated by the > Infra team and the overhead for maintaining such a solution will be > “negligible”. > > ## Atticization process > > The Engineering Steering Committee (ESC) of TDF, the Board of > Directors (BoD) or one or more of its Directors can propose the > “atticization” of a part of the project. That proposal will have to be > voted on successfully by both the ESC and the Board of Directors. > > The specific code proposed (mostly, entire git-based repositories) > will be then effectively atticized by the Infra team. Other than > moving the repository to the attic, these other changes will be > needed: > > • Deactivation of specific -dev or -users mailing list; > > • No new binary releases will be provided (older releases will persist > in download archive); > > • Changing eventual specific category on BugZilla to “Atticized repo – > please do not use” (ed.: needs to be checked by Infra/QA/Ilmari); > > • Possibly disable Ask/Discourse pertaining categories (ed.: needs to > be checked by Infra/Sophie). > > ## De-atticization > > A part of the project that is actually present inside the “attic” can > be moved back into active development, whenever sufficient interest > around the code emerges. > > ## De-atticization requirements > > A repository can be de-atticized when it reaches the following requirements: > > • A publicly available repository has to be present, collecting new > modifications to the initial project. This repository needs to be > based on the initial atticized repository; > > • The modified code has to be open source/free software under an > OSI-approved license; > > • At least three different developers have committed changes to the > forked repository, ideally not all of them affiliated to the same > entity;
[board-discuss] Re: Acceptance of role in the Board of Directors
I, Thorsten Behrens, elected director of the board of The Document Foundation, hereby accept this position within the Stiftung bürgerlichen Rechts. My term will start February 18, 2022. Signed: Thorsten Behrens Ich, Thorsten Behrens, gewähltes Mitglied des Vorstands der The Document Foundation, nehme mein Amt innerhalb der Stiftung bürgerlichen Rechts an. Meine Amtszeit beginnt am 18. Februar 2022. Unterzeichnet: Thorsten Behrens signature.asc Description: PGP signature
Re: [board-discuss] Draft text: an "attic" proposal
Hi *, Michael Weghorn wrote: > I think that would be in line with how we have been handling single features > in the desktop version that were in a comparable state in the past - usually > after discussing the removal in the ESC first. > I would support that proposal. The attic process is for repository-level decisions. When it comes to code in the core repo, let's stick to the light-weight process we have already (as Michael said, larger/possibly controversial changes get discussed in the ESC). All the best, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Draft text: an "attic" proposal
Hi Marco, since you specifically asked me to comment - Marco Marinello wrote: > first of all, I'd like to state for those that are not into the current > status quo that this proposal will mainly affect the "Online" project at > TDF's infra. > Conversely, I believe it would be wise to structure the atticization process (and its reversal) independently of the LibreOffice Online question. It is not the first, and not the last time, that code we host becomes effectively unmaintained (for any number of reasons). You further state: > In conclusion, I would like to emphasise the fact that I’m > completely unhappy with the “attic” proposal as a solution for the > Online situation and hope we can all work together to allow TDF to > still consider Online a part of the LibreOffice suite. > Let's please dis-entangle this (ideally discussing Online remedies in a separate thread). You state you're unhappy with the attic proposal, but don't provide any specific criticism (change this clause, avoid that trap, etc). Is it that you would be fine with it, if -- hypothetically -- cppunit would become unmaintained? Or is there a more fundamental problem with it, from your PoV? If yes, can you suggest changes? On the Online topic, I've got nothing much to add (beyond the fact that the development from 2020 was rather regrettable). I'm also biased (as likely you are, and others with strong opinion on the question). Allow me one comment though: Marco Marinello wrote: > Kendy wrote: > > Marco Marinello píše v Po 20. 12. 2021 v 20:34 +0100: > >> I have already said this many times but I want to repeat it: it > >> has to be clear (and hopefully stated by legal contracts) to the > >> companies working in the LibreOffice ecosystem that they cannot > >> wake up one day and bring their development outside the > >> LibreOffice project. They cannot stay with one foot inside the > >> ecosystem, contributing to it, and with the other one bringing > >> their development effort outside. This is something the next > >> board should focus on. > >> > > Given that we are doing FLOSS (Free / Libre / Open Source > > Software) here, I wonder how would you like to frame such a legal > > contract, given that the "right to fork" is one of the basic Free > > Software freedoms? And what if it was not a company, but another > > group (do you remember IceWeasel?) > > > IANAL so I have no clue on how this kind of contract could be > settled but I want to say that is quite logical that you cannot both > support and oppose an entity. In Italy, the law states that if you > leave your job and create a company that will do the same job you > were doing as an employee, taxes will be much higher. > This idea sadly runs counter to *everything* that matters for FLOSS licenses and projects. Let's please put it to rest. Once the code is open, everyone is free to take it, fork it, and do with it what they please (according to the terms of the license, and perhaps by rebranding). All remedies I can think of are much worse than the disease you'd like to cure. And for companies, it is trivially easy to circumvent any sort of contract that binds a particular company, but not the general public. Cheers, -- Thorsten signature.asc Description: PGP signature
[board-discuss] Draft text: an "attic" proposal
Dear board, dear TDF members, all, as mentioned a few times during board calls, Emiliano and me have been drafting a proposal what to do with no-longer-active projects at TDF. Here's the draft we're both happy with: -%<-- ## Introduction It can happen, with a huge project like LibreOffice, that parts of the project worked on by the community will become obsolete or superseded by other projects. The following proposal will cope with the need to let the code (and/or other form of text related to the code) to be publicly available, while setting the correct expectations around its availability, suitability for a production environment, quality and security. ## What is the “attic”? The “attic” is a special area of TDF infrastructure where part of the code/documentation/translations can be parked, that is not anymore actively developed. This will help setting the correct expectations on its status of development, while not losing its fundamental trait of being open source (so its code must be publicly available). In the present proposal, the “attic” would be a single host inside TDF infrastructure, available in HTTP/HTTPS protocols, responding to a URI similar to: https://attic.documentfoundation.org ## Specificity of the “attic” This “attic” space will have, at minimum, the following characteristics: • It is supported by git – the well known CVS developed by Linus Torvalds initally and used to share the sources of the Linux kernel. Being supported by git will ease the forking of the code contained there; • Any repositories inside it will be made “read only”, so no “push” or “pull request” mechanisms will be available: this allows changes to the code to be shared as it was the last time it was “atticisized”; • Anonymous access to the repositories has to be made the default access method: we want the code present in the “attic” to be always available to everyone; • It should have a recognizable URL – or internet address, less technically: this allows for the code present to be clearly separated by other actively developed code; • A specific text explaining the nature of the code, its “de-atticization” requirements and how to get support on the code inside the repository to be present in the README of every repository. The text of these disclaimer, the de-atticization requirements will be discussed further on in the proposal. Regarding contacts to get support, the idea is to provide quick and ready information on who/where to ask for anything related to the code in the repository. The proposed implementation of this space is by using git-http-backend1. The proposal has already been evaluated by the Infra team and the overhead for maintaining such a solution will be “negligible”. ## Atticization process The Engineering Steering Committee (ESC) of TDF, the Board of Directors (BoD) or one or more of its Directors can propose the “atticization” of a part of the project. That proposal will have to be voted on successfully by both the ESC and the Board of Directors. The specific code proposed (mostly, entire git-based repositories) will be then effectively atticized by the Infra team. Other than moving the repository to the attic, these other changes will be needed: • Deactivation of specific -dev or -users mailing list; • No new binary releases will be provided (older releases will persist in download archive); • Changing eventual specific category on BugZilla to “Atticized repo – please do not use” (ed.: needs to be checked by Infra/QA/Ilmari); • Possibly disable Ask/Discourse pertaining categories (ed.: needs to be checked by Infra/Sophie). ## De-atticization A part of the project that is actually present inside the “attic” can be moved back into active development, whenever sufficient interest around the code emerges. ## De-atticization requirements A repository can be de-atticized when it reaches the following requirements: • A publicly available repository has to be present, collecting new modifications to the initial project. This repository needs to be based on the initial atticized repository; • The modified code has to be open source/free software under an OSI-approved license; • At least three different developers have committed changes to the forked repository, ideally not all of them affiliated to the same entity; • Every developer should have pushed 5-10 non-trivial commits over the span of at least three months; • The de-atticization proposal has to be supported by at least one member of The Document Foundation. ## De-atticization procedure The de-atticization has to be requested from either the ESC or the Board of Directors; the ESC will provide a technical clearance for the de-atticization, as well as any needed corrections to the project to comply to specific development customs of TDF community and to adhere to the conventions practiced at TDF. Once c
[board-discuss] Re: Board elections: questions to the candidate Thorsten Behrens
Dear Marina, members of TDF, thanks a lot for the opportunity to take a position. In case of being elected, here are my answers: Marina Latini wrote: > 1. Do you commit yourself to have enough time and the necessary > technological tools in order to participate to the regularly scheduled board > calls? > Yes indeed. I have participated in all board calls but one in the past term (IIRC), and want to keep the habit. > 2. Do you commit yourself to follow up and work on (at least) the main items > and actions you will volunteer to oversee or that will be assigned to you by > the board? > Yes indeed. > 3. What is your willingness to delegate decisions, especially in lack of > time? > It is good practice to authorise deputy directors for cases of absence, and I intend to do that again (if being elected director). Also I believe a future board will work best, when detail questions are sorted out in smaller working groups (which then also requires trust & delegation). > 4. What are your views on the foundation's budget? How should the money be > spent, besides our fixed costs? > Decisions on budgets are indeed probably the single most influential thing the board is going to do. As such, it is a valid question to ask, so voters know beforehand what they can expect. At the same time, it is a difficult question to answer for me, as experience has shown that spending TDF money can be surprisingly hard (constraints due to the charitable status of the foundation, supply/demand issues (budget items really should come out of / with community backing)... Generally, I'd like to spend money alongside my visions for TDF: - growing the contributor base - staying relevant (technology, attractiveness for contribution, and of course doing something that benefits our users) - professionalize TDF as a leading FLOSS charity > 5. Should we work towards broadening our pool of contributors, both > technical and non-technical? > Yes absolutely! > 6. What actions do you suggest to increase the engagement and participation > of volunteers from local communities around the world in project's > activities? > What works best in my experience is going via social experiences - having relatable people meet, encourage & grow a local community. That was and is certainly hard during Corona times, as personal meetings are so important; we all hope the next year will be better. It is beyond that likely that many local communities have specific needs. It will be important for me to reach out to them and listen. > 7. Should the Foundation -as an entity distinct from the LibreOffice project > or the Document Liberation project- engage into growing its influence and > promoting and defending Free Software and Digital Freedom? It is, after all, > an integral part of its mission per its very Statutes. If yes, do you have > ideas on what should be done about this? > I believe we already do that, but of course we can always do more! We touched on that in the board interview sessions, and my summary statement would be: we tend to have the largest impact by empowering our community. Hiring lobbyists is something TDF could do, but likely not on a global (or even European) scale. So, learning from successful grassroots lobbying campaigns (like the FSFE is running), and providing our community with the means & materials to promote in their local countries would be my plan. > 8. What's your idea to let TDF membership become more appealing? Currently, > the only difference from being Community member and TDF member is the > possibility to vote and be voted for TDF's governance, and it's fine, but > can you imagine anything to encourage more Community members to become also > part of TDF? > Obviously the ability to vote is a very important added value, especially during a board election. ;) More seriously, TDF and the LibreOffice project is shaped by its contributors. Some might be very content with contributing to the project only, others might additionally want a say in elections, and getting inside information from the members list. Even others want to shape TDF's fate by being part of the MC, or the board. All of those are equally valuable. I don't believe we should be in the business of nudging people too much into certain roles; instead we should continue to celebrate all kinds of contributions (to project and foundation). If there are barriers of course (e.g. language, bad communication, wrong medium etc) - we should work on overcoming those. The contributor survey was quite an excellent approach to that question, and we should continue doing it. > 9. How do you view your (potential) role as a member of the board of > directors, given that this position does not give you any specific > functional role inside the LibreOffice or Document Liberation projects? > Indeed. The board role in my view is largely one of representation - it is important to have the broadest possible spread of people (locales, sub-projects, mind sets) present
[board-discuss] [DECISION] Approve version 1.3.1 of the CoI policy
Hi, 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 5 Board of Directors members have participated in the vote. The vote is quorate. A quorum could be reached with a simple majority of 3 votes. > calling for a VOTE on the just-published draft update to the CoI > policy [1], to modify our Rules of Procedure [2] - such that we > reference version 1.3.1 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/2/21/Mike_BoD_Conflict_of_Interest_Policy_ver1_3_1.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. > > --- Result of vote: 5 approvals, 0 abstains, 0 disapprovals. Both deputies supports the motion. Decision: The proposal has been accepted. Best, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] [VOTE] Approve version 1.3.1 of the CoI policy
Hi, gentle reminder - the vote is running for a bit less than a day still. ;) Best, Thorsten I wrote: > Dear directors, all, > > calling for a VOTE on the just-published draft update to the CoI > policy [1], to modify our Rules of Procedure [2] - such that we > reference version 1.3.1 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/2/21/Mike_BoD_Conflict_of_Interest_Policy_ver1_3_1.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 December 1st, 2021. After approval, the amended Rules > of Procedure will be published and enter into immediate effect. > > [1] > https://wiki.documentfoundation.org/images/2/21/Mike_BoD_Conflict_of_Interest_Policy_ver1_3_1.pdf > [2] https://wiki.documentfoundation.org/TDF/BoD_rules > > Best, > > -- Thorsten signature.asc Description: PGP signature
[board-discuss] Candidacy for a board seat: Thorsten Behrens
Dear Community, Members of the TDF, and Membership Committee, I currently serve as a director on the board of The Document Foundation, and I would like to run again. My full name is Thorsten Behrens, as of today I'm 47 years old. Together with my wonderful wife & fellow LibreOffice hacker Bubli and my 3 sons, we live in Hamburg, Germany. My work with the project and codebase started in 2001 as a developer (with the then-OpenOffice.org community), which we jointly took and founded TDF & LibreOffice with in 2010. Since then, I was serving in various roles, including my current one on the board of directors. From 2008 to 2020, I was also a member of the OASIS ODF technical committee. Since 2021, I'm honoured to lead a great team of LibreOffice developers at my company allotropia software, helping numerous customers to run LibreOffice reliably and securely. Why am I running? * quite a few things that I wanted to pursue during the past board term do show some progress - but there's just so much left to do: * on the growing TDF impact and further professionalising front - the success story is us finally filling the developer mentor role. I helped with the interviews & selection process, and am looking forward to those efforts now bearing fruit. Still, my focus areas from last time remain almost unmodified, since I believe there's much left to be done: - further increase our mentoring & community building efforts - continue the push to have LibreOffice available everywhere it matters, especially on app stores - tap into grants and funding TDF is uniquely positioned to attract * Diversity - sadly this is an area where this term again saw little progress. With dev mentoring capacity now revving up, I'm confident a next board has more opportunity there to lift people up though. I would like to continue pushing that. At the same time, we must not forget to retain, nurture and celebrate our existing contributors, and remain an attractive and fun place to contribute to for everyone. * Integrity - I was talking about conflict of interest policy two years ago, and thanks to pushes from Marina and the MC, we now have explicit rules for both bodies in place. The topic remains very close to my heart, since its all about playing fair. At the same time, when it comes to displaying integrity as a charity to our donors and the outside world at large, more remains to be done. I'd love to continue pushing e.g. for TDF being occasionally audited, and eventually receiving a Charity Seal (certifying effectiveness & efficiency, as well as transparency). If you have any questions, about my person or the ideas above, please do reach out in public or in private! Full name: Thorsten Behrens Email: t...@libreoffice.org Corporate affiliation: allotropia software GmbH (German software & consulting company, member of the advisory board since 2021), owner and CEO 75 words candidacy statement: I'm leading a team of LibreOffice developers at allotropia software, and am a long-time TDF contributor to both code and organisation. Serving in the current board as a director, I would like to offer my continued help for the next two years. Things I promise to do: improve & professionalize organisation; grow & diversify contribution; keep things fun, fair & sustainable; and help with the largely-German administrative grunt work. Kind regards, -- Thorsten signature.asc Description: PGP signature
[board-discuss] Re: [VOTE] Approve version 1.3.1 of the CoI policy
I wrote: > Dear directors, all, > > calling for a VOTE on the just-published draft update to the CoI > policy [1], to modify our Rules of Procedure [2] - such that we > reference version 1.3.1 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/2/21/Mike_BoD_Conflict_of_Interest_Policy_ver1_3_1.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 December 1st, 2021. After approval, the amended Rules > of Procedure will be published and enter into immediate effect. > I approve. Cheers, -- Thorsten signature.asc Description: PGP signature
[board-discuss] [VOTE] Approve version 1.3.1 of the CoI policy
Dear directors, all, calling for a VOTE on the just-published draft update to the CoI policy [1], to modify our Rules of Procedure [2] - such that we reference version 1.3.1 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/2/21/Mike_BoD_Conflict_of_Interest_Policy_ver1_3_1.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 December 1st, 2021. After approval, the amended Rules of Procedure will be published and enter into immediate effect. [1] https://wiki.documentfoundation.org/images/2/21/Mike_BoD_Conflict_of_Interest_Policy_ver1_3_1.pdf [2] https://wiki.documentfoundation.org/TDF/BoD_rules Best, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Proposed version of the CoI Policy 1.3.1
Dear members, all, Michael Meeks wrote: > There is a marginally improved 1.3.1 version here from review today: > > https://wiki.documentfoundation.org/images/1/1f/Mike_BoD_Conflict_of_Interest_Policy_ver1_3_1.odt > For easier mobile reading, here's the PDF version of that draft: https://wiki.documentfoundation.org/images/2/21/Mike_BoD_Conflict_of_Interest_Policy_ver1_3_1.pdf Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Re: Agenda for TDF board meeting on Friday, August 27th at 1300 Berlin time (UTC+2)
Hi Andreas, please, this is not very constructive so far. I tell you §8 is not affected, you claim it is (and conclude a number of things from there). At the same time, MC and board are working on a CoI policy, so this: > And it shows further that a critical view about the impact of such > actions on TDF and its reputation is not available inside all long > term board members. > is a needless ad hominem, and a false statement on top. If you still have concerns, please lets get into a quick call (you have my number); or you join one of the next board meetings - there's always room for the community to ask questions in the beginning. All the best, -- Thorsten -- 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: Agenda for TDF board meeting on Friday, August 27th at 1300 Berlin time (UTC+2)
Hi Andreas, Andreas Mantke wrote: > seemed the board needs a discussion and decission about § 8 IV of the > statutes: > I can assure you (and the board), that § 8 (4) is most definitely not touched by that announcement. Please do reach out if there's any further questions (I'll probably not be able to make the call tomorrow though). All the best, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Vote about Certification Updates
Italo Vignoli wrote: > 1. Develop a training for certification (attached), which allows to access > the "LibreOffice Certified" entry level (without specification about > migrations and training), after the usual certification review. Once the > training for certification has been approved, it will be transformed into a > series of online training classes provided through Udemy (which seems to be > almost a standard for certification training, as it is used by Microsoft, > Oracle and Cisco, plus others). > > 2. Keep the current "Migration Professional" and "Professional Trainer" as > main level certification for people who have a hands-on experience in > migrations or training (exactly as in the past). People with LibreOffice > Certification could apply for Professional Certification after 12 months > from the first certification, based on a migration/training project with > extensive documentation (a detailed report of the migration project, or a > detailed evaluation of the training project). Only people with full > pre-requisites compliance can directly access Professional Certification > without going through LibreOffice Certification. > > 3. Create the certification training for single applications: "LibreOffice > Writer/Calc/Impress/Draw/Base Certified Trainer", which is simple and > uncontroversial. > > 4. Create a "Senior Migration Professional" and a "Senior Professional > Trainer" certifications, only for certified professionals who have been > active in the project for a while and contribute as volunteers in some area. > > 5. Update all certification related documents to reflect all the above. > All excellent, +1 - thanks Italo! Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Re: Libreoffice Vanilla
Hi Dennis, Dennis Roczek wrote: > E.g. You know very well how long which MS Windows version is supported with > which support plan. In the store you can only guess: > is it > * a live time license (buy one, only get this major release updates) > * some X months supported license > * buy-one-get-forever-updates license > * something different > Fair points. Still, before exploring if/how to address one or more of the above options, what would you (and others here!) consider a fair deal? Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Re: Libreoffice Vanilla
Hi Drew, on the feedback / contact question - I recall MS tried hard to keep people on the store pages (discouraging links off-site, encouraging companies to engage with users on the Store / comment pages there). The place to go & get support & provide feedback directly to CIB is: http://libreoffice.cib.de/ (click on the "free online support" button). Drew Jensen wrote: > 32Bit binary! > Why? > We started small & thought that would be a good catch-all; also given that many systems with Windows-S where entry-level. Meanwhile, MS added the option to provide several architecture packages for the same version, so that should be easy to fix (when I evaluated that initially, you had to build a package containing _all_ architectures, which was then quite bulky). Drew Jensen wrote: > > On the MS Store listing it would be good to actually show how long the > > buyer will receive updates. > > I have in my notes that it is 18 mos, but that came IIRC from the ML > > and nowhere on the store listing is that spelled out, at least not > > that I can find. > > > What would you consider fair? Drew Jensen wrote: > > > I see reference in the application to making a donation to TDF. > > > Why would I do that (donate) after I already purchased a license? > > > (I also purchased LO powered by CIB and Collabora Office and neither > > > include these references to making a donation to TDF; why would LOV be > > > different? Because it cost $5 less?) > > > > That's mostly due to the fact that we wanted to build & publish from an unmodified source tarball (aka publish a true "vanilla" version). If there's consensus that the store versions should be modified, that's easy to patch out then. Drew Jensen wrote: > > > Question; Last week TDF put out a statement that LibreOffice 7.0 is > > > now considered the proper release for all users. Can I assume that my > > > copy of LibreOffice Vanilla 6.4 will be upgraded to 7.0 shortly? > > > > I would think so, yeah. But please be aware that I can no longer speak for CIB (https://blog.allotropia.de/2021/01/14/cib-spins-off-allotropia/) ;) All the best, -- Thorsten signature.asc Description: PGP signature
[board-discuss] Updated representation statement Thorsten Behrens
I, Thorsten Behrens, elected member of the Board of Directors of The Document Foundation, hereby and until further notice, nominate the following deputy to represent me during board calls and meetings: 1. Nicolas Christener All the best, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] [VOTE] LibreOffice Online freeze-related decisions
Emiliano Vavassori wrote: > * branches will be rewinded to commit (or the commits before) > 4ca4fd34169dd386c2fa57bd28650c00b23d6864 (last commit before changes by > Collabora) > Yep, that was implied, +1 > * OpenGrok needs to point to the TDF git/gerrit > Yep, that was Guilhem's proposal, +1 > * revert decision 1b and (if feasible) point TDF repo on GitHub on > git/gerrit on TDF infra. > That was the compromise I had suggested last year, to have github track github, not the frozen gerrit. As such, -1. Cheers, -- Thorsten signature.asc Description: PGP signature
[board-discuss] Re: [VOTE] LibreOffice Online information in the release notes
Ah sorry, too much voting in one thread - yep, +1 to that proposal! Lothar K. Becker wrote: >+1 > >Thanks >Lothar > >Am 02.02.2021 um 13:15 schrieb Florian Effenberger: > > Hello, > > based on the previous discussion, putting the following to VOTE now: > > Ask the marketing team to summarize the new LibreOffice Online > information website (see vote item #1 in > [1]https://listarchives.tdf.io/i/4bCUE2Lh2ffa-M8da8zEfPF7) in the > release notes, adding a link to the full page > > [Note: The content of that website is currently edited and discussed and > should be finished soon.] > > Florian > > -- > Lothar K. Becker, 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: [2]https://www.documentfoundation.org/imprint signature.asc Description: PGP signature
Re: [board-discuss] [VOTE] LibreOffice Online freeze-related decisions
Daniel Armando Rodriguez wrote: > "rewind branches on https://git.libreoffice.org/online and for the time > being deny all write > operations to the repository, be it on the git or gerrit side. It'll > freeze the state of the dashboard, notification, and other clones for > free, and if/when we decide to accept contributions again everything > will be just one switch away." > Yep +1 - it was the initial, actual intention incidentally. ;) Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Collecting proposals on TDF subsidiary
Florian Effenberger wrote: > as discussed during the last board calls, the board is currently collecting > proposals on a TDF subsidiary. For that, we've created a folder "TDF > Subsidiary" in the Nextcloud "TDF Members" share, where the various ideas > will be collected. > The board would like to discuss (and I hope move this forward) during its FOSDEM meetings. So I'd like to repeat this call for proposals, and add a deadline for submission in time for the pre-FOSDEM meeting, let's say Thursday January 28th. Best, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] [DISCUSS] LibreOffice Online freeze-related topics
Guilhem Moulin wrote: > Anyway, why should TDF assist with tooling for a project that's no > longer developed under its umbrella? > Why not? It's a useful service, and the instance is running anyway. (for the record, it's not without precedent that TDF helps out not-directly-affiliated projects. it's I believe a good habit, that's also cultivated in other opensource foundations, to help each other out every once in a while...) In a word, no skin off our back, IMO. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] [VOTE] LibreOffice Online freeze-related topics
Florian Effenberger wrote: > 1. Ask the marketing project to make a proposal to revamp the LibreOffice > Online website (https://www.libreoffice.org/download/libreoffice-online/) to > reflect the status quo > > 2. Ask the team to keep an eye on BugZilla, and freeze/make read-only the > BugZilla component for LibreOffice Online, should that be necessary (to > avoid new bugs being filed, but do not delete existing content) > > 3. Point the OpenGrok repository to the mirrored Collabora Online > repository, for the time being, as long as the development is not happening > at TDF > > 4. Adapt the Dashboard for the Online repository and freeze contributions in > the state immediately preceding the fork > > 5. Ask the team to remove the Online section from the release notes in the > wiki > +1 - makes sense to me as a package. Best, -- Thorsten, who of course would like the whole situation to be better... signature.asc Description: PGP signature
Re: [board-discuss] [DISCUSS] LibreOffice Online freeze-related topics
Guilhem Moulin wrote: > I assume “freeze” in 1. was not meant to turn > https://git.libreoffice.org/online it into a read-only mirror? > That's anyway not how I read the decision. > Agreed. The idea was to mirror on github, and freeze on gerrit. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] LibreOffice 7.1 marketing plan and label ("tag")
Italo Vignoli wrote: > So, if you de-couple "rolling" from "release", and couple it with "idea" > or "object" you get the feeling of what could be the positioning if the > choice was "rolling" (very similar to "advance"). > Yes - and from the ESC minutes of last week: + idea: get the idea out, start discussing it more widely, and see how it goes (Michael M) + nothing would happen instantly, understand that it needs infrastructure, but want to start planning this (referring to necessary process adjustments, and the expressed need for automatic updates) I personally like 'Rolling' a lot, it just appears we can't pull it off for 7.1. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] [VOTE] LibreOffice 7.1 tag ("label")
Hi Lothar, Lothar K. Becker wrote: >The proposals, in ALPHABETICAL order, are as follows: > >a. Advance >b. Community >c. Rolling > My preference, in decreasing order: * Community * Rolling * Advance Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] [VOTE] LibreOffice 7.1 marketing plan
Lothar K. Becker wrote: >- APPROVAL of the 7.1 MARKETING PLAN, especially the ACTION ITEMS from the >aforementioned shared slides slide 27 onwards. > >- The board ASKS THE TEAM, especially the marketing group with Italo and >Mike, to WORK on the aforementioned ACTION ITEMS, as they are set forth in >the PDF. > >- The board ASKS THE TEAM, especially the marketing group with Italo and >Mike, to MONITOR results and RECEPTION of this marketing plan and its >action items, and COLLECT AND BRING FORWARD PROPOSALS FOR CHANGES, >REMOVALS AND ADDITIONS when necessary, especially in time for the NEXT >MAJOR RELEASES and/or snapshots, or the LATEST IN SIX MONTHS' TIME > +1 - broadly happy with the direction this is taking! Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] [DECISION] LibreOffice Online - repository and translations
Hi Lionel, Lionel Élie Mamane wrote: > On Wed, Dec 02, 2020 at 06:55:01PM +0100, Andreas Mantke wrote: > >> The Board of Directors at the time of voting consists of 7 seat > >> holders without deputies. In order to be quorate, the vote needs to > >> have 1/2 of the Board of Directors members, which gives 4. > > > as far as I know the statutes doesn't speak about a second vote of > > the Chairperson here. The vote of the Chairperson is only deciding > > in such case. > > I don't understand what you mean by "only deciding". Clearly, the > statutes (Satzung) intend for the Chairperson (Vorsitzender) or his > Deputy (Stellvertreter)) to act as a tie-break. Else the sentence > > In the event of a tied vote, the chairman, or as a substitute the > vice chairman, has the deciding vote. > > Bei Stimmengleichheit gibt die Stimme des Vorsitzenden, ersatzweise > seines Stellvertreters den Ausschlag. > > Is wholly without effect, as it can never have any effect in > practice. Can you please give a scenario where the fact that, in your > interpretation and understanding of the Statutes, the vote of > Chairperson being "deciding" leads to a decision that would not have > been reached without the "deciding" quality of the vote? > Yeah, I believe that was a misunderstanding. The quorum requirements where clearly met; after that simple majority of those present, plus tie-breaking rule applies. In a word, no need for a formal 4 votes in favour. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] [DECISION] LibreOffice Online - repository and translations
Hey Guilhem, Guilhem Moulin wrote: > Could the BoD clarify the short-term period and maybe even commit to > revisit the vote say, before the end of their term? > Though I cannot speak for the entire board, the above is my understanding at least (I'd say this needs revisiting the latest in early summer 2021). The proposal was made to buy us time to sort things out, not as a permanent setup. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] [VOTE] LibreOffice Online - repository and translations
Florian Effenberger wrote: > The vote that has been proposed is the following: > > 1. to freeze (not delete) the "online" repository at TDF's git, for the time > being > > 1b. to switch the https://github.com/libreoffice/online mirror to instead > mirror the Collabora repo, for the time being, and make sure we catch pull > requests there, e.g. via the mentoring alias on TDF side > > 2. to freeze (not delete) the translations for online in Weblate, for the > time being > +1 to all points. I'm convinced it's the least-worst short-term measure, and leaves the door open in all directions. Little clarification - the "freeze .. at TDF's git" refers to the gerrit repo. Cheers, -- Thorsten signature.asc Description: PGP signature
Proposal for a German fully-owned subsidiary (was: [board-discuss] Collecting proposals on TDF subsidiary)
Hi Flo, all, Florian Effenberger wrote: > The board is eager to get the discussion started, preferably on the public > board-discuss mailing list. > I'm somehow not able to add to that folder, so here's a separate share link: https://nextcloud.documentfoundation.org/s/TyRPPBJNsRkcdz8 Thanks to Uwe for doing the drafting with me; with TDF being based in Germany, it's kind of the most obvious thing to do. With my board hat on - would love to have perhaps one or two additional proposals, so there's actual choice? ;) Ultimately though, what I consider most important (with business rules largely comparable at least within the EU) - is who's going to be the persons running this entity. All the best, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Project vs product (and some comments to product itself)
Hi Telesto, all, Telesto wrote: > From internal perspective (so within the organization of TDF) > LibreOffice is viewed, managed, and functioning as a project. > and > LibreOffice for the end-user is pretty often associated with a > product. > True, that is a good description of the status quo. I cannot speak for Bjoern, but what resonated well with me is the "project over product" (or also called "community over code" elsewhere) line. Which says, to be successful in the long term, the advise is to generally favour community needs over user needs (and as a corollary, also focus marketing on attracting more contributors, rather than more users). And I agree with that approach. Of course, a sweet spot & a virtuous circle is when your community is motivated to build a great product; and in turn growing numbers of users of said product can be won as contributors. The discussion was not about that desirable state though, but for the case that there is a conflict. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] MCC questions ..
Hi *,
to comment on one aspect here for the moment:
Italo Vignoli wrote:
> I think the question is legitimate if you take away the last portion:
> "assuming the statutes can be tweaked". I do not see how the statutes
> can be tweaked, but I think that they can be applied with some added
> flexibility ("flexible" is different from "tweaked").
>
The statutes _can_ be modified, but the bar for that is relatively
high (for good reasons), plus the changes must not modify the original
intends and purposes:
- § 14 (1): The Board of Directors can make changes to the Articles of
Association provided that the changes do not affect the foundation’s
goals and do not substantially alter the original design of the
foundation or facilitate the fulfillment of the foundation’s goals.
- and any change has to be ratified (in essence cross-checked to
fulfil the above requirements) by the foundation authorities
All the best,
-- Thorsten
signature.asc
Description: PGP signature
Re: [board-discuss] Agenda for TDF board meeting on Friday, August 14th at 1300 Berlin time (UTC+2)
Hey Kev, thx a lot for taking the time & presenting your ideas during the board call on Friday! Kev M wrote: > The TDF could engage into a legal arrangement with the co-operative > that implies control of actions based on a contractual service > arrangement.. but theoretically the board of the co-op would be run > independently. If it's the case that the TDF must control the entity > then forming a co-op may be an overly complicated matter. > Yeah, as discussed - I guess for the immediate needs TDF has for a business entity, a cooperative would unnecessarily complicate matters. But - going forward their will be other & differently-structured challenges the community would want to tackle, and for that, a cooperative might well be a good match. And as Michael said during the board call, some more ptrs on how such a thing would look like in Canada, and also how a potential fully-owned subsidiary could be setup there, would be greatly appreciated! All the best, Thorsten -- Thorsten Behrens, Director, Member of the Board The Document Foundation, Kurfürstendamm 188, 10707 Berlin, Germany Rechtsfähige Stiftung des bürgerlichen Rechts Legal details: http://www.documentfoundation.org/imprint signature.asc Description: PGP signature
