But currently the only way to comment on OOo development is through issues. That's where the voice is taken. The "official" advice in in these newsgroups is "file an issue or forget about seeing it in OO ever"Okay, we're getting somwehre. There is certainly a communication problem here. I don't think that [EMAIL PROTECTED] is a good way to reach the community. I can't see people signing up to [EMAIL PROTECTED] and reading the specs in the off chance that one of them happens to forshadow a loss of a feature which they feel should "obviously" be there, because it's already there.
But people that are not developers (e.g. from the marketing project) could track that and act as a relay telling a wider audience in less technical terms about important specs and feeding reactions back to the developer.
Completely unmoderated communication between developers and a wider less techinalical audience often don't work well, as can be seen by the way issue commenting is often (ab)used in ways that are perceived as counterproductive by most developers.
Issuezilla is seen as *the* channel for RFEs
I agree that discussing about implementing something with that algorithm or that, using a sequence or a collection or what ever is not for end users. But programmers need an spec to work on and comply. If you read my previous post I have used the term "designers".
I have a question: How regular are the emails to [EMAIL PROTECTED] ? How long are they?
Hypothetically speaking, if those were CC'd to discuss, would they totally drown the list? If they wouldn't, then perhaps that's an avenue to explore. What do you think?
As mentioned before I think some active mediators ar needed. Simply pushing the technical content out to non-technical people won't work, just as noisy non-technical discussions won't be well received by the developers.
I had never heard of [EMAIL PROTECTED], and I suspect that I am in more OOo lists than 90% of the active contributors.
When looking for it I found it to be (too) well hidden. It isn't even mentioned on our main mailing list page. BTW: Do you know of [EMAIL PROTECTED] This is the list to track the step from specification to implementation.
Someone decided to take a usability lab on que quickstarter. Someone decided to remove the menu and wrote an spec doc asking that removal. A programmer simply took out the lines of code involved. It is the former person who should have cared a bit about. Those designers or "decision makers" shoud work tightly with end users, even more that with developers. They should understand the problem and the task involved in a user request, they should have a problem-solving orientaion to translate it into good general solutions, applying common sense. Just not people going directly to "click here put that there".
As a general rule, end users know much better how a program works and behaves than actual developers. It's human nature you are more interested in pointers and Java interfaces than in how to setup style rules and get an assignment written within deadline. As for developers, sometimes I wonder if you actually work with OOo. The wordcount is another infamous example. Easy to implement, actually done before via a macro that could have been incorporated into regular 1.1.x distributions.
You mention that "only" professional writers and some studenst do need wordcount, that "the majority of our users use the program to write personal or business letters, memos and similar documents and don't care about word count at all". By the same rule they should not care about header and footers, master documents, TOCs, autocaptions, bibliography, footnotes, references and many handy features that OOo has and that the user you have in mind, I promise you, never have heared of. Again, we the end users, those that do work with OOo functions (not on OOo code) many hours a day, those that know what type of documents are "normal" or "standard" in their fields and the tools we need to accomplish the task (and you may be surprised by the sophisticated demands of even a grandma: suppose she want the photograph of each of her grandsons in the header of each chapter or her document, but not as a watermark. And automatically update it upon birthdays).
- Enrique -
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
