Re: [DISCUSS] Re: [board-discuss] [VOTE] New proposal for hiring in-house developers.
hi Jean-Baptiste, On 02.12.22 19:21, Jean-Baptiste Faure wrote: Hi Thorsten, If the ESC is an official TDF committee, where are its statutes, its functioning rules and the rules of its members designation ? hmm i've wondered this too a while ago, i couldn't find a word in the TDF statutes about it :) If it is an official TDF committee, why its mailing list is not hosted by TDF ? due to the fact that it pre-dates the founding of TDF - it exists as long as the LibreOffice project - its mailing list is hosted on freedesktop.org. the address is: libreoff...@lists.freedesktop.org probably migrating the mailing list wasn't considered worth the hassle to subscribers? apparently it was called "tech steering" in the beginning? or at least the minutes claimed that was the name? h... the oldest minutes i can find also seem to abbreviate "action item" as "AA:" - that was still the case when i joined, those were the days :) no, found an even older minutes mail - the first one says "technical group" - dated 2010-09-28. https://lists.freedesktop.org/archives/libreoffice/2010-September/02.html (in case you want to send a mail to all ESC members, sorry but i don't know any more convenient way than to manually put them into the address field in your mail client...) regards, michael -- 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
[DISCUSS] Re: [board-discuss] [VOTE] New proposal for hiring in-house developers.
hi Stephan, On 02.12.22 11:12, Stephan Ficht wrote: Dear board, hi all, = Foreword: I here speak in my capacity as a Member of the Board of Trustees. = This part of the vote TDF will seek to hire a developer(s); - who will report [...], and consult weekly with the ESC, which will oversee the technical direction of the work; is in my opinion not acceptable. This results in TDF (the employer) paying for the staff but others will have the saying about their tasks. how is this different from TDF employees Cloph, Heiko, Hossein, Ilmari, Olivier, Stéphane, Sophie, and Xisco, who already consult weekly with the ESC? regards, michael -- 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] Agenda for TDF board meeting on Monday, October 31st at 1800 Berlin time (UTC+1)
hi Andreas, On 29.10.22 22:07, Andreas Mantke wrote: In additon: I reviewed the whole process about sending a project to the attic again. The proposal for the process seemed to neutral text, but it was only written and voted on for one subproject: LOOL. The only four members, which participated in the vote and agreed on the proposal, had all a CoI on the LibreOffice Online topic, except one. The three members had to stay away from the discussion and decision on this proposal, because of their CoI. Thus there were only one effective participation and vote on the proposal. Thus the proposal was not approved. Conclusion: there is also no approved basis for topic 7. but why do you stop at this step? if i count correctly, of the directors that approved various versions of the CoI policy, a majority of them either have subsequently restricted their actions due to potential CoI, or there is an investigation for potentially having a CoI ongoing at the moment. following your line of argument that the policy applies to decisions that lead to decisions where the policy applies, it's clear that none of them should have participated in discussing or voting on the CoI policy, since all of them have an obvious CoI with the CoI policy because it could potentially restrict their actions, and therefore the CoI policy has never been properly accepted for lack of quorum (4 directors). [board-discuss] [VOTE] Approve version 1.3.2 of the CoI policy https://www.mail-archive.com/board-discuss@documentfoundation.org/msg05506.html of 6 votes, 4 were by directors with potential CoI [board-discuss] [VOTE] Approve version 1.3.1 of the CoI policy https://www.mail-archive.com/board-discuss%40documentfoundation.org/msg05130.html of 5 votes, 3 were by directors with potential CoI in both cases, only 2 directors who don't have an interest in the CoI policy participated in the vote. best regards, michael -- 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: Please take personal conflict off-list (was: [board-discuss] Merged proposal for in-house developers at TDF)
hello Paolo, On 02.06.22 19:55, Paolo Vecchi wrote: > > Also thanks to Andreas comment about the ESC minutes I had a look at > last week and today's minutes and it seems like Michael Meeks is already > implementing his proposal, transposed mostly by copy/paste by Kendy in > his own proposal (which BTW hasn't been renamed yet), with some > unexplained urgency and without anyone informing the board. if memory serves (and i'm sorry to say i missed last week's meeting due to a public holiday), the ESC discussed this topic because there was an urgency expressed on this list [1] regarding the hiring of in-house developers/mentors by TDF. one of the questions with this plan is which problem domains the in-house developers would be working on, that is, which are the areas that are actively used but under-maintained currently, so that for example expertise in such areas could be considered when evaluating applicants. hence the question was brought to the ESC to draw on the experience of its members in diverse areas of the code base, and the ESC attempted to come up with a list of such under-maintained areas in a collective effort, in order to expedite the TDF hiring process. the current version of the list, imperfect and unfinished as it is, is public in the TDF Wiki. also there was a follow-up discussion on the public mailing list, with about half a dozen people with various backgrounds - including several community members who are not in the ESC - provided additional input that can been taken into account. in case the board no longer considers hiring to be urgent, or is not interested in advice prepared by the ESC and sourced from the developer community, i think the ESC (who i don't speak for, this is just my personal opinion) would be most happy to stop discussing this topic and come back to it at a later date; please advise us of your preference in this regard. best regards, michael [1] https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00540.html -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Draft text: an "attic" proposal - version 2.0
hi Andreas, On 14.03.22 18:36, Andreas Mantke wrote: and with the proposal the Android Viewer had to be put the attic and wouldn't currently get the chance to get out of this state (because only one developer looking for it). that's a bad example: the Android Viewer is in the core.git repository. there is no practical way to "move it to the attic" - in the hypothetical case, i'm pretty sure it would be considered too much effort to disentangle a dead project from core.git and there would just be a commit that deletes the code, as has happened for multiple large pieces of obsolete code in the past (just this year i happily deleted 2 WebDAV UCPs). -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
[board-discuss] Re: Draft document for TDF in-house developers proposal
On 25.02.22 15:43, Paolo Vecchi wrote: Hi Michael, thanks for your feedback. On 25/02/2022 10:22, Michael Meeks wrote: > In the graph above the committers have been grouped in Commercial > (companies specialised in selling LibreOffice development and > products), Corporate (companies and institutions contributing > voluntarily) I'm intrigued by this distinction; can you specify which entities are in which bucket and why ? The macro categories can be easily worked out but here they are: Commercial contributors: * Collabora * CIB->Allotropia Corporate contributors: * RedHat last i worked there, LibreOffice was a fully supported part of Red Hat Enterprise Linux that customers could and did file enhancement requests for. * Assigned (a bit of a mix but volumes don't change much the result) err, no: these are people who are not contributing as part of their employment, although they *may* be paid Google Summer of Code interns. the way it works is that or people who contribute at different times with different employers, their contributions for their employer are counted for their employer, while their contributions with no employer are counted as "Assigned". * NISZ * SIL * Munich Volunteers: * Unknown (no official affiliation) and TDF own contributions. > TDF has to develop a strategy which includes the employment > of internal developers which will both increase the speed of > development and will help with the on-boarding of new external > commercial, corporate and volunteer contributors. Why do you believe that in-house developers (vs. say mentors) will help with on-boarding new contributors if that is not their focus? My suspicion is that mentoring is hard and "doing it yourself" is superficially easy in the short term. As from previous answer: "Learning by doing (fixing bugs) will help those developers in helping others following the same path while getting rid of issues that commercial contributors and volunteers have overlooked." i think what Michael meant is: how do you get an experienced developer to spend 3 hours discussing a problem with a newbie spread across a longer time period and giving them hints to fix it and review their work, instead of simply fixing it themselves in a single session in half the time, if their job title is "developer" and not "mentor". > and the quantity of bugs, features and updates that may require > tendering or paid for services by the commercial contributors is > still so vast that it will not affect noticeably their income While it is true that there may be an inexhaustible amount of work and TDF will never reduce that by doing some of it, I'm not sure that is really relevant. Tendering has been used by TDF to help stimulate, diversify and sustain the commercial ecosystem around LibreOffice since the beginning. TDF has a fairly fixed amount of cash - if there is less of that to spend, that will have a non-trivial impact. The methods tested up to now to stimulate and diversify the number of more commercial contributors haven't brought the desired result as it seems like mostly 2 companies bid for those tenders so we'll have to work harder on it. how do you expect to grow the number of companies who bid for tenders if there are not more tenders? N companies bidding for a tender means that N companies spend significant time doing estimations, but N-1 companies get 0 income for that effort. Worse than that though is the possible for TDF to significantly harm the market for bug-fixing far in excess of any work it can do - by creating the idea that there is a "free" way to have issues addressed through political machination at TDF. I'm concerned by your comment as you seem to put in doubt the neutrality and the dedication to the wider community of TDF's team. Reading it in another way someone may even think that "political machination" tried to stop TDF to fully express its potential for serving the wider community. Naturally not many people came up with those thoughts so I guess they really aren't an area of concern for most. i guess you aren't familiar with the history of this project, but this was very common in OpenOffice.org times: when a beta was released, suddenly a bunch of people came out of the woodwork to complain very loudly on public lists why bug X or bug Y had not been fixed and how this could possibly be given that this bug is obviously so severe that the product is unusable. in many cases what happened then is that Sun fixed the bug before the release - a bug which was actually found by some enterprise user who deployed "free" OOo and paid a consultant to file the bug in IssueZilla and then make a noise about it, without paying any developer to actually fix the bug. -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems?
Re: [board-discuss] Drafting Tender "Cleanup & further improve ODF conformance"
hello again, On 03.02.22 14:30, Florian Effenberger wrote: Florian Effenberger wrote on 01.12.21 at 15:30: (3) Is it possible to get https://bugs.documentfoundation.org/show_bug.cgi?id=48392 ODF: Implementation for svg:linearGradient and svg:radialGradient is missing as explicit issue for "Required"? We had this already as suggestion "Multi-color gradient" in https://wiki.documentfoundation.org/Development/Budget2021 and now again in https://wiki.documentfoundation.org/Development/Budget2022 I've added it. Not sure, however, how much that would change the work/cost estimate of the tender. This is in the draft. We can add a similar note as mentioned above if we're unsure about the work required. so i've discussed this with Armin now and we noticed that this would be a *lot* of effort and really should be a separate tender, and the gradients are currently listed separately in the Wiki page. or, put another way, if you put the gradients into this tender there won't be any time to fix any other bug. regards, michael -- 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] Drafting Tender "Cleanup & further improve ODF conformance"
hi Florian, On 03.02.22 14:30, Florian Effenberger wrote: Hello everyone, the below mail is a bit older - Christmas break and some other tenders came in between, so I get to this only now. Florian Effenberger wrote on 01.12.21 at 15:30: (2) The search result from item "Required 2." contains Meta-issues. Expanding them results in 80 issues. Using Whiteboard as search criteria has no advantage compared to the Meta-issues. And I think both, Whitheboard search or Meta-issues, are not suitable for a tender, but a tender needs to list the issues explicitly. The list from Whiteboard search and Meta-issues needs to be examined and prioritized manually. This is taken from the specification at https://wiki.documentfoundation.org/Development/Budget2021#Cleanup_.26_further_improve_ODF_conformance I fear answering that question is beyond my skills. ;-) Does it make sense to bounce this question back to the ESC for further specification? Regina (thanks a lot!) sent a list of bugs back in December on the dev mailing list: https://lists.freedesktop.org/archives/libreoffice/2021-December/088210.html Was there any further discussion or feedback on this? If the list mentioned there is fine, I replace item 2 from the tender with it. If we're unsure whether that meets the budget or not, as the person days are listed in the tender, we can add a note along the lines of "Please propose a subset and prioritization of these bugs, that do not exceed the person days factored in for this tender, see below." thanks for reminding me, due to too much vacation i forgot but now i just provided some feedback about some of the issues to Regina. i haven't thought about how much time the selected issues would require yet, it's possible it might still be more than the budget which the BoD wants to spend, so i guess a fixed budget and then apply for a subset of the issues makes sense. Michael Stahl wrote on 03.11.21 at 10:49: the scope of this is quite large and unclear... *required* items are: 1. ODFAutoTests: addressing issues will be difficult because as Regina points out the web service appears to be offline. IIRC it's possible to run the tests offline, but currently i guess nobody knows how much work it is to set that up and what problems would actually be found, so i guess this item mostly amounts to "get ODFAutoTests to run at all". I've tried to rephrase #1 a bit, let me know if this is better. Is the current wording fine? i guess, as long as nobody interprets it to mean "set up a public website" :) -- 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] Drafting Tender "Cleanup & further improve ODF conformance"
On 29.10.21 08:32, Florian Effenberger wrote: Hello, one of the approved [1] tenders is the Tender "Cleanup & further improve ODF conformance" The board would like to work together in public with all of you on this tender before it gets officially published. The current draft is therefore shared at https://nextcloud.documentfoundation.org/s/ggqpciBK54rztJi The board is happy to get your feedback and proposals. We'd like to discuss this ideally in the board call after next, i.e. on Friday, November 19, at 1300 Berlin time. Please send your feedback to the public board-discuss@documentfoundation.org mailing list. the scope of this is quite large and unclear... *required* items are: 1. ODFAutoTests: addressing issues will be difficult because as Regina points out the web service appears to be offline. IIRC it's possible to run the tests offline, but currently i guess nobody knows how much work it is to set that up and what problems would actually be found, so i guess this item mostly amounts to "get ODFAutoTests to run at all". 2. odf_validation: * 37128 this is, errm, "interesting" problem and might take weeks to fix * 96066 likely needs specification work * 94768 cannot be solved with ODF 1.3, it needs specification work * 106934 needs specification work, possibly it was already added for ODF 1.4 * 131127 might be fixable? * 131148 needs specification work * 131159 this was added for ODF 1.4 * 108198 export meta-bug depending on 26 unfixed bugs, wow... * 94587 *import* meta-bug depending on 37 unfixed bugs - how does this have "odf_validation" keyword in the first place, i thought that applied only to the export filter? i would propose to remove "odf_validation" keyword and keep "odf". ... so i'm not sure what would make sense here, certainly *requiring* fixes of > 60 different bugs that are all over the map doesn't make sense to me, unless the board wants to spend the entire yearly budget... maybe everything should be "optional" and then applicants can list which bugs they think are actually possible to fix given the current ODF 1.3 specification? -- 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] Drafting Tender "Cleanup & further improve ODF conformance"
On 29.10.21 14:57, Regina Henschel wrote: Hi Florian, (1) The link http://autotests.opendocumentformat.org from item "Required 1." does not work. Do you have another reference for ODFAutoTests? the git repo is here: https://gitlab.com/odfplugfest/odfautotests but it does look quite inactive, with the last commit in 2015. possibly Jos van den Oever knows more... -- 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] TDF Budget 2021
On 25.03.21 09:52, Ilmari Lauhakangas wrote: On 25.3.2021 8.58, Ilmari Lauhakangas wrote: On 24.3.2021 20.46, Andreas Mantke wrote: Thus TDF has to evaluate the reasons for this poor execution and make improvements (especially for the time after the corona pandemic). If TDF will dodge on this topic, there will be from my opinion no valid reason to complain about a 'shortage' of volunteers in the LibreOffice project. I can't say I recognise your description as in 2021 alone I have onboarded over 130 volunteers and I'm not the only one doing this sort of thing. I have to correct myself: in 2021 I have onboarded 58 volunteers and in 2020 84 volunteers. Ilmari thanks Ilmari, i think it's great to have TDF staff onboarding volunteers :) -- 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] Discussion about options available with marketing plan draft and timetable
On 09.07.20 18:19, Andreas Mantke wrote: and there are three reasons, why TDF is "Gemeinnützig": * der Volks- und Berufsbildung, * der Wissenschaft und Forschung, insbesondere auf dem Gebiet der Informatik, * des bürgerschaftlichen Engagements zugunsten gemeinnütziger Zwecke. (non binding English translation: * Public and professional education * Science and research, particularly in the field of computer science * Civic engagement for non-profit purposes) There is nothing in this lines about the promotion of an ecosystem of service providers (etc.). i don't believe anybody is claiming that promotion of an ecosystem of service providers should be a *goal* of TDF - what i understand is being claimed is that it can be a good *means*, a tool to eventually help reach the actual defined goals of TDF to a fuller extent, and the proposed marketing plan is a way to increase the ... leverage(?) ... of the means/tool. -- 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] How is TDC compelled to keep the user first?
On 28.02.20 15:04, Brett Cornwall wrote: Other Free Software projects have had for-profit entities created underneath the stewardship of a non-profit; Mozilla Corporation and Canonical are two living examples. Sacrifices to user empowerment are off-topic, but: how is Canonical related to any non-profit? https://en.wikipedia.org/wiki/Canonical_Ltd doesn't mention anything. 3. What assurances does TDF offer that assuage fears that the lifeblood of LibreOffice will pivot from one of community involvement to one of company culture (with community involvement as a PR spin)? what exactly do you mean? the majority of bugfixes and new features already come from developers employed by companies such as Red Hat, Collabora, CIB, and this has been the case for most of the existence of the project. of course most if not all of the developers employed by these companies consider themselves members of the LO community, and why shouldn't they? -- 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] Apache ODF Toolkit migration
hi Dennis, On 28.11.18 12:49, Dennis Roczek wrote: On 28.11.2018 11:00, Michael Meeks wrote: 2. the web site, in SVN (will also be changed to read-only): https://svn.apache.org/repos/asf/incubator/odf/site/ the SVN repo contains some MarkDown files that are converted to ... presumably there should be a way to preserve the (relatively small and simple) content of the repo to either Wiki markup, or something that some other MarkDown-to-HTML tool can understand; volunteers are certainly welcome to help with this. Sounds sensible - what is the scale of the problem: how many lines/tags of markdown ? so most of the SVN repo is binary releases, and generated JavaDoc documentation. there are 10570 lines worth of files with ".mdtext" suffix. there are converters (see https://stackoverflow.com/questions/9824489/any-markdown-to-wikimarkup-converter-available ) so especially pandoc. sounds promising. I offer the help for the MWiki migration. ;-) thanks for the offer, much appreciated :) from my point of view, having most of the site in Wiki would be easiest to maintain, except perhaps for the release download page. regards, michael -- 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] Apache ODF Toolkit migration
thanks Simon, Michael, Thorsten for the support! i suppose we should wait for a formal decision of the TDF board before proceeding with the migration. On 28.11.18 12:37, Simon Phipps wrote: Hi! On Wed, Nov 28, 2018 at 11:12 AM Thorsten Behrens mailto:t...@documentfoundation.org>> wrote: Michael Meeks wrote: > On 28/11/2018 09:40, Michael Stahl wrote: > > so i'll propose to migrate the ODF Toolkit to The Document Foundation. > > Seems like something the BoD should vote on, In general, subject to the > marketing concerns at the end, it seems like a good idea to me. I assume > there are no current contributors to be upset either way. > Indeed, very supportive of that idea. I'd be quite happy if the ASF would formally agree handing this over to TDF. I agree. I would be very pleased for TDF to host this as a service, and would prefer that it happened with the co-operation of the ASF. S. -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
[board-discuss] Apache ODF Toolkit migration
hello TDF folks, hello ODF Toolkit community, i'm writing here as a Committer (fwiw) of the Apache ODF Toolkit (incubating) project. it turns out the ASF has voted to rename the Apache ODF Toolkit (incubating) project to Apache ODF Toolkit (retired). https://lists.apache.org/thread.html/d4b4b33470a7bc3e70dc6192527168bb5907810045df5453c784cc93@%3Codf-dev.incubator.apache.org%3E https://mail-archives.apache.org/mod_mbox/incubator-general/201811.mbox/%3cca61fcd0-ff43-4e4a-bc30-5a942ae53...@comcast.net%3e the ODF Toolkit project is important for the ODF ecosystem in general and for LibreOffice in particular, since it contains not only the ODFDOM Java library, but also the most accurate ODF Validator, which we use in the LibreOffice test suite to check the ODF export filter. so i'll propose to migrate the ODF Toolkit to The Document Foundation. this is my (probably incomplete) understanding of the various different parts of the project that need some action: 1. git: the repository of record is on GitHub, and will be changed to read-only by the ASF: https://github.com/apache/odftoolkit the obvious options are: a) move the git repository to gerrit.libreoffice.org b) fork the GitHub project and continue hosting on GitHub In any case, we should have a redirect from the old incubator project to the new sources (perhaps a big red notice in README will be enough?). 2. the web site, in SVN (will also be changed to read-only): https://svn.apache.org/repos/asf/incubator/odf/site/ the SVN repo contains some MarkDown files that are converted to static HTML by some mysterious ASF-grown tool (Svante claims that Perl scripts that rewrite references and a custom CMS are involved somehow) that doesn't talk to anything other than the ASF SVN server and which nobody in the ODF Toolkit project understands. presumably there should be a way to preserve the (relatively small and simple) content of the repo to either Wiki markup, or something that some other MarkDown-to-HTML tool can understand; volunteers are certainly welcome to help with this. for a quick start it could also be an option to scrape the existing HTML from http://incubator.apache.org/odftoolkit/ and replace the internal URLs for consistency... 3. the domain "odftoolkit.org" - this currently redirects to "http://incubator.apache.org/odftoolkit/; this domain would need to be transferred from ASF to TDF before it expires. (i don't know whether other domains related to ODF Toolkit exist; apparently "odftoolkit.com" was registered at some time but it's already expired/for sale) 4. mailing list: the "odf-...@incubator.apache.org" will be retired; probably the amount of traffic is going to be quite small, hence suggest to just use "libreoff...@freedesktop.org" for now; if the traffic increases and becomes a problem a dedicated list can be set up later. 5. currently the ASF JIRA is used as bug tracker, with project "ODFTOOLKIT": https://issues.apache.org/jira/browse/ODFTOOLKIT-479?jql=project%20%3D%20ODFTOOLKIT there are currently 137 issues that are neither RESOLVED nor CLOSED. so there are 2 decisions to be made here: a) do we want a new component in "bugs.documentfoundation.org" Bugzilla, or use GitHub issues (only makes sense if GitHub is used for the repo, of course) b) should open issues be migrated? as long as they will be accessible read-only in ASF JIRA (and i don't see any reason why not), i don't see much value in it, since there aren't currently developers available with time to fix the issues; if anybody feels strongly about their issue they can re-create/copy it over manually. another point that we should probably discuss after the migration is finished is whether the so-called "Simple API" should be removed from ODFDOM due to being duplicative and unmaintained for years. regards, michael PS: thanks to Svante for proofreading this, if any errors remain it's my fault -- 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
