Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Architecture Council/About the AC
Contents
What is the AC?
- From the 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".
- 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 charter to care for the Development Process was added with the 2011 Bylaws Change.
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?
- Architecture Council/Membership Qualifications for members, and how to become a member
- The councils page has the official members list (driven from EMO database)
- The Members and Mentors page includes information about dormant members and proposed mentors of new projects
- Architecture Council/Dormant Status charter
How does the AC work?
- Monthly Architecture Council/Meetings to exchange latest information and spark off discussions
- AC Bugzilla for ongoing discussions until an issue is resolved (File a bug)
- AC Mailing List for ideas and organisational messages (Archives, RSS Feed)
- Personal Architecture Council/Mentorship for guiding projects adopting the development process and being successful
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.