On 26 April 2013 20:41, Jürgen Schmidt <jogischm...@gmail.com> wrote:
> On 4/26/13 8:10 PM, janI wrote: > > On 26 April 2013 18:52, Rob Weir <robw...@apache.org> wrote: > > > >> On Fri, Apr 26, 2013 at 12:45 PM, Claudio Filho <filh...@gmail.com> > wrote: > >>> Hi > >>> > >>> Em 26/04/2013 12:13, "janI" <j...@apache.org> escreveu: > >>> > >>>>> for the record, this was not what I said....I simply believe that a > >>>> feature without help (and documentation) is not complete and if > released > >>>> should be highlighted because our average user depend on help in many > >>>> situations. > >>> > >>> Only to give an out perspective, this "highlighted" can return against > >> we, > >>> as a incomplete or immature development. > >>> > >>> Imho, an important feature of aoo project is its concern in bring and > >>> deliver a product with high quality. So, the PoV of Ariel and Jan are > >> solid. > >>> > >> > >> Then all the more reason for someone who cares to enter an issue into > >> BZ for this. Don't you agree? > >> > > > > I have not seen BZ yet for problems/shortcomming with new features in > > development (e.g. where are the detailed outstandings of IA2, jsc 3 layer > > change etc). The help/documentation issue is part of the general sidebar > > development, but of course we can make one big extra BZ for the 4.0 > > release just to please the administrative overhead. > > well I had at least one issue for my 3 layer work and got a second one > for a problem that I introduced. I will create more top finish the SDK > adoption. An of course I would prefer indeed issues for all many more > changes. > > > > > making BZ for problems/missing with ongoing development is highly > > problematic, I could f.x. make about 10 BZ for genLang, and I am pretty > > sure the sidebar developers/documenters/testers could make about at least > > 100 BZ if they wanted to. It would simply flood BZ, make real problems > > harder to spot, and put an extra burden on the people doing the work. I > > f.x. have a simply list with my outstandings,which is quite normal during > > the development/initial test phase. > we have indeed many issues now for the sidebar to document the problems. > Problems from very trivial to more complex and not easy to solve. > Missing help is of course one that should be tracked with an issue. As > release manager I will of course not accept it as showstopper if we have > no issue. And even then it has to be discussed. > > We had again a lot of discussion and nobody started to solve the > problem. I have at least tried to collect some info about the format and > the tooling. And Ariel provided a patch that will help with extended > tooltips. But nobody started work on a help file so far. > > If somebody will veto the release because of a missing help file you can > be sure that I will never ever acting as release manager again. > According to ASF rules a veto cannot be vetoed...release manager needs to say go, with min. 3 PMCs. In general the vote is a majority vote for releases, so even if e.g. I was to vote -1 it would not have a big effect...but stay rested I will not be the show stopper. Unless I read the rules really wrong. rgds Jan I > > And yes it would be missing and it should be fixed, we all agree but it > is not stopper issue. We have much more serious problems that we have to > fix before. > > > > > making a special BZ for this issue, is in my opinion just an > administrativ > > trix, it does not change 1 millimeter about the fact, that we have both a > > challenge. And also I dont understand why you separate this issue from > all > > the other open issues with sidebar. > > I really don't see a separation here, it's simply one more issue > regarding the sidebar. > > > > > We should be focussing a lot more on solving our challenges !! > > exactly and I don't see that here > > > > > Discussing whether or not help is integrated after both developers and > > documenters have told it is not, or whether or not a BZ should be filled > > out are not positive for the process or for our community. > > > > This is of course my private meaning, but we have a real tendency at the > > moment to discuss the administrative surrounding and not the kernel > issues. > > I do not understand, why that is, but I strongly believe it signals > > something negative. > > bring your concerns on the table and describe it clearly that we all can > understand exactly what you mean. It is better to start the discussion now. > > > > > > Lets try to focus on the problems, make solutions...not administrative > > stoppers, any objections to that ? > > an issue for this problem is quite normal and the solution is to start > working on it. Quite easy from my pint of view. > > Juergen > > > > > rgds > > Jan I. > > > > > > > > > > > >> > >> -Rob > >> > >>> My 2 ¢ > >>> > >>> Claudio > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >> For additional commands, e-mail: dev-h...@openoffice.apache.org > >> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
