Re: [eclipse.org-architecture-council] The architecture council identity

[Valentina Popescu <popescu@xxxxxxxxxx>]

Michael, 
It feels good to read your note and
feels even better to comment on your ideas :)

My own view on how to make the AC effective
is to start by reviewing its charter; this should be a document where shall'
or 'may' will not have a place.

I assume that every member of the AC
is either the AG lead for the project it represents or a technical lead
of the project. So at the AC level, it is not about guiding their team
but working with the rest of the technical leads and guide the Eclipse
project community as a whole. 

Two of the AC imperatives to be added
to the charter ( this is an incomplete list but it covers the most important
things as I see them )

- cooperate at a technical level
to impose good integration between projects; report back to AC on their
execution 
The catalog of reusable assets is a
good fit for this. Any other integration issues should be brought up, reviewed
and have recommendations on how to fix them.

- based on technical decisions made
at the AC level, provide technical guidelines to their own projects; report
back to AC on their execution
Basic samples : jarred plugins, plugin
manifest files, string properties to use NLS bundle and be removed from
the plugin.properties

- technically mentor new projects


I see AC being no different than the AG leader of an Eclipse project contributed
to by different groups. At the end of the day, the mission of the AG lead
is to guide the project in such a way that the functionality offered by
the project satisfies all groups while integrating with the rest of the
project's capabilities. The end user satisfaction is the main goal.

Thank you,
Valentina Popescu
Senior Advisory Analyst
IBM Toronto Labs
Phone:  (905)413-2412         (tie-line  969)
Fax: (905) 413-4850

"Scharf, Michael" <Michael.Scharf@xxxxxxxxxxxxx>
Sent by: eclipse.org-architecture-council-bounces@xxxxxxxxxxx

12/07/2006 11:20 PM

Please respond to
"eclipse.org-architecture-council"        <eclipse.org-architecture-council@xxxxxxxxxxx>

To	<eclipse.org-architecture-council@xxxxxxxxxxx>
cc	"Scharf, Michael" <Michael.Scharf@xxxxxxxxxxxxx>
Subject	[eclipse.org-architecture-council] The architecture council        identity 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-council