Hi,
Charles-H.Schulz wrote:
Joerg Barfurth wrote:
Actually I like this idea and it solves a real problem.
The idea being that non-english-speaking users can submit an issue in
their native language. That issue bundles all input in that language.
And someone from the NL project submits a separate issue in English to
the developers, which is marked as blocking the NL issue.
As Joost has pointed out doing that naïvely may create a lot of
problems. My point is that, *if done properly*, this can indeed enable
people to participate in OOo QA that couldn't so far.
The main burden of this would be with the native-language projects that
choose to adopt this:
- They need to set up a web interface that directs the submitted
native-languge issues to the right place - these issues should be
submitted against the native-language component for that language rather
than the product component.
- They need to have people that take ownership of such submissions, do
some initial triage/confirmation and finally submit a translated (and
possibly improved/clarified) issue for the developers. These people
would also need to monitor status changes of the developer issue and
relay the information to the native issue.
But if we standardize on one way to do this and get an initial version
of the web pieces for the NL sites to facilitate it (in some language),
then others can build on that work and we can geta common understanding
instead of having each NL project invent their own solution.
So, I like the idea - but to make it work, a lot remains to be done.
Ciao, Jörg
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.
--
Joerg Barfurth Sun Microsystems - Desktop - Hamburg
>>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<<
Software Engineer [EMAIL PROTECTED]
OpenOffice.org Configuration http://util.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
