Hi together,
as I have the feeling that many discussions in our most beloved thread
started to go around in circles I want to break out and focus the
discussion by providing a personal summary of it. Please read this
summary as a whole before you comment on single items, I really tried to
cover all points of view, but not in each and every sentence.
IMHO the discussion was about "quality" of the producet and it touched
two major aspects:
- source control
- specs
and mixed them in a way that many of us talked in cross-purposes.
Unfortunately we mixed the spec discussion with the question wether we
should throw code in fast or not - and I for myself was jointly
responsible for that as I mixed those aspects in one of my first mails.
I think that these two topics are only losely coupled and to concentrate
on the "spec" discussion we should leave the "integrate early and fast"
part out for now.
We also touched the matter of "early communication" and it wasn't
disproved that early communication is the best way to avoid delayed
integration. Also nobody denied that early exchange of ideas is a good
thing though that isn't necessary in case of trivial or uncontroversial
changes.
OTOH it is only fair that contributors trying to get in touch with
others can expect a reaction in a reasonable time frame. My personal
take on that is that we should track this in the same way as we track
response times for patches though I don't want to go too much into
details here. But even then we must deal with the situation that
something might get stuck and we must avoid that contributions vanish in
a black hole.
All communication should happen with the spirit "thanks for your work,
let me help you get it included" and not "I'm so busy I can't be
bothered to reply to your mail/issue".
OTOH contributors should accept that they might receive some requests
for improvements of their contribution - the more the longer they are
"on board".
To enable contributors to communicate with others they might need for
the integration of their contribution we should have a contact list that
makes it easier to find the right people to talk with.
Alltogether resolving the communication problems seems to be the most
important step towards any possible closer interaction (e.g. specs or
iTeams). Now back to specs.
"Specs" doesn't necessarily mean exactly what we have now. It can be
something more lightweight, but it must be agreed upon by all
stakeholders how this should look like. To enable this the stakeholders
must publish their goals they connect to "specs". Some of the already
mentioned goals are:
- helping QA to create and execute test plans
- helping documentation to describe the feature
- helping developers to implement what the requirement is about
(something that usually does not apply to community development as in
this case most often the requirement comes from the one who does the
implementation)
- helping developers to change existing features in a controlled way
- to be continued
Let's think about "specs" as a kind of documentation that currently has
a defined shape but not necessarily must keep this in the future.
Whatever shape it will have it must be accessible, understandable and
usable for all stakeholders (so it can't be "use the source" :-)).
Though nobody of the spec supporters ever made claimed that you can't
reach quality without specs as we have them today it was used as a
weapon against them. Instead of continuing this endless discussion I
would like to propose that we should agree upon this:
Specs (not necessarily in their current shape) are a means for achieving
quality, but not the only one.
It's open for discussion wether the effort/result relation of specs in
one or the other shape is fine or not. If we see "specs" as I described
them above I think that even those who argue against our current way of
doing specs didn't deny that having some kind of spec is a good thing.
If we want to change something we must find a replacement for the
current process, we must not undermine or ignore it.
Whatever we do with specs in the future we should address a lot of
problems that have been mentioned:
- content can be out of sync with the code
- missing content
- broken or unaccessible links
- maintainability of screenshots (embedded/linked?)
- maintainability of localized strings
- uncontroversial and trivial changes should go in fast and easy
- non-responsiveness of people shouldn't block contributions: ensure
that the spec. process is filled with shortish timeouts to handle people
that don't respond
- make every possible step asynchronous so there are as few round-trips
as humanly possible
- separate the aspects of design requirements (team) and documentation
(spec) and make it less formal
- focus the saving in (very scarce) developer / QA resource on other
things: a good unit test framework eg. (*)
- re-direct some spec. process time in favour of peer code review - it
will yield a higher quality, and ultimately better trained, more careful
coders (*)
- clearly specify the cases where full specifications are not required,
and aim to extend this list
- to be continued
(*) my personal comment: these two measure don't help us a lot if they
are applied as an addition, they make most sense if they replace
existing ones.
Specs even for trivial ("uncontroversary") changes seem to create a high
barrier for contributors. It is important to lower this barrier. A first
attempt to achieve this could be to make the spec process less formal
(e.g. by using a wiki or even Issuezilla) and concentrate on the content
we want to deliver.
Possibly we can establish a process that allows for more "asynchronous"
work or creates the documentation in a "Q&A" style (QA or documentation
ask for the information they need instead of forcing the developers to
provide everything upfront). This will be useful for contributions where
not an iTeam cooperatively designed a feature but at the end the various
members of it are needed to integrate the work. This happens very often
in case of community based development.
It was also suggested that in case someone (QA/UserEx or somebody else)
isn't pleased with this that he himself should do the necessary work or
find someone else to do this. But it shouldn't be the community
developer (means: not a developer paid by Sun, Novell or others) who
finds himself overwhelmed by a huge process to get his contribution
integrated. It must be investigated how this works in practice.
Is that a basis for further considerations? Did I miss something important?
Ciao,
Mathias
--
Mathias Bauer - OpenOffice.org Application Framework Project Lead
Please reply to the list only, [EMAIL PROTECTED] is a spam sink.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
