[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipse.org-architecture-council] The architecture councilidentity crisis....
|
Michael,
I think these sorts of questions have been bounced around the Architecture
Council at one time or another, but to date little has come of these
discussions. Anyhow, here's some random thoughts about the Architecture
Council:
(1) I don't think it is practical to have every member understand any
significant set of Eclipse projects to a depth that would be useful. This
is because:
(a) There's a lot of projects
(b) Not all the projects are represented directly on the Arch Council --
how do we obtain details about these and discuss issues?
(c) It would take a lot of effort on the part of each Arch Council member
to learn about all the projects -- what is the incentive for this?
Rather, I think we need to rely on experts in each project being on the
Arch Council or at least on the mailing list. Also, I don't think we can
expect to cover all projects at Eclipse -- perhaps we aim at the top-level
projects first?
(2) Documenting the architecture: I think this would be really useful for
consumers (especially strategic consumers), but efforts to do so in the
past have suffered from a number of problems:
(a) Lack of agreement on the representation: Having been a "software
architect" in a previous life, I really don't believe that the typical
box-and-line diagrams are particularly useful. They are mostly like an
abstract paintings -- everyone readily understands them, each in their own
way. So, we'd need to adopt a start architectural documentation standard
(several choices exist). Next, each member would have to become familiar
enough with the notation to understand and contribute to it. Finally, we'd
have to collect the diagrams and maintain them in some location.
(b) So, this turns out to be a lot of work, and hard to justify to each
project owner. We would need someone who benefits from this to drive the
documentation effort over a significant period of time.
(3) The Arch Council as an enforcer of consistency and principles across
projects: This would seem to make a lot of sense, but I can't see the
individual projects submitting themselves to the judgement of the Arch
Council. In general I think that each project has an agenda based on
contributing parties and adjusts their agendas to accommodate community
demands when possible. This leads to the next point:
(4) The Arch Council as watch-dog member in the community: This, I believe,
is the only viable mission of the Arch Council going forward. Simply put, I
suggest that the Arch Council discusses any number of issues (like those
you suggest below, for example) and make recommendations about them is a
very visible place (like the Wiki site companion to the "Ask the
Architecture Council" initiative). Next, the Arch Council acts as a vocal
member of the community (just like any community member would -- enter
bugs, blog, etc.) to pressure for the changes/policies we feel are
important. By "we" here I mean "1 or more members of the Arch Council."
In summary, I think the Arch Council should be a meeting of project
leads/senior project members where good ideas are hatched. Instead of
trying to impose these ideas on projects, however, the Architecture Council
should be a strong voice in the Eclipse community at large.
Regards,
John Graham
Eclipse Data Tools Platform PMC Chair
Staff Software Engineer, Sybase, Inc.
http://dataplat.blogspot.com/
"Yossi Leon"
<yossi@xxxxxxxx>
Sent by: To
eclipse.org-archi "eclipse.org-architecture-council"
tecture-council-b <eclipse.org-architecture-council@e
ounces@xxxxxxxxxx clipse.org>
g cc
Subject
12/08/2006 01:17 RE:
PM [eclipse.org-architecture-council]
The architecture councilidentity
crisis....
Please respond to
"eclipse.org-arch
itecture-council"
<eclipse.org-arch
itecture-council@
eclipse.org>
Hi Michael,
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
expecting.
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
happen.
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
-----Original Message-----
From: eclipse.org-architecture-council-bounces@xxxxxxxxxxx
[mailto:eclipse.org-architecture-council-bounces@xxxxxxxxxxx] On Behalf
Of Scharf, Michael
Sent: Thursday, December 07, 2006 11:21 PM
To: eclipse.org-architecture-council@xxxxxxxxxxx
Cc: Scharf, Michael
Subject: [eclipse.org-architecture-council] The architecture
councilidentity crisis....
Summary
-------
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
architecture council.
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
spots.
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
enough.
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.
Principles
----------
- What are the principles that worked in the projects you are
working on?
- 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
Architecture Council?"
Structural questions
--------------------
- How does your project split code into eclipse projects and
features?
- How do you deal with massive code contributions that have
little functionality?
- 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?
Technical questions
-------------------
- 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?
Social aspects
--------------
- 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
implements wins).
- 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???
Michael
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-counci
l
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
