[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse.org-architecture-council] Portland Council meetings agenda

Talented Council Members,
The Requirements, Architecture, and Planning Councils will be meeting in Portland next week. As you know, we will be meeting at the Hotel Lucia (http://www.hotellucia.com/). The agendas for each Council follow.
I am not planning to have call-in numbers for these face-to-face meetings because mixed f2f and conf.call meetings tend to have lower productivity than either mode by itself. Minutes of the meetings will be published and posted on the website: http://www.eclipse.org/org/council.html


------------------------------------------------------------
*Requirements Council*
>> Tuesday, May 17, 8:30am - 5pm
Mike Milinkovich is chairing this council and will be sending the agenda separately.
A working lunch will be provided.
Lunch-time demo of BIRT and TPTP will provide the entertainment.


>> Tuesday, May 17, evening
A group dinner at a nearby steakhouse is being arranged by Sharon Wolfe.

>> Wednesday, May 18, 9:15am - noon
Plenary session with all three councils. The purpose of this session is for the Strategic Consumers and the Requirements Council as a while to provide input directly to the Architecture and Planning Councils. As part of this plenary session, each Strategic Consumer will have an opportunity to provide a 20-30 minute presentation to the Councils on their requirements. This presentation should be: focused on the project-level technical requirements; backed up with explanations of the impact that this requirement is having on the Strategic Consumer's development; and prioritized. Please note that this communicate mechanism does not replace Bugzilla and the normal flow of requirements. This is an opportunity to explain your high-level requirements directly to the open source leadership. Your requirements must be cross-references to existing bug reports so that they can be tracked using Eclipse's normal processes.
A working lunch will be provided.
Lunch-time demos of WTP and ECF will compete with the gourmet food for your attention.


>> Wednesday, May 18, evening
The Beaverton Open Technology Center is hosting a reception for Eclipse Council members. A further announcement will be forthcoming.


------------------------------------------------------------
*Architecture Council*
>> Tuesday, May 17, noon - 5pm
A working lunch will be provided.
Lunch-time demo of BIRT and TPTP will provide the entertainment.

The first half of the Architecture Council meeting overlaps with the Requirements Council, and some of the members are common between the two Councils. Thus we will keep agenda items likely to generate more controversy to the second day. We will start this first day with:

* Project Boundaries and Council Role in Coordination. How can the
Architecture Council help the technical progress of Eclipse
without creating an overly large bureaucracy? We're an open source
organization, so in some circles that means "no control", but in
fact we're an organization with a deliberate process whose purpose
is to create high-quality frameworks. How does the Architecture
Council help with that?
Tim Wagner and David Williams volunteered to provide an initial set of
talking points for this discussion. (The goal was not to be exhaustive, but
rather to come up with a set of conversation starters so that we can make
use of our limited time in Portland.)
* Monthly Conference Calls. How can we use these calls effectively?
What issues are useful for discussion? What is a good schedule?
What issues should we expect the Projects to bring the Architecture
Council?


>> Tuesday, May 17, evening
A group dinner at a nearby steakhouse is being arranged by Sharon Wolfe.

>> Wednesday, May 18, 9:15am - noon
Plenary session with all three councils. The purpose of this session is for the Strategic Consumers and the Requirements Council as a while to provide input directly to the Architecture and Planning Councils.
A working lunch will be provided.
Lunch-time demos of WTP and ECF will compete with the gourmet food for your attention.


>> Wednesday, May 18, 1pm - 6pm
In the second (disjointed) half of our meeting, we will address the other two agenda items from our April phone call:
* Quality and How to Keep It High.What does it mean to have the
Eclipse brand attached to a project? What are the quality
requirements? As the Technical Leaders for Eclipse, the
Architecture Council members should actively participate in the
various Reviews. We should create agendas for these Reviews
including checklists of gating factors for transitioning from one
project state to the next. I have composed a draft Release Review
agenda (and it was used for the BIRT 1.0 Release Review):
http://www.eclipse.org/org/processes/release-review.html
One of the big issues that arose during the BIRT Release Review
and will arise during the WTP Release Review is the definition
of APIs and the use of provisional APIs and the package
naming scheme for provisional APIs. I have composed a
draft Eclipse Quality APIs document (and it was used for the
BIRT 1.0 Release Review) reachable through the draft
Release Review agenda, third bullet "APIs".
John Wiegand and Bjorn volunteered to provide
an initial set of talking points for this discussion.


* Overlap, Now and in the Future. We need to develop a core
    competency in the Architecture Council for identify and resolving
    overlaps between projects. We need to concentrate on the technical
    aspects of the overlap rather than the project organization
    aspects. And we need to develop a process for consulting
    with/reviewing projects on how to detect and resolve overlaps.
       1. This topic has two sub-topics: the first is the Now
          Overlaps. There are a number of potential or actual overlaps
          amongst the projects right now including DTP-WTP, DSDP-CDT,
          and WTP-Platform.
       2. The second sub-topic is the Future Overlaps. There are a
          number of proposals such as a "Languages group" that would
          involve (or resolve) overlaps. We should have a proactive
          approach to encouraging a good technical resolution to "what
          are the correct architectural units?" and other similar issues.
    We have a short-term agenda item to discuss current overlaps (such
    as the navigator issue and the flexible project structure issue of the
    DTP-WTP and WTP-Platform overlaps).  We should also discuss
    how to deal with common components that are not part of the platform.
    For example, project A has a component X; project B also wants to
    use X; but X is not, and never will be, part of the Platform. Should
    there be a new project C that contains X?  Should A have two
    release - A w/ X and just X - so that B can use X?
    Anurag and Boris volunteered to provide an initial set of
    talking points for this discussion.

>> Wednesday, May 18, evening
The Beaverton Open Technology Center is hosting a reception for Eclipse Council members. A further announcement will be forthcoming.


------------------------------------------------------------
*Planning Council*
>> Tuesday, May 17, noon
Planning council members are invited the technology demos during the working lunch.
Lunch-time demo of BIRT and TPTP will provide the entertainment.


>> Tuesday, May 17, evening
A group dinner at a nearby steakhouse is being arranged by Sharon Wolfe.

>> Wednesday, May 18, 9:15am - noon
Plenary session with all three councils. The purpose of this session is for the Strategic Consumers and the Requirements Council as a while to provide input directly to the Architecture and Planning Councils.
A working lunch will be provided.
Lunch-time demos of WTP and ECF will compete with the gourmet food for your attention.


>> Wednesday, May 18, evening
The Beaverton Open Technology Center is hosting a reception for Eclipse Council members. A further announcement will be forthcoming.


>> Thursday, May 19, 8:30-5pm
A working lunch will be provided.
* Cross-Project Cooperation. Each of the projects brings a distinct and interesting
approach to Eclipse and we'd like to find a way to gather the best of all of them
into our collective development processes and conventions. We need to develop
a core competency in this area - how are we going to do that? All the members
have commercial pressures to do "just their thing" and yet all the members have
joined Eclipse partly because the cooperation and interaction of open source
was deemed to be beneficial. Hence more "time consuming" cross-project
cooperation, communication, and mind-melding will be advantageous - if we
can figure out how to make this happen.


* Participation in Reviews. As the project leaders for Eclipse, the Planning
Council members should ensure that their projects are participating in the
various Reviews, especially those of incubation and top-level projects.
And not just the formal Reviews, but also the discussion period before the
conference call. This participation is important to properly balance a
high quality bar and an inclusive, inviting, and interesting flow of new ideas.
Participation does, however, take time, thus we need to develop processes
to ensure that projects are getting enough reviews. Perhaps we want to
limit the number of Reviews in a given period? Perhaps we want to appoint
Special Reviewers (taken from the broad members, not just from Platform)
to do public reviews?


* Planning, Information, and Synchronized Releases. There are a number of
issues related to planning releases and milestones, and the information
flow around those dates. Specifically: should the projects synchronize
or semi-synchronize their releases? Whether the releases are synchronized
or not, should the release numbers be synchronized or meaningful in some
way? For example, should all releases that are compatible with the Platform
3.1 be released as 3.1? Or should the release numbers have the traditional
meaning local to the project (major releases, minor releases, service updates)?
Should milestones be fixed or can projects change their milestone dates?
And how do we communicate all these dates to the various consumers? (I
suggest we use an RSS feed of the dates to alert consumers to changes.)


* Status Reporting Format. Discussion of the status reporting format that
we, collectively, are content using so that we can generate our Roadmap
inputs at the end of the year without a lot of extra work by any of us.
Similarly, what kind of automatically rolled-up status reporting should
we have (e.g., http://www.eclipse.org/org/processes/master-timeline.php).


* Website Content.  Most of our project pages are out-of-date. We need to
   commit to updating our pages with relevant and useful information, or at
   the very least removing the old and incorrect information.

------------------------------------------------------------
Eclipse is at yet another interesting point in its evolution: success has bred rapid growth. It is our challenge to manage this growth while maintaining the productivity, innovative frameworks, and high quality bar that have made Eclipse great. I look forward to a productive three days of meetings with you all.


--
*Bjorn Freeman-Benson*
Technical Director, Open Source Process and Infrastructure
Eclipse Foundation <http://www.eclipse.org/>
voice: 971-327-7323 (PDT, UTC-7 <http://www.timeanddate.com/worldclock/custom.html?cities=202,188,195>)
email: bjorn.freeman-benson@xxxxxxxxxxx <mailto:bjorn.freeman-benson@xxxxxxxxxxx>


---
[This E-mail scanned for viruses by Declude Virus]