(top posting) The discussion drifted apart from the original issue... Regarding documentation on the sidebar there is something to say, but please, consider the following just as an analysis of the actual situation, no complains from my part.
The documentation team have a non small problem. Right now there are several good editors, but only one active writer: me. That's an unfortunate situation for a number of reasons. First of all I'm not a native English speaker so editors have more work. Also, I cannot write the whole guide by myself: base is far from my experience, I only seldom use Calc and I do not like presentation with transitions (always use static pdfs...). But more important to this topic is that I'm not able to understand how the online help system works. So the sad true is that nobody is working on the bundled help and unless someone takes the lead with a clear proposal nobody will work on it on the near future. Regards Ricardo 2013/4/25 janI <j...@apache.org> > On 25 April 2013 19:42, Rob Weir <robw...@apache.org> wrote: > > > On Thu, Apr 25, 2013 at 1:15 PM, Andrew Rist <andrew.r...@oracle.com> > > wrote: > > > > > > On 4/25/2013 1:16 AM, Jürgen Schmidt wrote: > > >> > > >> On 4/25/13 9:55 AM, janI wrote: > > >>> > > >>> On 25 April 2013 07:34, Jürgen Schmidt <jogischm...@gmail.com> > wrote: > > >>> > > >>>> On 4/24/13 11:34 PM, janI wrote: > > >>>>> > > >>>>> On 24 April 2013 22:33, Juergen Schmidt <jogischm...@gmail.com> > > wrote: > > >>>>> > > >>>>>> Am Mittwoch, 24. April 2013 um 17:06 schrieb janI: > > >>>>>>> > > >>>>>>> On 24 April 2013 16:25, Jürgen Schmidt <jogischm...@gmail.com> > > wrote: > > >>>>>>> > > >>>>>>>> On 4/22/13 10:50 PM, janI wrote: > > >>>>>>>>> > > >>>>>>>>> On 22 April 2013 22:27, Jürgen Schmidt <jogischm...@gmail.com> > > >>>>>> > > >>>>>> > > > <snip snip snip> > > > > > >>>>> But again, if the general opinion is, that is better to keep a > > selfmade > > >>>>> deadline and release a half finished product, it would not be fair > of > > >>>>> me > > >>>> > > >>>> to > > >>>>> > > >>>>> stand in the way. > > >>>> > > >>>> See above, I think we have to hold our deadlines to show confidence > to > > >>>> the outside. But we can of course improve our planning in the > future. > > >>>> > > >>>> Or we should think about a real train model where we release every 3 > > or > > >>>> 4 month. But where we maintain also a more stable branch where we > fix > > >>>> mainly bugs and potential security fixes. > > >>>> > > >>>> this would be a good idea for minor/maintenance releases but not > for a > > >>> > > >>> major release. > > >>> > > >>> However, it seems I am the only one with this concern, so I will > > silence > > >>> myself. You > > >>> are the voted in release maneger (which I highly support) so > according > > >>> the > > >>> apache way, > > >>> it is your call together with a majority vote is a release is > > acceptable. > > >> > > >> I simply volunteered to do this task, I am happy if somebody else > steps > > >> in ;-) > > >> > > >> And in general I share your opinion that releases should not have 100% > > >> fixed dates but should more take the planned features into account. > > >> Fixed dates result often in poor software or poor quality. But I > believe > > >> we have to find a compromise and what's possible and to show the > > >> necessary confidence to the public about the progress in the project > and > > >> in the product. It's not easy ... > > >> > > >> Juergen > > >> > > > Have we discussed, as a project, the tradeoffs that we are making here? > > On > > > one hand we have solid decisions on the release made by Jürgen which > trim > > > features, but lead to a predictable, stable, and complete release. On > > the > > > other hand, we have we have the reasonable question by Jan, as to > whether > > > there is an alternative approach that sacrifices the schedule (i.e. > > pushing > > > back release date) for the features. My question is "Do we have a > solid > > > understanding of this trade-off, and should we make this decision as a > > > project?" > > > > > > To me there are three major changes that would be good to be in AOO 4.0 > > > which are currently in jeopardy: > > > > > > * Accessibility - the integration of iA2 - work is ongoing. This has a > > > major impact on the product, and the ability of large corporations > > > and governmental agencies to embrace the product. > > > This is important to me. > > > > * New Translation Infrastructure - this is the major change to use the > > > po files directly in the code, the consolidation of the poo files, > > > to me this is nice to have, but does not afftect end-users. > > > > and the new pootle server infrastructure. > > > Is ready in approx. 1 week. > > > > * Brand Refresh - this work is moving along now, but there is some > > > question as to how much of this project can be completed in the > > > timeframe necessary. (logo + icons/resources + full brand/splash > > > screens + color schemes + ??) > > > This is to a must for 4.0, we cannot change brand with 4.01 > > > > > > > > > > I see a few directions that this could go: > > > > > > 1. Follow the current trajectory and push off a significant amount of > > > originally planned 4.0 work to 4.1 > > > 2. Push off the release by 3 months and get all of these features in > > > completely > > > > > > > We're coming into summertime and vacations. Nothing happens 3 months > from > > now. > > > > 3. Hold the release indefinitely, waiting of these features > > > > > > > > > I think that pretty much everyone would disagree with option #3. > > > > Remember that is how this already feels for those who checked in code > > almost a year ago, when they were working on the trunk while work on > > 3.4.1 was occurring in a branch. There is always more that can be > > added, if we wait. But there are also a lot of improvements that > > we're withholding from users at the same time. > > > Are we really withholding any major features...when I compare the codebases > I cannot really see it, but I might be wrong. > > > > > > One thing already in the code is a fix to a horrendous random crash > > that hits users who upgrade from OOo 3.3.0. Millions of users are > > likely crashing because of this. Do we really want to hold this back? > > We should consider not only the additional stuff we could do with > > more time on this release, but also all the stuff that we are > > preventing users from accessing every day we delay further. > > > This is a maintenence release, which could have been done in 3.4.1, and > still can be done as 3.4.2. > > Please remember 4.0 is a major release. > > > > > IA2 is not a regression. It is a new feature that is not yet done. I > > wouldn't hold back anything there. It is progressing per the original > > plan, for AOO 4.1. It was never in the plan for AOO 4.0, right? > > > > I think we already punted on the translation work for AOO 4.0. I was > > ready to start recruiting translators but stopped since we said that > > was not ready. > > > That work is first of all only in the very beginning (see mails from jürgen > regarding po files), and it is not lost in any way. > > rgds > Jan I. > > > > > > > > Option #1 is a solid option, but I think that there is some portion of > > our > > > community that is not fully comfortable with this. > > > > > > That leaves us with option #2, which is not perfect, either. Do we have > > > estimates from each of the deferred features how long they would need > to > > be > > > complete (with a reasonably high confidence level)? If the time frame > > would > > > be 6 months instead of 3 months, would anyone be comfortable with that? > > > > > > Could we explore option #2 as a project, and get the answers to these > > > questions? Then with a more full understanding, can we make a decision > > as a > > > project for #1 over #2 (or vice versa)? > > > > > > > Another option is to recognize that we'll probably need a 4.0.1 or > > something, later this summer, to fix any critical bugs that we miss. > > Of course, we hope this will not be necessarily, but it is prudent to > > plan for this possibility. This release could accommodate new > > languages, even selected new features. > > > > Regards, > > > > -Rob > > > > > A > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > >
