Louis Suarez-Potts wrote:

I think the issue here is coordinating efforts and controlling the work
done on OOo, as well as its dissemination.


I certainly don't want to propose anarchy. I can see how my usual comments (e.g. about being flexible) could be taken the wrong way. I guess this is a good time to remind you that I do see value in coordination. My usual comments spring from the fact that usually I feel like control is over-tight for things that shouldn't be. Like the business card example, I felt that should have been simple. But don't take that to mean that I apply that to /all/ projects. Some things aren't simple, or small. Like deciding on a brand name, an SMP, a logo, OOoCon,... and SpreadOOo, in its current proposal.

Following that line of reasoning, I see roughly two options for SpreadOOo: (1) change the proposal to make it something small and simple or (2) accept the need for lots of coordination and agreement from MP and NLC.

As Charles has suggested out, a site that essentially duplicates and competes 
with
extant work will naturally distract from the OOo proper site.  We do not
want that.  We do want a site that complements and is fully integrated.

I agree.
I don't have any easy solutions as to how to accomplish that.

I'm also a little puzzled at the need of this...

Don't ask me :-) I'm not really sure what SpreadOOo is supposed to be. I still don't have a clear picture of what a "window" site is, or whatever the term is.

Our NLC projects already do what is being suggested, pretty much, and our 
marketing project includes things similar to spreadfirefox.

I don't think that marketing does anything remotely like SFF. But that doesn't imply that we need a SOO site.

Put another way, I can see lots of dangers here but few real benefits.


I see the dangers.
As for benefits, I guess I tend to see any new tool as a benefit just because it's there. I'm the kind of person who tends to think, "I'm gaining a tool, I'm not losing any, so this can only help". But that kind of reasoning only applies in absence of dangers.


But let's wait to hear a bit more. Maybe there's a way that dangers can be addressed neatly. I suggested putting each NL project in charge of their respective language. I don't imagine that's a full solution, but it's a thought.

Cheers,
Daniel.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to