| <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> |
| <html> |
| <head> |
| <title>BIRT Project Charter</title> |
| <link rel="stylesheet" href="../style/compose.css"/> |
| </head> |
| <body> |
| <p class="head">The Business Intelligence & Reporting Tools Project Charter</p> |
| |
| <h1>Overview</h1> |
| |
| The Eclipse Business Intelligence & Reporting Tools Top-Level Project |
| is an open source collaborative software development project dedicated |
| to providing an extensible, standards-based platform to address a broad |
| range of needs in the business intelligence and reporting space using |
| the Eclipse platform. |
| <p> |
| This document describes the composition and organization of the project, |
| roles and responsibilities of the participants, and development process |
| for the project. |
| |
| <h1>Mission</h1> |
| |
| |
| The mission of The Business Intelligence and Reporting Tools Project is |
| to create a wide variety of capabilities that allow developers to easily |
| extract data from data sources, process that data using flexible and powerful |
| data manipulation, sorting and aggregation, and present the processed |
| information in a formatted layout to the end users. |
| <p> |
| The capabilities can range from application- and production-level reporting, |
| through ad hoc user-driven query tools, to highly interactive multi-dimensional |
| online analytical processing (OLAP) and data mining tools. |
| <p> |
| Some level of reporting is a common requirement in the majority of applications |
| developed today - this project provides a focal point for the creation |
| of best-of-breed business intelligence and reporting capabilities for |
| integration into these applications, or as dedicated applications in their |
| own right. |
| |
| <h1>Scope</h1> |
| |
| The Business Intelligence and Reporting Tools Project encompasses capabilities |
| for designing and deploying business intelligence and reporting solutions |
| that will be used within an application. The can broadly be divided into |
| two categories: design tools for authoring, for example, reports; and |
| deployment capabilities for utilizing these designs within an application. |
| <p> |
| Initially, the Project will focus on leveraging the Eclipse platform to |
| provide infrastructure and tools for the designing, deploying, generating |
| and viewing of reports in an organization, including ad hoc query and |
| reporting tools. While not an initial focus, the BIRT project scope includes |
| complementing these reporting capabilities with Online Analytical Processing |
| (OLAP) and Business Intelligence dashboard functionality. Over time, but |
| not in the initial scope, the creation of additional projects is anticipated |
| and encouraged to address additional aspects of business intelligence, |
| such as Executive Information Systems (EIS), statistical analysis, modeling |
| capabilities (what-if analysis), Data Mining Tools, Data Warehouse Modeling |
| Tools, Extract Transform and Load (ETL) tools and Data Quality Tools. |
| <p> |
| It is recognized that BIRT cannot meet all the requirements of all applications |
| and tools that use BIRT. It is therefore a core design principle for all |
| projects within BIRT to support a broad range of extension points within |
| the tools and frameworks that allow developers to address additional needs, |
| and to provide exemplary implementations for these extension points. |
| <p> |
| The list of the Projects under the Business Intelligence and Tools PMC |
| will be maintained as part of <a href="index.php" target="_top">Business |
| Intelligence and Reporting Tools Project</a>. |
| </p> |
| |
| <h1>Project Management Committee</h1> |
| |
| The Projects under this Charter are managed by a group known as the Project |
| Management Committee (the "PMC"). |
| <p> |
| PMCs are expected to ensure that: |
| |
| <ul> |
| <li>All Projects operate effectively by providing leadership to guide |
| the Project's overall direction and by removing obstacles, solving problems, |
| and resolving conflicts. </li> |
| |
| <li>All Project plans, technical documents and reports are publicly available. |
| </li> |
| |
| <li>All Projects operate using open source rules of engagement: meritocracy, |
| transparency, and open participation. These principles work together. |
| Anyone can participate in a Project. This open interaction, from answering |
| questions to reporting bugs to making code contributions to creating |
| designs, enables everyone to recognize and utilize the contributions. |
| </li> |
| |
| </ul> |
| |
| <p>The PMC has the following responsibilities: </p> |
| |
| <ul> |
| <li>Providing the leadership and vision to guide the Project's overall |
| direction in a manner consistent with the Eclipse Foundation Architectural |
| Roadmap. </li> |
| |
| <li>Providing assistance and support to the developers and researchers |
| working on the Project by removing obstacles, solving problems, and |
| resolving conflicts. </li> |
| |
| <li>Ensuring that Project plans are produced. </li> |
| |
| <li>Working with the Eclipse Management Organization (the "EMO") |
| to establish the development processes and infrastructure needed for |
| the development team to be effective. </li> |
| |
| <li>Recommending new Projects to the EMO. </li> |
| |
| <li>Recommending the initial set of Project committers for each new Project |
| overseen by the PMC, and establishing the procedures consistent with |
| this Charter for voting in new committers. </li> |
| |
| <li>Helping to ensure that the Projects overseen by the PMC have enough |
| contributors, and working to fill vacancies in roles. </li> |
| |
| <li>Producing "how to get involved" guidelines to help new potential |
| contributors get started. </li> |
| |
| <li>Coordinating relationships with other Eclipse Foundation Projects. |
| </li> |
| |
| <li>Facilitating code or other donations by individuals or companies. |
| </li> |
| |
| <li>Making recommendations to the Eclipse Foundation Board regarding contributions |
| proposed under licenses other than the EPL. </li> |
| |
| <li>Working with the EMO and Committers to ensure in-bound contributions |
| are made in accordance with the Eclipse Foundation IP Policy. </li> |
| |
| <li>Acting as a focal point for the community in representing the Projects |
| it oversees. </li> |
| |
| </ul> |
| |
| <p> |
| The PMC Lead is appointed by the Board. The initial PMC is selected by |
| the PMC Lead. Thereafter, to become a member of the PMC, an individual |
| must be nominated by another member of the PMC, and unanimously approved |
| by all PMC members. |
| <p> |
| In the unlikely event that a member of the PMC becomes disruptive to the |
| process or ceases to contribute for an extended period, the member may |
| be removed by unanimous vote of remaining PMC members. PMC members may |
| resign at any time by delivering notice of their resignation to the PMC |
| Lead. |
| <p> |
| The PMC is responsible for producing and maintaining the Project Charter. |
| Development must conform to any rules or processes outlined in the Charter, |
| so a change to the development process may necessitate a change to the |
| Charter. Changes to the Charter are approved by the Board. |
| <p> |
| The work of the PMC is shared by the PMC members. All PMC members are |
| expected to contribute actively. In particular, PMC members are expected |
| to take responsibility for overseeing certain areas of work in the Project, |
| and reporting to the PMC on these areas. |
| <p> |
| Active participation in the user newsgroups and the appropriate developer |
| mailing lists is a responsibility of all PMC members, and is critical |
| to the success of the Project. PMC members are required to monitor the |
| main Project mailing list, and the developer mailing lists for all Projects |
| and components they are overseeing. |
| </p> |
| |
| <h1>Project Requirements Group</h1> |
| |
| The Requirements Group is formed at the discretion of the PMC. The Requirements |
| Group gathers requirements for the project and communicates them to all |
| members of the Project, including the PMC. The Requirements Group will |
| accomplish its objectives by working closely with the development teams |
| and the PMC. |
| </p> |
| |
| <h1>Project Architecture Group</h1> |
| |
| The Architecture Group is formed at the discretion of the PMC. The Architecture |
| Group is responsible for development, articulation and maintenance of |
| the Project Architecture, as well as for providing an explicit description |
| of the architecture and communicating this description to all members |
| of the Project, and for releasing it as part of the project deliverables. |
| The Architecture Group will accomplish its objectives by working closely |
| with the development teams and the PMC. |
| </p> |
| |
| <h1>Project Planning Group</h1> |
| |
| The Planning Group is formed at the discretion of the PMC. The Planning |
| Group assists the PMC in establishing the Project plan in conjunction |
| with available Project resources, coordinating relationships between Project |
| participants and with other Eclipse projects. The Planning Group helps |
| to ensure that projects have enough contributors, filling vacancies in |
| roles and facilitating code or other donations by individuals or companies. |
| The Planning Group will accomplish its objectives by working closely with |
| the development teams and the PMC. |
| </p> |
| |
| <h1>Roles</h1> |
| |
| The Projects under this Charter are operated as meritocracies -- the more |
| you contribute, and the higher the quality of your contribution, the more |
| you are allowed to do. However with this comes increased responsibility. |
| <p> |
| <dl> |
| <dt>Users</dt> |
| <dd> |
| Users are the people who use the products that the Project produces. People |
| in this role aren't contributing code, but they are using the products, |
| reporting bugs, and making feature requests and suggestions. Users are |
| encouraged to participate through the user newsgroup(s), asking questions, |
| providing suggestions, and helping other users. Users are also encouraged |
| to report problem reports using the bug tracking system. </dd> |
| |
| <dt>Developers</dt> |
| <dd> |
| Users who contribute code or documentation become developers. Developers |
| are the people who contribute code, fixes, documentation, or other work |
| that goes into the product. Developers are also encouraged to participate |
| in the user newsgroup(s), and should monitor the developer mailing list |
| associated with their area of contribution. When appropriate, developers |
| may also contribute to development design discussions related to their |
| area of contribution. Developers are expected to be proactive in reporting |
| problems in the bug tracking system. </dd> |
| |
| <dt>Committers </dt> |
| <dd> |
| Developers who give frequent and valuable contributions to a Project, |
| or component of a Project (in the case of large Projects), can have their |
| status promoted to that of a "Committer" for that Project or |
| component respectively. A Committer has write access to the source code |
| repository for the associated Project (or component), and gains voting |
| rights allowing them to affect the future of the Project (or component). |
| </dd> |
| </dl> |
| <p> |
| In order for a Developer to become a Committer on a particular Project |
| overseen by the PMC, another Committer for the same Project (or component |
| as appropriate) can nominate that Developer or the Developer can ask to |
| be nominated. Once a Developer is nominated, the Committers for the Project |
| (or component) will vote. If there are at least 3 positive votes and no |
| negative votes, the Developer is recommended to the PMC for commit privileges. |
| If the PMC also approves and the Developer signs the Committer Agreement |
| established by the EMO (wherein, at the very least, the Developer agrees |
| to abide by the Eclipse Intellectual Property Policy), the Developer is |
| converted into a Committer and given write access to the source code repository |
| for that Project (or component). Becoming a Committer is a privilege that |
| is earned by contributing and showing discipline and good judgment. It |
| is a responsibility that should be neither given nor taken lightly. |
| <p> |
| At times, Committers may go inactive for a variety of reasons. The decision |
| making process of the Project relies on active committers who respond |
| to discussions and votes in a constructive and timely manner. The PMC |
| is responsible for ensuring the smooth operation of the Project. A Committer |
| that is disruptive, does not participate actively, or has been inactive |
| for an extended period may have his or her commit status removed by the |
| PMC. |
| <p> |
| Active participation in the user newsgroup and the appropriate developer |
| mailing lists is a responsibility of all Committers, and is critical to |
| the success of the Project. Committers are required to monitor and contribute |
| to the user newsgroup. |
| <p> |
| Committers are required to monitor the developer mailing list associated |
| with all Projects and components for which they have commit privileges. |
| This is a condition of being granted commit rights to the Project or component. |
| It is mandatory because committers must participate in votes (which in |
| some cases require a certain minimum number of votes) and must respond |
| to the mailing list in a timely fashion in order to facilitate the smooth |
| operation of the Project. When a Committer is granted commit rights they |
| will be added to the appropriate mailing lists. A Committer must not be |
| unsubscribed from a developer mailing list unless their associated commit |
| privileges are also removed. |
| <p> |
| Committers are required to track, participate in, and vote on, relevant |
| discussions in their associated Projects and components. There are three |
| voting responses: +1 (yes), -1 (no, or veto), and 0 (abstain). |
| <p> |
| Committers are responsible for proactively reporting problems in the bug |
| tracking system, and annotating problem reports with status information, |
| explanations, clarifications, or requests for more information from the |
| submitter. Committers are responsible for updating problem reports when |
| they have done work related to the problem. |
| <p> |
| <h1>Projects</h1> |
| |
| The work under this Top Level Project is further organized into Projects. |
| New Projects must be significant works consistent with the mission of |
| the Top Level Project, be recommended by the PMC, and confirmed by the |
| EMO. Projects can be discontinued by decision of the Board. |
| <p> |
| When a new Project is created, the PMC nominates a Project lead to act |
| as the technical leader and nominates the initial set of Committers for |
| the Project, and these nominations are approved by the EMO. Project leads |
| are accountable to the PMC for the success of their Project. |
| </p> |
| |
| <h1>Project Components </h1> |
| |
| The PMC may decide to divide a Project further into components. If a Project |
| is divided into components, commit privileges are normally granted at |
| the component level, and the committers for a given component vote on |
| issues specific to that component. Components are established and discontinued |
| by the PMC. When the PMC creates a component it appoints a component lead |
| to act as the technical leader and names the initial set of Committers |
| for the component. The component lead is designated as a committer for |
| the Project and represents the component in discussions and votes pertaining |
| to the Project as a whole. Component Committers do not participate in |
| votes at the level of the Project as a whole, unless they are also the |
| component lead. |
| </p> |
| |
| <h1>Ports</h1> |
| |
| For components that contain platform-specific code, it may be advantageous |
| to allow developers to work on a port of the component to a new platform |
| without requiring that they already be committers for the component. In |
| this case the main code base is known as the component "core", |
| and the port code base is known as a component "port". The decision |
| to set up a port is made by the PMC. When a new port of a component is |
| created, the PMC appoints a Port Lead, and an initial set of committers |
| who will have commit and voting privileges specifically for the port. |
| The port is done under the auspices of the core component, and all committers |
| for the core component automatically also have commit and voting privileges |
| on the port. Normally the Component Lead will also be the Port Lead. |
| </p> |
| |
| <h1>Coordinated Release Cycles</h1> |
| |
| All projects and components under this Project will have coordinated release |
| plans, milestone dates, freeze cycles, builds, and ship dates. These projects |
| will be coordinated by a group consisting of the project leads, the component |
| leads from these projects, and the members of the PMC assisted by the |
| members of the Planning Committee. |
| </p> |
| |
| <h1>Infrastructure</h1> |
| |
| The PMC works with the EMO to ensure the required infrastructure for the |
| Project. The Project infrastructure will include, at minimum: <br> |
| </p> |
| |
| <dl> |
| <dt>Bug Database</dt> |
| <dd>Bugzilla-like database for tracking bugs and feature |
| requests. </dd> |
| |
| <dt>Source Repository</dt> |
| <dd>One or more CVS repositories containing both the |
| master source code and documentation for the projects. </dd> |
| |
| <dt>Website</dt> |
| <dd>A Web site will contain information about the project, including |
| documentation, downloads of releases, and this charter. </dd> |
| |
| <dt>General Mailing List</dt> |
| <dd>Mailing list for development discussions pertaining |
| to the project as a whole or that cross projects. This mailing list |
| is open to the public. </dd> |
| |
| <dt>Project Mailing Lists</dt> |
| <dd>Development mailing list for technical discussions |
| and committer voting related to the project. These mailing lists are |
| open to the public. </dd> |
| |
| <dt>Component Mailing Lists</dt> |
| <dd>Development mailing list for technical discussions |
| and committer voting related to the component. This mailing list is |
| open to the public. </dd> |
| |
| <dt>Newsgroup</dt> |
| <dd>A newsgroup where users, developers, and committers can |
| interact regarding general questions and issues about the project. </dd> |
| |
| </dl> |
| |
| <h1>The Development Process </h1> |
| |
| Each Project lead must produce a development plan for the release cycle, |
| and the development plan must be approved by the PMC and by a majority |
| of Committers of the Project. |
| <p> |
| Each Project must identify, and make available on its web site, the requirements |
| and prioritizations it is working against in the current release cycle. |
| In addition, each Project must post a release plan showing the date and |
| content of the next major release, including any major milestones, and |
| must keep this plan up to date. |
| <p> |
| The Committers of a Project or component decide which changes may be committed |
| to the master code base of a Project or component respectively. Three |
| +1 ('yes' votes) with no -1 ('no' votes or vetoes) are needed to approve |
| a code change. Vetoes must be followed by an explanation for the veto |
| within 24 hours or the veto becomes invalid. All votes are conducted via |
| the developer mailing list associated with the Project or component. |
| <p> |
| Special rules may be established by the PMC for Projects or components |
| with fewer than three Committers. For efficiency, some code changes from |
| some contributors (e.g. feature additions, bug fixes) may be approved |
| in advance, or approved in principle based on an outline of the work, |
| in which case they may be committed first and changed as needed, with |
| conflicts resolved by majority vote of the Committers of the Project or |
| component, as applicable. More restrictive rules for releasing changes |
| may be established by the PMC near the end of release cycles or for maintenance |
| streams. |
| <p> |
| The master copy of the code base must reside on the Project web site where |
| it is accessible to all users, developers and committers. Committers must |
| check their changes and new work into the master code base as promptly |
| as possible (subject to any check-in voting rules that may be in effect) |
| in order to foster collaboration among widely distributed groups and so |
| that the latest work is always available to everyone. The PMC is responsible |
| for working with the Eclipse Foundation to establish a release engineering |
| and build process to ensure that builds can be reliably produced on a |
| regular and frequent basis from the master code base and made available |
| for download from the Project web site. |
| <p> |
| The PMC is responsible for establishing the level of testing appropriate |
| for each Project, and approving the test plans. |
| <p> |
| All development technical discussions are conducted using the development |
| mailing lists. If discussions are held offline, then a summary must be |
| posted to the mailing list to keep the other committers informed. |
| </p> |
| |
| <h1>Licensing</h1> |
| |
| All contributions to Projects under this Charter must adhere to the Eclipse |
| Foundation Intellectual Property Policy. <br> |
| </body> |
| </html> |