2012/11/24 Jürgen Schmidt <jogischm...@gmail.com> > On 11/23/12 5:26 PM, Keith N. McKenna wrote: > > Rob Weir wrote: > >> On Fri, Nov 23, 2012 at 8:20 AM, Keith N. McKenna > >> <keith.mcke...@comcast.net> wrote: > >>> Jürgen Schmidt wrote: > >>>> > >>>> On 11/21/12 5:33 PM, Keith N. McKenna wrote: > >>>>> > >>>>> Rob Weir wrote: > >>>>>> > >>>>>> On Wed, Nov 21, 2012 at 11:04 AM, Keith N. McKenna > >>>>>> <keith.mcke...@comcast.net> wrote: > >>>>>>> > >>>>>>> Regina Henschel wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> Hi Jürgen, > >>>>>>>> > >>>>>>>> Jürgen Schmidt schrieb: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> first of all I would like to volunteer again as release manager > >>>>>>>>> for > >>>>>>>>> our > >>>>>>>>> next release if it's ok for our community. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> +1 > >>>>>>>> > >>>>>>> +1 on that from me also > >>>>>>> > >>>>>>>>> > >>>>>>>>> Second I would like to define with you what our next release > >>>>>>>>> will be. > >>>>>>>>> After various discussion and activities on the mailing list and > >>>>>>>>> also at > >>>>>>>>> the ApacheCon, I got the impression that the majority would > >>>>>>>>> support a > >>>>>>>>> 4.0 version as our next release. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> I'm not in favor of an version 4.0 as next release. The changes > >>>>>>>> have > >>>>>>>> listed below would justify a version "4.0". But I doubt, that > >>>>>>>> they are > >>>>>>>> possible in a time frame, I see for the next release. > >>>>>>>> > >>>>>>> I am with Regina on this one. I do not see a Jan or Feb time > >>>>>>> frame as > >>>>>>> feasible for the design and implementation of a new and still a > >>>>>>> comfortable > >>>>>>> bit of padding to deal with the inevitable gremlins that will sneak > >>>>>>> out of > >>>>>>> the woodwork to assure the kind of quality release that is > >>>>>>> expected of > >>>>>>> OpenOffice and that we expect of ourselves. > >>>>>>> > >>>>>> > >>>>>> Uh, Juergen never suggested January or Feburary as a time frame for > >>>>>> 4.0. So I don't see how one can dismiss a 4.0 proposal as being > >>>>>> unfeasible based on dates that he never suggested. Maybe we should > >>>>>> ask Juergen what timeframe he had in mind for 4.0? Of course, it > >>>>>> might be possible to do both, provided we have volunteers willing to > >>>>>> own testing and release management for 3.5. > >>>>>> > >>>>>> -Rob > >>>>>> > >>>>> As I re-read the post you are correct Rob and I apologize to > >>>>> Juergen for > >>>>> reading to much between the lines. What timeframe were you > considering > >>>>> for a 4.0 release Juergan? > >>>>> > >>>> > >>>> Well I had indeed not February in mind but when we targeting on end of > >>>> March or April we will have more time. > >>>> > >>>> Maybe we can take first a look on what others have in mind to put in > >>>> the > >>>> next release. > >>>> > >>>> Juergen > >>>> > >>> This sounds like a good idea. My concern is that we have enough time to > >>> adequately the changes, especially the potential UI changes, and that > we > >>> address the end of life issues with the 3.x.x line. We do not want to > >>> spring > >>> possibly major UI changes on end users without adequate warning. > >>> > >> > >> Is there something users need to do to prepare for UI changes ? ;-) > >> > > Rob, have you ever been involved in direct user support? When you make > > major UI changes your support structure is going to be inundated with > > questions under the best of situations. When you spring them on users > > unawares you unleash the tirade of "change for the sake of change" > > potentially getting bad publicity for the product. > > > > While it is true that an amount of this is inevitable, a good marketing > > and communication campaign can go a long way towards minimizing it. We > > cannot loose sight of the act that we are an end user project and not > > just for the techie types. > > > >> IMHO, if the changes are a bad idea we should never do them. But if > >> the changes are a good idea then let's get them done, tested and > >> released without delay. Yes, it will be a surprise for many end > >> users. As far as I can tell most users still don't know we've moved > >> to Apache either. > > > > Whether we have moved to Apache or not is of little concern to the > > general user. Changing the look and feel of the product he or she is > > familiar and comfortable with is. > > > > Do not get me wrong, I am not against change. I am simply adding a voice > > of caution that we not inadvertently shoot ourselves in the foot > > (figuratively to be sure). The UX work that Kevin and others are going > > and the push by you and others for greater marketing presence are all > > good things and need to be given sufficient time to have a good impact. > > > > If in the considered judgement of the community the March/April > > timeframe is sufficient that is great and we should do it. All I am > > doing is raising some considerations that may not always be thought of. > > > > Before we go in endless discussion here about UI changes I would > recommend that people who are interested join the related discussion in > time, give their input or raise their concerns. What I don't want to see > is that people speak up when everything is implemented and final ;-) > > Now it's not the time to discuss it. We all agree that UI changes have > to made careful and need intensive testing. We are trying to do our > best, a good implementation, good testing and a smooth transition to the > new UI. > > We are talking here about the sidebar where the main concept is already > known from Symphony and where the interface was awarded already. We > don't talk about something completely new and we will do it step by > step. The toolbars will be still available and the sidebar can be hidden. > > The concept will evolve over time and I am very confident that our users > will like it. > > Furthermore I would like to ask all of you to think about features that > are not easy to use today but very common for many users. Useful > features that are not easy to find or where the usage is unintuitive. > Let us think how we can make it better and easier to use. Let us improve > what we already have step by step. I learn always new things and I am > most often impressed what we already can today and where I am not aware > of these features. > +1, the key of the UI change is to improve user experience. No matter sidebar, new icon or some other changes, they should be a more easy entrance for user to find the command, or provide a simplified operation comparing to previous release. User Experience Improvement, that's the goal of 4.0, IMHO.
BTW, sorry Juergen I forgot to say in my previous response: +1 for your continuing to be our release manager. :) - Shenfeng (Simon) > > Juergen > > > > Regards > > Keth > > > >> > >> -Rob > >> > >>> Regards > >>> Keith > >>> > >> > > > > > >
