[
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]
