Hi Joerg,
Sorry also for the delay.
Joerg Barfurth wrote:
Hi Sophie,
Sorry for the late reply. I was busy with other things.
I can imagine :) and thank you for your answer.
Sophie Gautier wrote:
I join Christian here, it's not about getting feature implemented but
influence the decisions that are taken.
It is hard to find the right level at which this can happen and where
this separation is possible.
The decision how much effort should be put into a feature can't really
be separated, but that decision in turn is strongly interrelated with
decisions about the feature itself and what shape it should take on a
high level. OTOH many detailed decisions can only be taken when there is
a solution design and maybe even a prototype, which means that the
decision to address the feature has been taken already (otherwise who
would do the work on the design or prototype).
This is why we would like to be part of the specs first draft. We will
be able to complete scenarii, for example the companies or governements
that make our users base are able to give a valuable feeback here. I
don't want to say that we are able to interverne at each step of the
implementation, but we can accompany its design and avoid some
"mistakes" or regressions.
OOo 2.0 had one big step forward in handling planned changes by
making most of the work public. The 'Q concept' was published, specs
were published and announced - sometimes well before implementation
and most feature issues were entered in IZ instead of the
Sun-internal bug tracking system. This already would have allowed
community participation, but it was not explicitly solicited. It is
my impression that this opportunity was not used very much.
I agree with you and here I wave between two feelings : 1) the
community was not mature enough to measure this level of sharing, 2)
Q-concept and specs have not been explained correctly to the community.
As for EIS where informations about QA are missing, we need also to be
aware where and when we can intervene and when and where we can't.
Understanding this probably requires a deeper understanding of the
development process. I believe this was not very easy in the early
stages of the OOo 2.0 release cycle. But thing should have improved
since. We now have the CWS (child workspace) process open to community
developers, so the way things get implemented is visible and documented
for the non-Sun community.
Oh yes, I agree with you, cws are a big step forward and this should be
really popularized, this is our role to explain it and bring
contributors here, and I'm happy to see that their is more community
contributions on it (yes cloph, I've seen yours ;). From what I know
there is still some documentation to write (about synchronizing a cws
for example) but this is details, and we can write it.
Participating in this also requires a QA process that integrates the
community QA and possibly a process to do early (pre-integration)
feedback releases from child workspaces. Both of this isn't really there
yet. This is probably something the qa project should try to set up.
Probably yes.
But if you want to influence design decisions, this will probably have
to start earlier, which means were are back at the RFE and specification
process.
yes.
But now OOo 2.0 is approaching a close and now is the time to return
to the things that were formerly postponed to 'post-2.0' and to
consider any new ideas for the 3.0 release cycle. This is what Louis
is doing here.
That is also where we are trying to help him and please, don't forget
why this conversation appeared :)
Yes. I was only reinforcing this.
understand
What did you foresee would happen with the RFE process? AFAICT the
plan was to implement a better RFE process for the release after 2.0,
oups, I was not aware of that. We have begin to work on RFE process
some time ago now and nobody told me that it was postponed after 2.0.
Anyway I have postponed my participation because nothing was moving at
all.
Not sure if this was a formal decision. This was just my impression, but
I really have nothing to do with the RFE process myself. I noticed that
progress on the RFE process was stalled and when looking for reasons I
had the feeling that everyone (i.e. at least the relevant Sun people)
was very busy with 2.0. I also recall my impression that this work
wasn't really productive at the time, because most 2.0 deadlines were
passed already and planning for post-2.0 was still far away.
RFE triage and consolidation at its current stage has nothing to do with
a deadline for a release. I think that the next feature set for 3.0 is
in his way and all what is in "requierement" is in a dead zone.
this is still possible and you can participate in making that a
reality. If you don't participate, you shouldn't complain if it
doesn't happen. And if you and others don't participate because you
'foresee' it not becoming a reality, then that may simply be a
self-fulfilling prophecy.
What if you participate (or try to) and been answered that your
complain is not the good one because you're not representative ? All
the work we are trying to do here is to answer this question.
I was really referring to participating in designing a RFE process. I
have not heard of process suggestions being turned down because the
proposer is not representative.
May be your ears were not long enough ;)
Of course such a process will have to deal with the fact that any given
RFE may not be good for all users and that anyone who implements
features (e.g. Sun) will value the perceived needs of their target group
higher than those of the general community (representative or not).
I can understand this, but the proposals of the community could be also
part of the needs of the group targeted by Sun. This is about an
exchange where we can bring valuable input instead of being ignored.
Of course the very long release cycle we've been having is a large
part of the problem and because of it most RFE submitted after the
2.0 planning phase are still waiting in some queue. But that this is
a problem is known and there is an ongoing discussion how this
problem can be avoided - again for the time *after* 2.0.
Where is this ungoing discussion taking place ? Why aren't we part of
it or do I miss to subscibe to a list ? What about regressions that
are not RFEs and targeted to OOolater ?
This discussion is also moving slowly. There was some visible activity
on OOoCon 2004 (e.g. a presentation by Matthias Huetsch). Since then
there wasn't much public discussion on this. I assume that the ESC
and/or the CC may still have this on their agenda. Again this release
cycle discussion is something that should be revisited now for post-2.0
planning. Actually this has to happen anyhow, as we need to decide how
big our next release(s) will be...
have to check for all the items we have on the CC agenda...
Honestly saying, I don't really know, why I care about issues, that
could be resolved within minutes ..
How do you know that? If you know, why don't you resolve them
yourself? Do you have examples? Do you consider that changing the
user interface requires more than changing the code (e.g.
specifications, documentation, translation).
Most leads here are aware about documentation, translation and so on :)
Yes. But people who suggest that UI changes may be simple and take 'only
a few minutes' apparently are not.
yes, but we are leads of our projects and we are trying to make
reasonable propositions ;) I will never say that a change being in the
UI or not will take only few minutes because I'm not a developer, but
I'm sure we can sometime avoid unnecessary work by our proposal and
feedback.
There certainly were problems with how some issues were handled. But
all participants occasionally make mistakes (e.g. some issues remain
unhandled, because they have the wrong owner, component, status or
target milestone. If you see some systematic problem, then you should
attempt to get the process improved. For RFEs the need to improve the
process is known and has just been sleeping.
Well, hard to hear when a new process has been put in place in July
and that you have take some time during your vacation to work on it !
Not sure what you are referring to here.
see the [email protected] archives and issue :
http://qa.openoffice.org/issues/show_bug.cgi?id=29756. That was supposed
to solve some issues on RFEs process.
And yes there are some systematic problems that either the community
and Sun have to adress, this is what we are trying to do, I guess
I think the main point is that the non-Sun community and the involved
Sun people need to get *together* to figure out how they can collaborate
here.
+1 but it's not only at the developers level. The Sun developers have
made a lot of change in their way of work since the past years. I
underline it because it might not have been easy each time. But their is
also a marketing staff at Sun we may be able to speak and exchange with.
This is why I don't want to see new categories in IZ, or anything else
where we try to work on that anyhow will be ignored. As I said, we
have no time and energy to waste on a process that leads nowhere.
Are you sure it won't lead somewhere eventually?
Not in the way it is done actually. See Christian's comments about it
here and on the archive of the list I mentionned above.
I can understand that
you are reluctant to put effort into the first parts of a process when
the next steps and the entire picture are not yet clear. So probably
finishing the process should have priority now, even if it means holding
off on actual work on RFEs even longer.
What is not clear is what and when will be the next step after the
triage actually made. As I said this process had begin in June or July
last year, and we are in May and nothing more happened.
I recognize that we have missed the specs publication. So now we will
work with them, a team is already in place in my project and I've
asked Christian Jansen to add a target for all projects specs when he
will have time.
There have been ideas floated to track spec handling and QA tasks in IZ,
like implementation tasks are tracked today. Maybe that would help get a
visible handle on them.
Yes, if we are aware of it.
I know that we shouldn't discuss about this on issues, going on the
[EMAIL PROTECTED] list and speak to the developper in charge is a
possibility, but this is not a clear and good process when :
- the developper is already working on the features, it's too late
- each time you have to proove that you are speaking for a community
and not on your own name,
I don't think you have to prove that. But if you are convinced that you
solution is better than his, that yours is important to many people or
that his is detrimental to many people, you surely need arguments.
Actually I think that numbers like votes or duplicate issues are not the
best arguments, because they may be the input of a vocal minority.
This is where we need to be recognized. For my own case, I'm not talking
without consulting our users base, I have regular feedback from users
group that represent 50 seats to 250 000 seats or even more. The
arguments I can develop are the one developed in the reports they send
me. I can send the report I had about the mailing wizard in 2.0 from
several hundreds people, where do I send it if this is not
supposed to be public.
As for RFEs, we need to define a communication between us.
- each time you have to proove that the feedback you've got from your
community is as important as the one Sun has. This is exhausting.
If the developer is paid by Sun, he is obliged by his job description to
implement what Sun customers need (however Sun determines that). Thus he
must to care about requirements he received through Sun-internal
processes. For anything beyond that you need to convince him that doing
the extra work is in the interest of Sun or the OpenOffice.org project.
I don't really see a way around that. The same applies analogously for
other implementors or project leads, if you want them to change their
plans.
Well in that case, why couldn't we speak to the person behind the
developer at Sun, why the developer should do extra work if what we
propose is also good for Sun ?
- there is no way here for us to imply companies that want to
implement a complete feature,
I'm not sure I understand this sentence. Companies (e.g. Ximian/Novell)
already have implemented entire features. If you don't have such a
company for your feature, you may try to get together a group of
individuals that can complete the task. In any case it is best to
communicate with the responsible project lead before you start to avoid
duplicate or contradicting efforts and to make sure the feature will be
accepted (i.e. does not contradict OOo plans or concepts).
What I wanted to say is that if all the feature implementations are
designed behind the scene there is no way for us to bring companies to
participate. I have had the case for a feature 2 years ago and this is
what I would like to change.
Not all companies are as large as Novell. They need to be introduced to
the project and find interlocutors. As you said, the developer paid by
Sun has to answer Sun requirements and has no time to discuss about what
is out of this, and I really understand it.
For example, some companies asked me about a list of features because
they were planing their major developments and wanted to incorporate
some work for OOo in this planing.
- there is no way for us to give a clear representation of the needs
of our users base.
Why? That would be up to you wouldn't it?
The point that is unclear is how you can feed that into OOo processes so
that it will be heard (and hopefully implemented, even though you said
you didn't care about that).
That was not me who said that, but this is not important :) The
important point is where and how we can have influence on the next set
of features for a major release, as you said : being heard.
Kind regards
Sophie
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 266.11.16 - Release Date: 24/05/2005
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
