RE: [eclipse.org-architecture-council] The architecture councilidentity crisis....
First of all, Yes, of course. (The final question)
I know that I'm a rookie in everything that has to do with Eclipse and
the councils but I still think you brought up important questions about
why and what.
When I came to the first meeting I was waiting for architecture diagrams
and discussions about the architecture of different projects or
conceptual issues while it was all about what is the council purpose,
which is very important of course but definitely it wasn't what I was
I guess that first meeting is coming as a guest, second is being part
and third is taking responsibility, so it's all up to us to make this
I agree with Anurag that we should come up with top level architecture
as our output and then drill down to further projects.
I think that one of the output this council should bring is the
architecture of the entire Eclipse projects and their relations and
based on that provide guidelines in order to improve it.
That's what on my mind,
Yossi Leon, Product Manager, Development Tools & PHP IDE Project Leader
yossi@xxxxxxxx http://www.zend.com/ +1-212-645-0040
[mailto:eclipse.org-architecture-council-bounces@xxxxxxxxxxx] On Behalf
Of Scharf, Michael
Sent: Thursday, December 07, 2006 11:21 PM
Cc: Scharf, Michael
Subject: [eclipse.org-architecture-council] The architecture
At the last architecture council face to face meeting, we
came up with the idea to create a forum called "Ask the
architecture council". I was supposed come up with a plan for
such a list. I have been thinking a bit further and I think,
unless we have a clear vision and mission as architecture
council, such an effort will not really take off.
I ask some fundamental questions about the architecture
council. I describe what think (thought) the architecture council
should be. Finally I collected a very incomplete and biased
set of questions. The hope is to start some discussions.
The fundamental questions
The fundamental questions we (the architecture council)
have to solve are:
- What value do we add to eclipse?
- What *is* the architecture council?
- Why do we meet?
- How to get the architecture council to do something useful?
The mailing list is still pretty dead and it seems non of
us really spends a lot of time or energy on it.
I think we should either come up is a clear vision and
mission of what the architecture council is or cancel the
The rest of the mail are some of my thoughts and questions
about the architecture council.
What I thought the architecture council is
When I first came to the architecture council, my
expectation was that this is the group that consciously
thinks about the architectural principles behind eclipse.
I often have the problem that I am not sure that the
architecture principles I extract from looking at good
eclipse projects like the platform are the "right"
principles. This makes it hard for me to "enforce" those
principles in the projects I am working on. I thought this
is the group that distills and spreads the principles. I
find it very hard to "enforce" or "require" anything in a
project, when I am the lonely fighter. I ask myself:
"Is it just my idea?"
"Am I pushing people into the wrong direction just
because I think this is 'right'?"
My hope is that the architecture council becomes the group
that looks at eclipse from a higher level and gives eclipse
a technical direction. Working on a project that has a
certain "culture" it is often very hard to step back and to
see the project without bias. My hope is that the
architecture council can help me to eliminate the blind
When I study excellent software systems, I ask myself what
are the principles are practices behind the system that make
the software successful. Over the years I came to the
conclusion that it does not matter too much what the
principles are, as long as there are used consistently
within the project. I wonder if eclipse still has a set of
principles that are used everywhere and if they are strong
Some ideas and questions for the architecture council
I collected some random questions that came to my mind when
thinking about the architecture council. I tried to put them
into different categories, but there are really a kind of
brainstorming with myself.
- What are the principles that worked in the projects you are
- How are those principles defined? How are they maintained?
- Where is the knowledge encoded? At the moment it seems
that the platform guys are the "gods". Where are the
"gods" in the architecture council? Why are they not coming?
- How can architecture be maintained and increased in
highly distributed software development?
- How can we achieve consistency across the projects?
- We think the platform is a good "blueprint" of how to do
things. How can we spread this knowledge?
- What is the "eclipse way" of doing design and architecture?
- Should we give a talk at eclipsecon about "What is the
- How does your project split code into eclipse projects and
- How do you deal with massive code contributions that have
- How to drastically reduce the massive amount of code?
- How to structure my code into projects?
- How to reduce cross project dependencies?
- How do we enhance cross-project communication?
- How to avoid duplication of code?
- What should become base technology usable by everybody?
- How to find out what's code is out there?
- What is your biggest technical challenge?
- Are there threading concerns in your code?
- What caused performance problems in your code? What can we
learn from that?
- I want to learn about the process of defining good APIs.
- How to define stable APIs and to keep the code flexible at
the same time?
- How to deal with team-blindness?
- What are the principles behind decision making?
I believe that communities are very powerful in making
decisions. However often technical decisions are
made somehow randomly (the one who speaks loudest or
- Should there be a process to think at a higher level
about what is going on?
- Who is reflecting about the technical decisions?
- How to deal with Concerns on how something is done?
I have often seen that people have valid concerns but dare
to speak up. Can we as the architecture council help to
get a process in to place where technical issues are
raises? Maybe by allowing to get anonymously in contact
with the architecture council?
- How to motivate people to do things of technical importance?
Do you think it's worth thinking about those questions? Are
they relevant for the architecture council? Did anybody read
this mail to the end???
eclipse.org-architecture-council mailing list