Re: Ambiguous paths for module hunspell
On Sat, Oct 27, 2012 at 5:49 PM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, Am 27.10.12 08:03, schrieb Ian C: Hi, I saw a post back in Aug 4 where Pedro had build -- version: 275224 Ambiguous paths for module hunspell: I just updated my svn and get the same thing. Anyone have a solution? Yes :-) the folder/module hunspell is moved from folder /main to /ext_libraries. The folder hunspell in folder /main is not deleted by an svn update, if it contains the output files from a previous build. Thus, just delete the folder hunspell in folder /main manually and it should be working again. Excellent, thanks. That has gone, but now it seems to be looking for rtlbootstrap.mk make: makefile.mk: line 29: Error: -- Include file snip/ooo/main/solver/350/unxlngx6.pro/inc/rtlbootstrap.mk, not found ERROR: error 65280 occurred while making snip/ooo/main/instsetoo_native/inc_openoffice/unix I just ran configure, bootstrap, sourced the sh file, changed to instsetoo_native/ and ran build (no arguments seems to give more output) Last time I ran build I added -all -P4 -- P4 to get some parallel processing and threading. This is a Fedora build by the way. Best regards, Oliver. -- Cheers, Ian C
Re: [PROPOSAL] Initiate a Contest for Branding of 4.0
On 26/10/2012 Ian Lynch wrote: I arranged one for the OOo schools mascot ... The winner was clear-cut. A 16 year old Italian boy who aspired to be a graphic designer. Here he is (by chance, he's called Andrea too): http://www.openoffice.org/editorial/interview_andrea_maggioni.html (EN) http://www.openoffice.org/it/stampa/comunicati/avv12.html (IT) A quick web search shows that in the end he managed to become a graphic designer indeed! The mascot is at the end of http://www.openoffice.org/marketing/education/schools/ but it didn't have that much recognition in the end. Indeed, as Ian pointed out, the main value of that competition was in getting media exposure; while in this (OpenOffice 4.0 visual identity) competition we will probably want both media exposure and a professional outcome, so a clear RFP (Request for proposal) as Graham proposes will help and it is an excellent first step. Regards, Andrea.
Re: Apache and ODF
On Thursday, October 25, 2012 21:14:19 Rob Weir wrote: On Thu, Oct 25, 2012 at 2:24 PM, Andreas Säger ville...@t-online.de wrote: Hi, Today my wife got her new Kindle which comes with a document viewer based on Apache Freetype for the rendering job and Apache POI which is a Java library to parse Microsoft documents. It handles doc(x)/xls(x)/ppt(x) but no ODF. Although I am not deeply involved in this project, I feel somewhat embarrassed and alarmed because in the year 2012 the Apache foundation develops excellent tools to process proprietary file formats but fails to offer anything equivalent for the free and much simpler ODF standard. Is my assumption correct that http://incubator.apache.org/odftoolkit/ would be the remedy to solve that problem but due to a lack of development resources it is not ready for the job? The ODF Toolkit is a Java library for manipulating ODF documents. A classic use would be document automation, e.g., taking a document template and filling in data from a database, to create a new ODF document. It does this all without any GUI, no OpenOffice required. It is not an editor, not a viewer. It has no rendering, layout or calculation logic. It operates directly on the document file. So ordinarily I'd say that this was not appropriate for a document viewer, certainly not without a layout engine. But on something like the Kindle, with relatively simple layout requirements, the ODF Toolkit would be analogous to POI, and would make the task far easier. If you search for it, you will find various solutions for converting ODF to EPub. But I have not seen something that does the same for Kindle's MOBI format. -Rob Greetings, Andreas Säger Calligra Author and Calligra Words 2.6 that will be released as beta in next week has both a new Epub2 and a MOBI export. This is done because of the new Calligra Author application that is aimed especially at creating ebooks. Upcoming versions will also have Epub3 support with dynamic contents.
Re: extensions and translations.
On Sat, Oct 27, 2012 at 10:27:34AM +0200, jan iversen wrote: I agree with you, we should NOT put a new framework on extensions writer. I was thinking along the lines of make a new directory ./extras/extensions/source, with files extension name.known extension This will force the extension developer to release that file under the ALv2, because only ALv2 code can be committed. Regards -- Ariel Constenla-Haile La Plata, Argentina pgpkFslOjxwNG.pgp Description: PGP signature
Re: Ambiguous paths for module hunspell
On Sat, Oct 27, 2012 at 06:16:08PM +0800, Ian C wrote: I just ran configure, bootstrap, sourced the sh file, changed to instsetoo_native/ and ran build (no arguments seems to give more output) Last time I ran build I added -all -P4 -- P4 to get some parallel processing and threading. you should run build --all in instsetoo_native/ or build --from the module that broke. See http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO#Building_2 Regards -- Ariel Constenla-Haile La Plata, Argentina pgpCuDRFyZPcm.pgp Description: PGP signature
Re: [DISCUSS] Cleanup installation files, make them more modular
2012/10/27 Joost Andrae joost.and...@gmx.de Hi Marcus, Am 26.10.2012 23:06, schrieb Marcus (OOo): I've modified the subject as I think this topic deserves its own, new thread. that is a good idea. Am 10/26/2012 07:28 PM, schrieb Ariel Constenla-Haile: On Wed, Oct 24, 2012 at 05:27:41PM +0200, Jürgen Schmidt wrote: Once thing to pay attention for the next release is the increasing size: more than 14 Gb for Linux packages only. This is going to be even more, as more languages are added. INFRA has already complained after the first release (can't find the message right now) about the size of our dist/ folder, so we must think about a solution, before they complain once the next release is uploaded. IMHO you can think and try whatever you want. At the end there is only one solution: Cleanup the packaging, delete redundat files, rearrange how the install files will be packed, think new how the installation on the users-side could be done. I have some items to add: - The installer packages should be modulized to allow the selection of parts (already done but we shouldn't forget to work on this) - Localizations should be separated from the binaries (soffice.bin, libs, resfiles). Maybe it's a good idea to separate language packs from the installer and that localizations are not part of the base installation package (this can solve parts of the INFRA issues) - The installer structure should allow small updatable packages (we already had this for MSI, MSP files). We should think about designing a more heterogenous approach for introducing a patch based update process. - Documentation might be divided into parts that link to the soffice instance (via HelpIDs) and into parts that allow intermediate updates without interfering with the application logic. This would allow a continous development process for those who like to work on documentation items. Just my 2 Euro Cents... Joost Last week there was an user on the ES forums with a particular problem: he was trying to install AOO in a school on a really old machine without network connection (no internet, no internal net, nothing) that runs Linux and needed to donwload (and burn into a CD) the right AOO version on a Windows machine. How such theoretical installer will manage those situations? Yes, this particular user is a corner case but it is quite easy to think about *many* corner cases... for example: - Such installer should be multi platform, something like a java based app, BUT can we presume that all systems have a java virtual machine working? While this is usually true on Linux, it is not so true on Windows or Mac. - How such installer will integrate with package managers on Linux? This is a problem not only with rpm and deb, the currently supported packages, but also with sabayon's entropy, with pardus' PiSi system... - ... While a new packaging system is an interesting idea, we need to be *really* careful to not left many users outside it. Regards Ricardo
Re: extensions and translations.
Got it, as Marcus explained, this is not a path to follow, but now I can write in my document that is has been discussed. jan On 27 October 2012 14:47, Ariel Constenla-Haile arie...@apache.org wrote: On Sat, Oct 27, 2012 at 10:27:34AM +0200, jan iversen wrote: I agree with you, we should NOT put a new framework on extensions writer. I was thinking along the lines of make a new directory ./extras/extensions/source, with files extension name.known extension This will force the extension developer to release that file under the ALv2, because only ALv2 code can be committed. Regards -- Ariel Constenla-Haile La Plata, Argentina
Re: [DISCUSS] Cleanup installation files, make them more modular
Hi, I have some items to add: - The installer packages should be modulized to allow the selection of parts (already done but we shouldn't forget to work on this) - Localizations should be separated from the binaries (soffice.bin, libs, resfiles). Maybe it's a good idea to separate language packs from the installer and that localizations are not part of the base installation package (this can solve parts of the INFRA issues) - The installer structure should allow small updatable packages (we already had this for MSI, MSP files). We should think about designing a more heterogenous approach for introducing a patch based update process. - Documentation might be divided into parts that link to the soffice instance (via HelpIDs) and into parts that allow intermediate updates without interfering with the application logic. This would allow a continous development process for those who like to work on documentation items. Just my 2 Euro Cents... Joost Last week there was an user on the ES forums with a particular problem: he was trying to install AOO in a school on a really old machine without network connection (no internet, no internal net, nothing) that runs Linux and needed to donwload (and burn into a CD) the right AOO version on a Windows machine. How such theoretical installer will manage those situations? Yes, this particular user is a corner case but it is quite easy to think about *many* corner cases... for example: - Such installer should be multi platform, something like a java based app, BUT can we presume that all systems have a java virtual machine working? While this is usually true on Linux, it is not so true on Windows or Mac. - How such installer will integrate with package managers on Linux? This is a problem not only with rpm and deb, the currently supported packages, but also with sabayon's entropy, with pardus' PiSi system... yes, the Linux package management is a nightmare and the only way to work-around this is to provide packages that don't make use of it... Joking aside, using system packages is needed to be available for distribution applications that manage the rollout within a network (LAN, WAN). And I belive there is already some kind of patch management on Linux, Solaris, FreeBSD and on MacOS available that is comparable to the MSP approach on Windows based systems. Unfortunately on Linux we have several packaging systems (.deb, rpm, etc.) that we need to take care of. On Linux there's another thing that needs attention that's the desktop system integration which differs from distribution to distribution and it's really a nightmare because some distros provide diverse frameworks like Gnome, KDE, etc. that need their own integration. This could be one thing that could be out-sourced into extra packages that a Linux user can download for his/her distribution additionally to the base installation package. Kind regards, Joost
Re: [RELEASE] Releasing new languages for 3.4.1
On 26/10/2012 jan iversen wrote: On 26 October 2012 19:43, Andrea Pescetti wrote: - Releasing a new language is totally risk-free: a new language can't break functionality in OpenOffice, while any feature could have bugs and needs more qualified testing. I do not agree to that statement for two reasons - a bad translations will influence the reputation of AOO in that language zone. - Wrong translation of e.g. accelerators, might not break the product technically speaking, but for sure the end-user will experience it as non-functioning. We can do worse as Marcus remembered (and actually we once managed to completely break styles in an Italian release candidate by translating Header and Heading with the same Italian word), but that was not my point. I meant that any damage a translation can do is self-contained: adding a translation will not pose any risk to the English (or other) version of OpenOffice (in other words: I can update the Danish language resources, rebuild and be sure that this does not introduce bugs in the English version). As for testing translations, this goes without saying: for sure we want to distribute only languages that have been tested. We used to have acceptance tests that every N-L team would run on the localized build to give green light for its distribution. The release voting is now different, but I would still expect that we test every language at least at a very basic level. release cycle of quarterly releases (every 3 or 4 months)? This could be a solution too. In this case we would have the problem of choosing what to translate - I think it would be nice to give translators an early start possibility, giving them a choice of working late after freeze or taking parts now with the risk that new messages are added. OK, from this and other comments it seems that the cleanest solution would be to establish a translation deadline (say, near the end of November, but this is purely hypothetical), incorporate all available translations and make a build available a few days later, give one week (or whatever appropriate) for feedback, then release a 3.4.2 with the standard process upon positive feedback. This would avoid creative solutions like publishing patched sources or working around the Apache release process. The 3.4.2 would of course be released from the AOO34 branch, with the new language resources and maybe a few cherry-picked bugfixes. Regards, Andrea.
Re: The Impossible Question
On Fri, Oct 26, 2012 at 4:57 PM, Dave Fisher dave2w...@comcast.net wrote: On Oct 26, 2012, at 2:06 PM, Louis Suárez-Potts wrote: Hi Every now and then a user finds the experience of downloading, installing, using AOO disappointing and frankly frustrating if not worse. They will usually go to the user forums, but sometimes they will contact the Apache Foundation directly. Okay, but this does not really help them. What we did with OpenOffice was set up a Support page, which has since been moved to here, http://www.openoffice.org/support/. It's pretty much an improved version of the old but of course the ecosystem needs further fleshing out—it suffers from a lack of substantial existence. I'm also not persuaded that the route to it from either the application download page or homepage or wherever is redundantly clear enough for the befuddled enduser who installs AOO to replace his or her whatever suite and doesn't really know where to go….. So, my query is the usual impossible question: What can we do to make it clearer to the puzzled and frustrated how to get help? Sure, we can have a knowledge base (kb), FAQ, etc., and also enthusiastic community members. But what would you suggest as a path, or paths for the user? I personally would include something in the installation sets that point to the support page above; but also banners, say, or tags, stickers—glaringly obvious neon coloured blinking lights?—to relay users to useful pages. Ideas? We could emulate a version of what the ASF does to highlight the many projects. Take a look at www.apache.org - you will see a feature project section. Perhaps on www.openoffice.org we can add a Featured Support Question / Language / News. This would be backed by an xml file of FAQs, Languages and News which would randomly be selected every day and republished to the front page. hmmm...an interesting idea. This would be easier to implement if our items were in a DB of some sort. Otherwise I'm clueless has to how we could realistically do this. Regards, Dave Yeah, I got to thinking more after I posted this yesterday. For starters, maybe we should put together a Support FAQ or Problem Shortlist and link that prominently on the support page. This would take some time to cull through issues, but I think we already have a pretty good idea about what some of these are. I'm thinking of a rather short list here -- like maybe 10 - 20 items. Also, what about the Support page. Is the order of items OK. If not, what should they be? Thanks Louis -- MzK Anyone who considers protocol unimportant has never dealt with a cat. -- Robert Heinlein
Re: The Impossible Question
On 12-10-27, at 13:05 , Kay Schenk kay.sch...@gmail.com wrote: Also, what about the Support page. Is the order of items OK. If not, what should they be? The order there is totally up for grabs and there is no reason in that page's case to abide by precedent (just the expectation that others probably have of how things ought to be laid out—but even here, that is a little up in the air, if not cloud). It was cobbled together by several, and the work they did was superb—thanks! But expectations have changed and so have what can or ought to be listed there. Originally, the page was conceived using the old CollabNet static pages. That was a while ago, and in that while, we've come to use the New Millennium's technology. -louis
Re: The Impossible Question
On Sat, Oct 27, 2012 at 2:08 PM, Louis Suárez-Potts lui...@gmail.com wrote: On 12-10-27, at 13:05 , Kay Schenk kay.sch...@gmail.com wrote: Also, what about the Support page. Is the order of items OK. If not, what should they be? The order there is totally up for grabs and there is no reason in that page's case to abide by precedent (just the expectation that others probably have of how things ought to be laid out—but even here, that is a little up in the air, if not cloud). It was cobbled together by several, and the work they did was superb—thanks! But expectations have changed and so have what can or ought to be listed there. Louis, it sounds like you are almost saying something, but not quite. Could you be more specific, or give an example? Thanks! -Rob Originally, the page was conceived using the old CollabNet static pages. That was a while ago, and in that while, we've come to use the New Millennium's technology. -louis
Re: the presentation program keeps losing my pages
Grant McPeetie wrote: I have used the impress program to produce two presentations for my work as a teacher. The first time, it ate fifteen pages. I loaded it on a more powerful machine and I can’t account for three missing pages. I save my work all the time, even though it autosaves, and I deleted only one page myself. The thumbnails show the wrong pictures. If you drag and drop a page that’s out of order, sometimes it just vanishes. ... I have used open office forever and I’ve never needed to contact you prior to these problems. Hi, this is a very uncommon report: but indeed OpenOffice Impress has a new slide management functionality; if you installed an old beta, this functionality was still incomplete there and occasionally it would lead to instability and crashes, at least on my system. But if you installed the official version from http://www.openoffice.org/ then it should be robust and stable as usual. What you might have missed is that in the Normal view there is now a pop-up interface that allows you to hide a slide (just move the mouse over a thumbnail); hidden slides are not deleted, but they won't appear if you run your presentation. Since it was an upgrade, a common advice we give to people who upgrade and report problems is to reset their user profile; you just need to rename a folder, see http://forum.openoffice.org/en/forum/viewtopic.php?t=12426#p58403 for more information. Regards, Andrea.
Re: proposal for new l10n workflow
Based on the comments I have received, I have updated the document. The major changes are: - removed l10n web page tools - no auto-commit in any tools - proposed changes to pootle server (based on request from andrea, to use/change existing tools) - added more text on the translation workflow, inkl. local teams The document is available as pdf: http://wiki.openoffice.org/wiki/File:L10procNew2.pdf and (due to a polite hint) as a wiki page: http://wiki.openoffice.org/wiki/Localization_AOO/new_proposal Furthermore a projectplan is available as a wiki page: http://wiki.openoffice.org/wiki/Localization_AOO/workPlan this mail is posted on both ooo-L10n and ooo-dev, but please use ooo-dev for discussions. Andrea: I hope you have time to see if your suggestions are well represented now, so this document could be used as discussion basis when you meet the pootle people. Have a nice evening. jan I. On 25 October 2012 23:01, Andrea Pescetti pesce...@apache.org wrote: On 21/10/2012 jan iversen wrote: I have finally finished my proposal for a new workflow. please have a look at: http://wiki.openoffice.org/**wiki/File:L10procNew.pdfhttp://wiki.openoffice.org/wiki/File:L10procNew.pdf It seems I'm the first one who replies after having read your document in full. And the quality of your proposal is not the issue here: on the contrary, it is a very good one and I'm answering in detail below. So the issue must be somewhere else. I'm confident you will understand that I'm not criticizing or lecturing you here, and I'm not implying any of the items below to be you fault (none is); but maybe this will help you in getting better feedback in future. 1) Unfortunate timing. We've just graduated, the Apache Conference is coming in about one week, we need to relocate all infrastructure... It's a busy period, so we may be less responsive than usual. 2) Excess of communication. If all people on this list had written as much as you did in the last 24 hours to the OpenOffice lists, ooo-dev would have received a message every 9 seconds! If you make yourself manageable it will be easier for us to answer your requests with less confusion. 3) Dispersion of communication. Discussion about your proposal is scattered in three different threads across ooo-dev and ooo-l10n (not counting private e-mails); if you need to send a message to multiple lists, and this is a good example, it's best to send one message to two lists (and specify which one should receive answers) since answers will be grouped in the same discussion for people who are reading e-mail by discussions. 4) Proposal format. Uploading a PDF is very convenient but it does not make others feel empowered to really contribute. I would have applied a dozen typo fixes to your proposal if it had been available as a wiki page. Others might have done the same. OK, enough said. The proposal has significant merit, so let's focus on that for the rest of this message. It won't be short: it's still a 20-page document. The main reasons to drive it forward are: - It puts us back in total control of the l10n process, with no need to rely on partially broken or lost tools. - It reduces the number of steps strings must go through for being translated and imported back. - It automates a number of operations that have been manual so far. - It allows to have a proper version control for translations. In general, I think the document would benefit from some knowledge about how the process works with established teams: - There is a string freeze date in the release schedule (this concept needn't be taken away: for sure we still want a string freeze even if tools allow a continuous localization; translators shouldn't have the surprise to see new strings appear in the last weeks before a release) - After string freeze, strings are made available in Pootle (and this happens automatically in your proposal) - Volunteers pick a file, usually a help file and the main application related to it (so, the sw module for Writer and its help file; and, answering another message from you, the subdivision you propose would be OK). Here indeed it is helpful to know that a file has been taken, something that volunteers track manually at the moment. Volunteers do not have time constraints and may well take two weeks to complete their assignments: the 4 days you propose are not realistic for most teams. - Nobody works on Pootle. This has nothing to do with rights, it is totally incorrect to see Pootle as the committers tool. The Pootle server used to be slow and not responsive and anyway, as a matter of fact, most people, including me, prefer to work with downloaded files. - Volunteers mark all strings they touched as fuzzy to distinguish them; if I understand correctly, a XLIFF based workflow here would suggest to mark the strings as to be reviewed. - Other volunteers (in general one person per language) review the translations, collect all
Re: The Impossible Question
On Sat, Oct 27, 2012 at 11:57 AM, Rob Weir robw...@apache.org wrote: On Fri, Oct 26, 2012 at 7:57 PM, Dave Fisher dave2w...@comcast.net wrote: On Oct 26, 2012, at 2:06 PM, Louis Suárez-Potts wrote: Hi Every now and then a user finds the experience of downloading, installing, using AOO disappointing and frankly frustrating if not worse. They will usually go to the user forums, but sometimes they will contact the Apache Foundation directly. Okay, but this does not really help them. What we did with OpenOffice was set up a Support page, which has since been moved to here, http://www.openoffice.org/support/. It's pretty much an improved version of the old but of course the ecosystem needs further fleshing out—it suffers from a lack of substantial existence. I'm also not persuaded that the route to it from either the application download page or homepage or wherever is redundantly clear enough for the befuddled enduser who installs AOO to replace his or her whatever suite and doesn't really know where to go….. So, my query is the usual impossible question: What can we do to make it clearer to the puzzled and frustrated how to get help? Sure, we can have a knowledge base (kb), FAQ, etc., and also enthusiastic community members. But what would you suggest as a path, or paths for the user? I personally would include something in the installation sets that point to the support page above; but also banners, say, or tags, stickers—glaringly obvious neon coloured blinking lights?—to relay users to useful pages. Ideas? We could emulate a version of what the ASF does to highlight the many projects. Take a look at www.apache.org - you will see a feature project section. Perhaps on www.openoffice.org we can add a Featured Support Question / Language / News. This would be backed by an xml file of FAQs, Languages and News which would randomly be selected every day and republished to the front page. I like the idea in general, but from a support perspective I think we need to get the feed down to the client. Why? Because users have no current reason to visit www.openoffice.org homepage on a regular basis. It is not really a necessary place for them to visit, once they've downloaded. Most users just want to get their work done. They don't have any emotional attachment to AOO. It is just a tool. If they are thinking about their tools rather then their work, then something is probably wrong. This is not sexy, Apple-like technology that users go gooey over. It is a good day that a user thinks about their document, but not about their word processor. The task is in the forefront, the tool recedes into the background, like any good tool an extension of the user. Well, that's one ideal, at least. So in terms of priorities, we should want: 1) Fewer bugs, not more bug FAQ's 2) Less need for support, not a more prominent support page Well this is the ideal of course. In some cases though, what a user already has running on their system may be a major culprit and something we can't control or deal with easily (yep! I spent a number of years in User Support as well). 3) More quick avenues for self-help rather than hard-to-scale support offerings 4) More skill-building pages, ways user can become more productive with the tools. We could make a destination that users would actually visit if we could pull together solid content on power tips, extensions reviews, lists of topical templates (for holidays, tax time, etc.). -Rob I don't know ANYTHING about how the Help (the Support menu item) pages for AOO are constructed (maybe time I learned?). There's already a LOT of information under Common Help Topics. But, maybe we need to spend some time revisiting this area and see if the topics still meet current needs (in the product itself). Some of the issues that have been reported recently are very odd but maybe there's a reason. This would be the most direct route for the end user I assume. Regards, Dave Thanks Louis -- MzK Anyone who considers protocol unimportant has never dealt with a cat. -- Robert Heinlein
Re: [PROPOSAL] difficulty field for Bugzilla
On Fri, Oct 26, 2012 at 3:09 PM, Rob Weir robw...@apache.org wrote: On Fri, Oct 26, 2012 at 5:28 PM, Kay Schenk kay.sch...@gmail.com wrote: On 10/26/2012 07:26 AM, Rob Weir wrote: On Fri, Oct 26, 2012 at 3:47 AM, Andre Fischer awf@gmail.com wrote: On 24.10.2012 22:28, Dennis E. Hamilton wrote: @Regina, Yes, Wizard is a reference to the level of mastery that a solver must possess, and is one of those which one of these words does not belong solutions. There is a well-known *logarithmic* difficulty scale that has been used over 40 years for problem difficulty. It might be worth adapting: (after unknown), 00 easy - immediately solvable by someone willing to do it 10 simple - takes minutes 20 medium, average - quarter hour 30 moderate, an evening 40 difficult, challenging, non-trivial (term project, GSoC...) 50 unsolved, deep, requires a breakthrough, research (PhD dissertation) 60 intractable (that I just made up - probably not something that is technically feasible regardless of skill, Nobel Prize, P = NP, etc.) Is this not similar to what Knuth used (uses) in his Art of Computer Programming series? It reminds me of Knuth as well. In any case, I've added the new field, using the above scale, but changing unsolved to research, since all open bugs are unsolved in some sense. -Rob Rob, Will you be updating the information/instructions on: http://wiki.openoffice.org/wiki/QA/HowToFileIssue with this new field? I don't think the average bug reporter has any idea whether something is an easy fix or not. Only a developer would know this. And developers don't read pages with names like 'How to file a good Issue ;-) But I will document as part of the new volunteer orientation stuff I'm writing up. There are a number of pieces that I need to connect together -- the new volunteers directory, the new orientation modules, the BZ difficulty field, etc. Hopefully I can get this ready to launch soon. OK, I know what you're saying...the thing is this will be a field the reporter can access, correct? They *may* put something in or wonder what they should use. I just think for completeness it should be included. and thanks for all of this... -Rob -Andre -- MzK Anyone who considers protocol unimportant has never dealt with a cat. -- Robert Heinlein -- MzK Anyone who considers protocol unimportant has never dealt with a cat. -- Robert Heinlein
Re: volunteering
On 10/27/2012 02:00 PM, Prabha Chidambaran wrote: Hello Apache: My name is Prabha Chidambaran and I live in New Jersey. I am an aspiring technical writer and would love to get involved in writing documentation and help guides for your website. I have a Master's degree from Rutgers University and I have some background in journalism. I am very comfortable with MS Office and familiar with MS Access. I'd be thrilled if I could help you all in the writing parts. Thank you so much, Prabha Hello Prabha -- We can certainly use your skills as a technical writer in the project. There are basically two forms of documentation that we maintain/support -- volunteer material on the Documentation area of the wiki, and an ongoing effort for more formal User Guides, currently carried on by the ODFAuthors group. More information on these approaches and how you can get started is available on the Documentation area of the wiki (see especially the How to Contriubte link to the right side of the following page): http://wiki.openoffice.org/wiki/Documentation Thank you for contacting Apache OpenOffice. -- MzK Anyone who considers protocol unimportant has never dealt with a cat. -- Robert Heinlein
