Architecture Council Minutes October 25 2007

(see Architecture Council)

October 25, 2007 Architecture Council Call

Topics of discussion included:

Overlap Between Projects

Brian observed that there is overlap between projects at Eclipse and what could we, the Architecture Council, do to reduce that. Jeff restated this as "how to foster, not force, cooperation". Step one is awareness of the issue. There is enough going on at Eclipse, that it is likely that some overlap may be due to a simple lack of knowledge of the other group's efforts. The Architecture Council members are well position to see and alert projects to duplicate work.

We discussed the difficulty of cooperation. Bjorn thought that the benefits on small things was probably too low to justify the effort, but as the component grew in size, the benefits of cooperation also grew: a trade-off between the effort of communication and the effort of implementation. Someone described this as "willing to make the investment if you trust that you will get something back".

Jeff suggested that we encourage the committers to use the (newly opened) committers mailing list for queries and conversations with other committers about reuse, e.g., "I'm looking for this", "I have this problem", etc. Something like an RSS feed of "problem of the week".

Jeff took the action item to send email to the committers mailing list describing this vision. Completed Oct 25.

Brian took the action item to contact the teams where he has seen overlaps to make them aware of the situation.

Martin took the action item to start a whiteboard wiki page of overlaps. The idea is to keep a record of them when we find them, partly for the teams use and partly as documentation for the larger Eclipse community.

EclipseCon Awards

Bjorn asked for ideas for the Awards that we give out at EclipseCon each year. Perhaps we can change the awards to promote "good behavior" rather than just be a voting situation. For example, if we could find a numeric measure for "best contributor", we could encourage that behavior (through the ranking and the award). The Council members agreed to think about it.

EclipseCon Hackathon

Jeff brought up the idea of an Eclipse Hackathon at EclipseCon this year, a la the ApacheCon Hackathons. We liked the idea. We mulled over the potential downsides (takes committers away from the main activities, could turn into a code camp of "helping users", etc) but we decided that the good out weighed the bad. We decided that it would be informal attendance (no signups) and that projects would do their own promotion, e.g., CDT team: meet in the "hackathon attic wednesday after lunch". Program chairs will want to schedule their categories to allow blank spots for the teams to wander off to the attic.

Bjorn took the action item to reserve a room with whiteboards, flipcharts, long tables, and powerstrips. Completed Oct 25.

Incubators: How Many, How Structured

We talked about whether incubator projects should be one per top-level or one per sub-project, e.g., should there be a Tools Incubator or a CDT Incubator and a Mylyn Incubator and a PDT Incubator and a ... etc. We did not come up with a firm recommendation as there are pros and cons to both.