Skip to main content
Jump to: navigation, search

Difference between revisions of "Architecture Council/About the AC"

(What does the AC?)
(What is the AC?)
Line 1: Line 1:
= What is the AC? =
= What is the AC? =
* From the [[Architecture Council/Bylaws|Eclipse Bylaws]] section 7.2: ''"responsible for the development, articulation, and maintenance of the Eclipse Platform Architecture"'' (as defined in the then current Eclipse Development Process).
* From the [[Architecture Council/Bylaws|Eclipse Bylaws]] section 7.2: responsible for ''"(i) monitoring, guiding, and influencing the software architectures used by Projects, (ii) new project mentoring, and (iii) maintaining and revising the Eclipse Development Process"''.
* From the [ Development Process]: ''"... and ensuring the Principles of the Development Process <b>through mentorship</b>."''
* See also the [ Development Process]
* The role of the AC has evolved since the original [ 2003 Development Process] and the [[Development Process 2006 Revision Final]] to mostly focus on Mentorship.
* The role of the AC has evolved since the original [ 2003 Development Process] and the [[Development Process 2006 Revision Final]] to mostly focus on Mentorship; the charter to care for the Development Process was added with the [[Architecture_Council/Bylaws|2011 Bylaws Change]].
= What does the AC do? =
= What does the AC do? =

Revision as of 17:58, 19 February 2013

What is the AC?

What does the AC do?

The EAC is responsible for the long-term technical health of the Eclipse platforms and frameworks. It involves itself in inter- and intra-project architecture and open source process through discussion during its meetings, mentoring and consultation. The AC is involved in both technical and process aspects because the social and process structure of a project has been shown to have a direct impact on the technical quality of its extensible frameworks and exemplary tools.

From Darin Swanson's Blog about the AC: We all have varied reasons for being involved with Eclipse but we all share a common goal: the desire to see continued technological success and innovation occur at Eclipse fostered by a healthy and vibrant Committer community. The job of the Council is to look out beyond the current work and ensure that our processes and environment foster success rather than impede progress. Instead of just listing the problems (which is always the easiest path), we need to tackle head-on the issues that impact Eclipse, including but definitely not limited to release trains, UI consistency and project diversity. To be successful on our mission the council needs to react to the current and future successes and challenges to Eclipse and to keep informed of developments from the committers. As well, we are tasked to lead by example within our own projects and within the role of mentor.

The AC is a facilitator that helps projects to be successful.

This role for the Architecture Council represents a new (revitalized?) role for the Architecture Council and thus there is not a lot of history to build on. The Council will be as effective and useful as we make it. Here is a recent presentation (PDF, 120K) about what the AC is and what it does in practice.

Who is on the AC?

How does the AC work?

What do AC members gain from their efforts?

  • Being in touch with other leaders
  • First-hand information about interesting trends
  • Networking to re-use common efforts
  • Stronger Eclipse community == stronger own products on top of it
  • Strong base for influencing the future of Eclipse

The cost of this is that it does take some time. We typically talk about at least 4 hours each month for active members: 1 hour for the monthly phone call, 1 hour for organization and E-mail reading to keep up, 1 hour for working on incoming issues and bugs, and 1 hour for interacting with mentored projects.

Any other questions?

Back to the top