Hi, putting the NL List in copy... Charles. Joerg Barfurth wrote:
> > Actually I like this idea and it solves a real problem. > >> Having two issues for one problem raises a problem which I don't like >> to have within IssueTracker: >> > > We even now can have several issues for one problem: > - Inadvertent (or unrecognized) duplicates > - Same issue for multiple target releases > - Hierarchically dependent issues > - High-Level requirement + detailed subtasks > - Feature tasks and pre-integration bugs > >> -> statistical work isn't possible anymore > > > It is still possible, especially if the native-language tasks stay in > the associated native-language components. Issues in non-code > components can't normally be counted in code/product quality > statistics anyhow. > > We might even have a special subcategory for 'product bug' in the NL > components, which could be used to monitor this feature (and check for > orphaned issues) > >> -> who cares about closing the issues in native language if the other >> issue has been fixed ? > > > Obviously someone must act as a translator and mediator. That person > files the translated (English) issue to the appropriate development > project. As submitter on that issue (s)he will get notfied as that > issue progresses and is responsible for forwarding this to the > originating native-language issue. > > NL projects of course could organize this differently (e.g. assign a > group to share that work). > >> -> a target milestone can only be set for one of the issues (because >> the developer does only understand the issue in 'common' language. >> > > This is common with tasks that depend on or block others: the > effective target milestone is determined by the blocking task. If the > NL resources can handle the workload, they can try to keep the target > milestone of the dependent issue in sync. Conversely, if the dependent > issue is deemed to be a stopper (for that NL release) the mediator can > propagate this to the developer issue. > > BTW: even now product issues are occasionally submitted against a NL > component and may linger there unhandled forever unless the NL project > has someone who looks for such issues and forwards then to > development. IMHO it would make sense to define a procedure for > handling such issues, that can be adopted by NL projects without > everyone having to reinvent their own variation of this. But > ultimately it depends on each NL project whether they want to adopt > this (and can find enough issue mediators). > > This is a rather natural extension to the idea that NL projects should > bundle and forward ongoing developments and discussion back and forth > between their native communities and the international OOo community. > > Ciao, Joerg > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
