Many good comments, mostly I think you are actually agreeing with me, so I'll try and be brief...
>> >>Yes, and I'm still advocating the brainstorming. What I'm suggesting is >>that only one person can really "design" something. >> > > I strongly disagree with this : although there must be a design leader, > discussing it in the open is key to a strong design. I've been doing it > in my work for years, and found several points that make it really > efficient : > - the designer may have chosen a wrong way, or made wrong initial > assumptions, Validation of the design by the users of the design is always required! > - gathering ideas from several people ensures that several points of > view have been taken into account and that the designer didn't missed > something important, Consideration of all design requirements is always required! > - designers often have an abstract way of thinking. Discussing the > design in the open ensures it can be understood by other people, and > those people are often the ones what will have to use and live with this > design for a long time. Editorial assistance on documenting the design is also a good idea. > And last, but not least, open design strengthens the community : > exchanging ideas helps people to better know each other (especially > important if we don't kwow each other IRL), and there is a lot to learn > by simply watching the process that leads to a strong architecture. Don't think I ever suggested that one should stop exchange ideas? What I'm asking for is 1) someone to try and make sure that the ideas we adopt fit into an overall strategy; 2) someone make sure that the overall strategy and the important architectural and design decisions get documented and published in places where every Cocoon developer can easily find them. For any given piece of Cocoon this "someone" might change, but I also think it would be a good idea if someone also picked up the overall architectural coordination for Cocoon as a whole. > What we also see is the design leader changes with the thing to be > designed. Yes, Stefano is often the leader for high-level Cocoon > architecture and new features, but there are many lower-level design > discussions that are led by people that had the initial idea and want to > push it because they think it is good (e.g. flowscript, modules, forms > handling, tree processor, etc). Remember, my concern isn't so much for the small changes as for the large changes. I really think that a single person has to assume ownership of any large design change and maintain ownership of the idea until it is either finally implemented or shown to be a bad idea (or dies from lack of interest.) I think the only point of difference we have is that I want the discussion leader to also be the architectural "owner" of the idea, the final word so to speak. That doesn't mean that they can't pass ownership or specific design decisions on to someone else if they see fit. >> >>I guess what I would changes is that I would add "architecture", "more >>discussion" and "design" steps between discussion and implementation, and >>architecture and design would also be single person efforts. Not for >>everything, but for the large pieces. >> >>I think that you are doing this to some extent, but I think it would help to >>make it explicit. The big thing that seems to be missing is the >>documentation that would fall out of the architecture and design pieces. >>Even if it's not complete it at least gives a framework into which the >>overall documentation can be pieced together. >> > > Mmmh... I can't speak for Stefano, but I can tell you by personal > experience that being a good architect doesn't imply being a good > documentation writer, nor that an architect has the same motivation for > architecting than for writing docs ;-) I'm not sure that you can be a good architect and not be good at conveying your ideas to others? If a software problem is big enough that an architecture is required then, by definition, you are creating high level documentation for large piece of development that will have many implementers. If you can't document the architecture properly it will never be implemented as expected! Now it doesn't necessarily follow that if you are good at conveying your ideas then you are good at writing, but I'd hope for at least mediocre skills. Certainly, the evidence here is that almost everyone can write pretty darn well... > Dictatorship isn't IMO a good way to manage a lot of newcomers, as they > will simply go away if a single person pisses them off when they propose > something. Umm, that will happen wither way. A benign dictator might actually help, since that way a dissenting opinion isn't necessarily seen as the final word. When it is the architect from a given area that says "no" you may disenfranchise someone, but if enough people get pissed off you've got a revolt on your hands and clearly the leader isn't doing a good job at that point. > Manageability of a large group comes with segmentation. When we will see > a lot of posts on cocoon-dev whose subject is prefixed with a [theme], > then we will ask ourselves if it's time for a separate mailing-list for > the [theme]. Not everybody is interested in the same parts of Cocoon, > and forming different discussion areas is the way to ensure efficiency. Somewhat different issue from what I am worried about. If you got six different ""theme's" off doing their own thing you've still got to make sure the overall strategy for fitting them together makes sense... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
