[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse.org-architecture-council] Boston Council meetings (I'm tempted to say "the final revision", but it will probably continue to evolve)

Title: Bjorn Freeman

Council Members,
Here is the "final revision" of the agenda, etc.

The Requirements, Architecture, and Planning Councils will be meeting in Boston August 23, 24, and 25. We will be meeting at the Hotel Marlow. You will need to make your own reservations, and you need to do so soon.

Hotel Marlowe
25 Edwin H. Land Boulevard
Cambridge, MA 02141
617.868.8000

Phone: 1 800 825 7040 for reservations block under “Eclipse Council Meeting Room Block” at the $179.00 rate

ACTION ITEMS: Again, please make your hotel reservations before the block expires. And please let Sharon (sharon@xxxxxxxxxxx) know that you are attending so that she can order enough food.

The new schedule has an overlap between the Requirements and Planning Councils and the four people on both councils will have to choose which meeting to attend. It does, however, solve other schedule problems for other members, so we'll give it a try. Obviously we're still trying to find the perfect Council meeting schedule, so we'll try this and see if it is better or worse than our previous Requirements-Architecture overlap.

  • Tuesday all day - Requirements Council
  • Tuesday all day - Planning Council
  • Wednesday morning - plenary with all three councils
  • Wednesday afternoon - Architecture Council 1/2
  • Thursday morning - Architecture Council 2/2

There will not be call-in numbers for these face-to-face meetings


Requirements Council

Tuesday, August 24, 8:30am - 5pm

  • Quality. Continuing our quality discussion starting with a discussion of the draft Guidelines and the feedback received from the community about these Guidelines. Please note that this documentation also addresses the action item from the last meeting "ACTION: Bjorn and Mike are to define the exit criteria for a checkpoint review."
  • Roadmap. The days are growing shorter and autumn will be upon us in no time at all, and with autumn comes the Eclipse Roadmap process. Last year's Roadmap is available online.
    1. Mike would like all representatives of Strategic Members to come prepared with their input into the Roadmap process. Last year, each person prepared a brief document and/or presentation on their firm's key requirements and presented them to the RC to help kick-start the process.
    2. Roadmap debrief: What worked last year, what changes would be like to see to the process?
  • Requirements Tracking. From the minutes of our last meeting: "Bjorn is to propose a requirements tracking process for Requirements Council. How will the data be tracked and reported?"

Bjorn's Tracking Proposal

There are three issues: 

  1. enumerating the larger architectural requirements
  2. encouraging the projects to implement those requirements
  3. tracking and reporting on the progress of implementations

For item (1), I propose that we add these requirements to the Roadmap document. Specifically, the larger architectural requirements from the Strategic members (Strategic Consumers and Strategic Developers) should be enumerated in the Themes and Priorities section. Where possible, these larger issues should references specific bugs, however we need to acknowledge the "cannot see the forest for the trees" problem with trying to describe larger architectural issues using only point-detailed bug reports. The Themes and Priorities section helps drive the project planning for the next major releases of all the projects, thus including specific architectural constraints will help steer the projects.

For example, SAP has described the "Make Eclipse Ready for Model Driven Development" requirement at previous Council meetings.

For item (2), I propose that the Strategic members use the Council plenary sessions to have a dialog with the relevant projects and then to follow up with one or more team-to-team meetings between the projects. Eclipse projects are run on open source principles, one of which is that direction follows contribution. Historically, requirements placed on Eclipse projects without corresponding development resources are ineffective. The collective buy-in around the Themes and Priorities, combined with direct interaction between Strategic members and the project leaders should help adoption.

For item (3), I propose a live Roadmap Addendum - a summary of the progress made towards implementing the larger architectural requirements. The Roadmap itself is static, but the summary will be automatically generated from the projects' status information. The Strategic member with the larger architectural requirement (and the EMO) can use the summary to watch the promised and actual progress towards implementing the issue. The summary will be available on the eclipse.org website and via a syndication feed.

Tuesday, August 24, evening

A group dinner will be arranged by Sharon Wolfe.

Wednesday, August 25, 8:30am - 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.


Architecture Council

Tuesday, August 24, evening

A group dinner will be arranged by Sharon Wolfe.

Wednesday, August 25, 8:30am - 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.

Wednesday, August 25, noon - 5pm

The first half of the Architecture Council meeting.

Thursday, August 26, 8:30am - noon

The second half of the Architecture Council meeting.

  • 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?
  • 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? We have not had monthly conference calls and I have not received any demands for them, but there is a vague sense that if we had more coordination between projects, that would be good.
  • Quality. Continuing our quality discussion starting with a discussion of the draft Guidelines and the feedback received from the community about these Guidelines.
  • Roadmap. The days are growing shorter and autumn will be upon us in no time at all, and with autumn comes the Eclipse Roadmap process. The Roadmap version 1 had a fairly lame architecture summary of Eclipse - we'd like to do better in Roadmap version 2. What would we like to see? And how can we make that happen?
  • Public Leadership. I'm going to push the idea that project leads (especially technical leads) should be blogging about their projects and their projects' relationship to other things going on in the ecosystem. Eclipse has gained significant traction in the mindshare of "use Eclipse as a Java IDE" and a bit of traction in the "use Eclipse as a tooling platform", but we haven't gained much mindshare in the "open source project" area. Blogging is one way to help change that.

Planning Council

Tuesday, August 24, 8:30am - 5pm

A working lunch will be provided.

  • Synchronized Release Train. Kevin Haaland will describe the mechanics of what projects who are opting-in to the Release Train will be opting-in to. The projects will, at this meeting, opt-in or opt-out.
    • Tyler points out that while that at our previous meeting we agreed that the projects would opt-in or out at this meeting, it may not be possible given that this will be the first time the projects have seen the requirements for doing so.
  • Status Reporting Format. Please read the proposed XML status reporting file format. We will discuss and then agree to something like it, and we will agree to a time line for placing our projects' information in this file format.
  • Roadmap. The days are growing shorter and autumn will be upon us in no time at all, and with autumn comes the Eclipse Roadmap process. The Roadmap version 1 was a real effort to put together. My theory is that the XML status report format will auto-gen the Planning Council parts of the Roadmap, but we should make sure we believe that before we leave Boston.
  • Clean Up Old Websites. A check on whether we accomplished our website updates that we agreed to last meeting; either update old information or remove it. I sent a reminder email on July 9th with some specific out-of-date and incomplete items that I had found on various project websites. Checking those items again on August 6th, I find that only one of them has been fixed. Hence I'm going to assume that we (collectively) did not spend much/any time meeting our commitment to update the project website contents by the date that we (collectively) had agreed to.
  • Standard Website Content. The Committer Get-Together in Beaverton last week resulted in a suggestion that all project websites have four standard links with standard icons and standard locations. This way anybody can find out common information about a project by going to its website and following one of those links. We should decide what those four (or two or three or five) links are, and we should all agree to put them on our sites. Suggestions include: the current plan, the PMC/project leadership minutes, project phase, ... ?
    • Bjorn would like to see the four standard urls be part of the Status Reporting Format XML file, and then have a simple standard php script that generates the four standard links on the project home page.
  • Quality. Continuing our quality discussion starting with a discussion of the draft Guidelines and the feedback received from the community about these Guidelines.
  • Project Log. As part quality discussion and part of the Guidelines and part of the IP Policy that we all signed on to follow, each project should be keeping a Project Log. We will go over what needs to be in that log and how important it is and the time line that the Foundation needs the current copies of the Log.
  • Changes to Bugzilla. Discussion of bug#106263. Wenfeng (BIRT) has requested some additional Bugzilla features to help the BIRT project management. Because we all use Bugzilla, we should discuss the pros and cons of making changes, how we might make changes that are project-agnostic, and whether we want to accept the bugzilla-upgrade risks of making changes.

Tuesday, August 24, evening

A group dinner will be arranged by Sharon Wolfe.

Wednesday, August 25, 8:30am - 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.


I repeat what I said last quarter: "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." 
We're making progress, but we need to keep making progress.

--

Bjorn Freeman-Benson
Technical Director, Open Source Process and Infrastructure
Eclipse Foundation
voice:  971-327-7323 (PDT, UTC-7)
email:  bjorn.freeman-benson@xxxxxxxxxxx

JPEG image