Re: [dev] automatic release notes
Frank Schönheit - Sun Microsystems Germany wrote (11-11-2007 22:14) While we are at it ... Somebody should look at those notes *before* they're published. It's nice to have automatisms, but as with other automatisms, there's a need for manual post-work. In this case, IMO it's a strong need. In the current form, which a) has a unfriendly layout b) contains semantic, grammatical and orthographic errors c) contains duplicates, it is a little bit of a shame, given that usually, we expect this to be a very early reading for a lot of people, once a new version is out. Could this meet 'your' needs, Frank http://wiki.services.openoffice.org/wiki/New_Features_2.3#Full_list If so, the release notes-page is useful for those needing/wanting more technical data, and the wiki for users. Regards, -- Cor Nouws Arnhem - Netherlands nl.OpenOffice.org - marketing contact - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] automatic release notes
Hi Cor. Could this meet 'your' needs, Frank http://wiki.services.openoffice.org/wiki/New_Features_2.3#Full_list Ah, that's cool! Who is in charge of this page? Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] automatic release notes
Hi Frank, Frank Schönheit - Sun Microsystems Germany wrote (12-11-2007 11:32) Could this meet 'your' needs, Frank http://wiki.services.openoffice.org/wiki/New_Features_2.3#Full_list Ah, that's cool! Who is in charge of this page? The volunteer :-) Inspired by the good work done by Sophie in the past, and the fact that we want such a page in Dutch as well, I picked it up. My idea is to document the steps, somewhere on the wiki, and make that known on [EMAIL PROTECTED] at the least, so that others can join or just step in, when I come in trouble with available time... It is therefore that I jump in every time, when there is a discussion that might lead to a more reliable automatic collection of issues ;-) BTW: at some stage after release of 2.3.0 it was linked from the projects main page. Ciao, Cor -- Cor Nouws Arnhem - Netherlands nl.OpenOffice.org - marketing contact - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: [allfeatures] new/OOo 2.4 : Context menu entry to quickly insert picture background for slides
Mathias Bauer wrote: Joe Smith wrote: I've started to see these messages on the features announce list (via Gmane). This seems like a good thing, but I have some questions: 1) Is there any mechanism for feedback on these features? None seem to have any issue number; are they supposed to be tracked through the CWS name? If so, is there a feedback channel there? I think they should have an issue number - in case there is a single issue for that feature. Besides that they can indeed by tracked through the CWS name in EIS. Most have a CWS name, but in this case (a community patch) there is not even that. 2) Do these features go through any UX process? Perhaps it is all internal. Every new feature is expected to go through a UX process, at least on an informal level. I don't know what internal should mean so let me describe what we are doing in Hamburg. ... Sorry I wasn't clear, but you understood my meaning of internal accurately. Getting feedback from a wide an audience as possible seems like a good way to go. It is so hard to change any UI design after the fact. As every work UX work needs a focus. IMHO posting new features to a discuss list at random will not produce useful results. Perhaps it will make things even worse when the discussions (as often) won't come to an end or end without a concrete result. I agree: a random discussion is not the way to do UX design, but it is part of the way. The iTeam can easily make a final decision and move on at any time, if there is no consensus. I think a feature always should have a dedicated UX worker (and of course at least one developer ;-)). If all people involved in developing the feature think that they need more input they may use our UX project and its mailing list to collect more input. But that's just my personal opinion. Yes, but it is precisely when the developers think that no outside input is needed that the outside input is most needed ;-) Of course the developers are professionals and can make good decisions, I'm not saying that everything has to be reviewed, only that comments should be solicited for all features, even if the solicitation is implicit (a link to a feedback channel). Tracking a feature through EIS is not good: it's very difficult and there is no place for direct feedback. Not every CWS links back to any issue; many link to several issues. There should be some link on the feature announcement, either to an issue id, or to a mailing address ([EMAIL PROTECTED] is not useful to outsiders!) or mailing list where comments can be made that will definitely be seen by the iTeam. I expect most will get no comments, but some will and some will be useful. In the case of this specific feature: Context menu entry to quickly insert picture background for slides the spec (http://specs.openoffice.org/impress/sd.insertbackground.odt) has a broken image of the proposed menu. I have no idea how and if a UX review happened for that particular feature. At least it would be a violation of our rules if it hadn't got one. But even a review may fail to prevent errors. Ok, well maybe this list will work in this case, but some channel should be opened to make it easy for a community volunteer to provide feedback on a feature before it is integrated. Thanks so much for taking time to explain the process. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] feature feedback channels (was: [dev] Re: [allfeatures] new/OOo 2.4 : Context menu entry to quickly insert picture background for slides)
Hi Joe, There should be some link on the feature announcement, either to an issue id, or to a mailing address ([EMAIL PROTECTED] is not useful to outsiders!) or mailing list where comments can be made that will definitely be seen by the iTeam. I expect most will get no comments, but some will and some will be useful. I like this idea. This can even be automated (sic!), since for the feature mail, you need to specify a project, anyway, which means the mail goes to [EMAIL PROTECTED] Adding some additional feedback to [EMAIL PROTECTED] should be easily possible, /me thinks. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: feature feedback channels
Frank Schönheit - Sun Microsystems Germany wrote: ... I like this idea. ... Cool! Of course now there are some replies appearing on [EMAIL PROTECTED], so maybe that's the simplest thing. I read the list through Gmane, where it appears as ..OO.announce.features, so I assumed it would not be appropriate to reply on an announcement list. As long as it's acceptable to reply there, and the iTeam monitors that list, it would be fine to simply comment there. OTOH, having a specific issue for each feature would provide a central, easy to find location for feedback related to that feature. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: feature feedback channels
Hi Joe, ... I like this idea. ... Cool! /me liking it doesn't mean anything about the probability for it to be implemented :) Of course now there are some replies appearing on [EMAIL PROTECTED], so maybe that's the simplest thing. I read the list through Gmane, where it appears as ..OO.announce.features, so I assumed it would not be appropriate to reply on an announcement list. As long as it's acceptable to reply there, and the iTeam monitors that list, it would be fine to simply comment there. In fact, discussing on the announcements list is not a good idea, this creates too much noise. OTOH, having a specific issue for each feature would provide a central, easy to find location for feedback related to that feature. An issue should normally be part of the feature mail, at least the EIS frontend has a field for it. However, discussing in a closed issue might also not be a good idea. I'd still vote for [EMAIL PROTECTED] Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: [allfeatures] new/OOo 2.4 : Context menu entry to quickly insert picture background for slides
Hi, Joe Smith wrote: I've started to see these messages on the features announce list (via Gmane). This seems like a good thing, but I have some questions: 1) Is there any mechanism for feedback on these features? None seem to have any issue number; are they supposed to be tracked through the CWS name? If so, is there a feedback channel there? there is a Spec Doc at http://specs.openoffice.org/impress/sd.insertbackground.odt In that doc, the issue number is given as: http://www.openoffice.org/issues/show_bug.cgi?id=82911 I assume we use this mailing list for feedback 2) Do these features go through any UX process? Perhaps it is all internal. this feature was submitted from an external OOo coder as a patch. I hope however that the internal QA tests took place and that the feature made it alright through those tests. Getting feedback from a wide an audience as possible seems like a good way to go. It is so hard to change any UI design after the fact. In the case of this specific feature: Context menu entry to quickly insert picture background for slides the spec (http://specs.openoffice.org/impress/sd.insertbackground.odt) has a broken image of the proposed menu. Also, it seems like there is a missing pathway: the spec mentions two possibilities: 1) Adding a background image for a master automatically affects all the slides that use that master. 2) Adding a background image to a specific slide prompts for a choice: a) apply to one slide, or b) apply to the current slide only. What happens if the presentation uses more than one master? Is only the current master affected, or does it literally mean all slides? If all slides, will the background for all masters be changed? good questions. The Spec Doc doesn't mention whether the master slide gets changed or just a new background image is applied to the current slide. It also does not mention what happens to other slides using the same master slide. We (online help authors, manual authors, etc) must either ask the author of the Spec Doc or install the CWS (where is it?) and find out by some tests what happens. Given the fact that now, a few days before feature freeze, a lot of new features arrive, such features that are not well documented must wait until there is spare time to care for them. Any other, well documented features will be processed prior to these research tasks. Uwe -- [EMAIL PROTECTED] - Technical Writer StarOffice - Sun Microsystems, Inc. - Hamburg, Germany http://wiki.services.openoffice.org/wiki/Documentation http://blogs.sun.com/oootnt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: [allfeatures] new/OOo 2.4 : Context menu entry to quickly insert picture background for slides
Uwe Fischer wrote: ... there is a Spec Doc at http://specs.openoffice.org/impress/sd.insertbackground.odt In that doc, the issue number is given as: http://www.openoffice.org/issues/show_bug.cgi?id=82911 I assume we use this mailing list for feedback ... Ahh, of course. I should've remembered to look there. Thanks for pointing that out. So you still prefer to have discussions on this list? I suppose the issue should not be cluttered with discussion, but it's hard to keep synchronized. E.g. there's no link at this point from the issue to this discussion. I will at least mention the broken image under that issue. Thanks for your help. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Multilanguage documents
Christian Lohmaier wrote: Hi *, On Nov 11, 2007 3:54 AM, jonathon [EMAIL PROTECTED] wrote: Rony wrote: FWIW: MS Word has been having that ability for quite a few versions now. There one would use the Language tab on styles to define what language it is used for (on that dialog one is able to turn off grammar- and spell-checking). How is that different from implementing language specific styles in OOo? Please don't confuse KAMI's feature-request with the stuff described in this excerpt. Did not realize that! Of course you can already assign different languages to different parts of your document and that language will be used for spell-checking, hyphenation and will affect things like autocorrect/autoformat (replacement of typographic quotes for example) Tsk, thank you for pointing that out. Being somewhat accustomed to MS Word, I looked into the wrong area in OOo to find that (just found it to be a drop-down field on the Character- resp. Font-dialog)! - if you choose the language none, no spell-checking, hyphenation is performed. Well, that would be *quite* different from being able to assign a specific language (important, to be able to identify/extract text in a certain language) and determine that that should not be spell-checked, hyphenized or Grammar checked. ---rony
Re: [dev] Re: [allfeatures] new/OOo 2.4 : Context menu entry to quickly insert picture background for slides
Joe Smith wrote: Mathias Bauer wrote: Joe Smith wrote: I've started to see these messages on the features announce list (via Gmane). This seems like a good thing, but I have some questions: 1) Is there any mechanism for feedback on these features? None seem to have any issue number; are they supposed to be tracked through the CWS name? If so, is there a feedback channel there? I think they should have an issue number - in case there is a single issue for that feature. Besides that they can indeed by tracked through the CWS name in EIS. Most have a CWS name, but in this case (a community patch) there is not even that. Seems that this was done in a hurry. ;-) As every work UX work needs a focus. IMHO posting new features to a discuss list at random will not produce useful results. Perhaps it will make things even worse when the discussions (as often) won't come to an end or end without a concrete result. I agree: a random discussion is not the way to do UX design, but it is part of the way. The iTeam can easily make a final decision and move on at any time, if there is no consensus. Doing every feature development this way would bring development nearly to halt. I don't want to start each feature development with a broad public discussion, this won't work and will surely demotivate the developers. I agree that more feedback loops at specification and development time are desirable and I'm sure that qualified feedback is something that every developer likes to get. Incorporating more community UX feedback shouldn't be a fundamental problem for features developed in Hamburg, it's just a matter of tooling, effort etc. I see problems for features not provided by Sun's developers as a considerable and verbose part of the non-Sun developers is not very fond of UX in general and community UX involvement as a project goal in particular. More or less verbally I was told in a meeting that the developers should be in charge. While I like to see developers driving the project I know where we have our limits. And I like to broaden our community by getting non-developers involved and contribute to our project with their abilities and knowledge. My own experience with community input for features is very positive. So much for internal vs. external. Yes, but it is precisely when the developers think that no outside input is needed that the outside input is most needed ;-) You seem to overlook that an iTeam is not consisting of developers only, there's always a UX member involved. We even sometimes exaggerated a bit in the past, leaving all UI decisions to the UX members what often resulted in the feature development being stuck. This was a pity especially for patches from the community where we (rightly) got some very negative comments for not putting them forward. So we learned that sometimes a decision *made* by a developer is better than a decision *not made* by a UX engineer. ;-) Tracking a feature through EIS is not good: it's very difficult and there is no place for direct feedback. Not every CWS links back to any issue; many link to several issues. I think your suggestion to allow for more and earlier feedback is valid and good. But getting involved should be a duty of those wanting to get involved, there shouldn't be a duty for iTeams to wait for input upfront. We tried to establish that by providing specifications early (again something that a part of the non-Hamburg developers does't like, a very prominent one of them even made a fun of it in his blog) but perhaps indeed the time when specs are published maybe quite late at times. Meanwhile we have started to publish ongoing development for larger features in the wiki so that input can be collected even before the spec is finished. Maybe we need a channel where such public development can be announced. An existing channel is our GullFOSS blog where Dieter Loeschky posts the ongoing work of all Hamburg teams once per weak. Perhaps we can add feedback links to that post. There should be some link on the feature announcement, either to an issue id, or to a mailing address ([EMAIL PROTECTED] is not useful to outsiders!) or mailing list where comments can be made that will definitely be seen by the iTeam. I expect most will get no comments, but some will and some will be useful. Seconded. That should be easy to add. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
