| <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> |
| <html> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> |
| <title>Eclipse Business Intelligence & Reporting Tools</title> |
| <link rel="stylesheet" href="../eclipse-webtools/templates/eclipse/eclipse.css"></head> |
| <body text="#000000" bgcolor="#ffffff" link="#0000ee" vlink="#551a8b" alink="#ff0000"> |
| |
| <table BORDER=0 CELLSPACING=5 CELLPADDING=2 WIDTH="100%" > |
| <tr> |
| <td ALIGN=LEFT width="60%"><font class=indextop>business intelligence & reporting |
| tools</font><br> |
| <font class=indexsub>Project Charter</font></td> |
| <td WIDTH="40%"><img SRC="../../images/Idea.jpg" HSPACE=50 height=86 width=120 align=CENTER></td> |
| </tr> |
| </table> |
| |
| <p>This project proposal is in the <a href="/projects/dev_process/"> |
| Proposal Phase</a> and is posted here to solicit community feedback, additional |
| project participation and ways the project can be leveraged from the Eclipse |
| membership-at-large. You are invited to comment on and/or join the project. |
| Please send all feedback to the <a href="http://www.eclipse.org/newsportal/thread.php?group=eclipse.birt">eclipse.birt |
| newsgroup</a> or the <a href="https://dev.eclipse.org/mailman/listinfo/birt-proposal"> |
| birt-proposal</a> mailing list.</p> |
| <table BORDER=0 CELLSPACING=5 CELLPADDING=2 WIDTH="100%" > |
| <tr> |
| <td ALIGN=LEFT VALIGN=TOP COLSPAN="2" BGCOLOR="#0080C0"><b><font color="#FFFFFF" face="Arial,Helvetica">The Eclipse Business Intelligence & Reporting Tools Top-Level Project Charter</font></b></td> |
| </tr> |
| |
| <tr> |
| <td> |
| <p><b>Overview</b><br> |
| 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.<br> |
| <br> |
| This document describes the composition and organization of the project, |
| roles and responsibilities of the participants, and development process |
| for the project. </p> |
| <p><b>Mission</b><br> |
| 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.<br> |
| <br> |
| 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.<br> |
| <br> |
| 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.<br> |
| </p> |
| <p><b>Scope</b><br> |
| 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.<br> |
| <br> |
| 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. Over time, the creation of |
| additional projects is anticipated and encouraged to address additional |
| aspects of business intelligence, such as Online Analytical Processing |
| (OLAP), statistical analysis, Extract Transform and Load (ETL) tools and |
| so forth.<br> |
| <br> |
| The list of the Projects under the Business Intelligence and Tools PMC |
| will be maintained as part of <a href="index.html" target="_top">Business |
| Intelligence and Reporting Tools Projec</a>t.</p> |
| <p><b>Project Management Committee</b><br> |
| The Projects under this Charter are managed by a group known as the Project |
| Management Committee (the "PMC").<br> |
| <br> |
| PMCs are expected to ensure that: <br> |
| </p> |
| <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>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> |
| <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> |
| <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> |
| <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> |
| <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> |
| <p><b>Requirements Group</b></p> |
| <p>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> |
| <p><b>Architecture Group</b></p> |
| <p>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> |
| <p><b>Project Planning Group</b></p> |
| <p>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> |
| <p><b>Roles</b><br> |
| 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> |
| <p><i>Users</i><br> |
| 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. </p> |
| <p><i>Developers</i><br> |
| 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. </p> |
| <p><i>Committers</i><br> |
| 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). |
| </p> |
| <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> |
| <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> |
| <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> |
| <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> |
| <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> |
| <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> |
| <p><b>Projects</b><br> |
| 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> |
| <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> |
| <p><b>Project Components</b> </p> |
| <p>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. <br> |
| </p> |
| <p><b>Ports</b><br> |
| 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> |
| <p><b>Coordinated Release Cycles</b><br> |
| 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> |
| <p><b>Infrastructure</b><br> |
| The PMC works with the EMO to ensure the required infrastructure for the |
| Project. The Project infrastructure will include, at minimum: </p> |
| <ul> |
| <li>Bug Database - Bugzilla-like database for tracking bugs and feature |
| requests. </li> |
| <li>Source Repository - One or more CVS repositories containing both the |
| master source code and documentation for the projects. </li> |
| <li>Website - A Web site will contain information about the project, including |
| documentation, downloads of releases, and this charter. </li> |
| <li>General Mailing List - Mailing list for development discussions pertaining |
| to the project as a whole or that cross projects. This mailing list |
| is open to the public. </li> |
| <li>Project Mailing Lists - Development mailing list for technical discussions |
| and committer voting related to the project. These mailing lists are |
| open to the public. </li> |
| <li>Component Mailing Lists - Development mailing list for technical discussions |
| and committer voting related to the component. This mailing list is |
| open to the public.</li> |
| <li>Newsgroup - A newsgroup where users, developers, and committers can |
| interact regarding general questions and issues about the project. </li> |
| </ul> |
| <p><b>Development Process</b><br> |
| 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> |
| <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> |
| <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> |
| <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> |
| <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> |
| <p>The PMC is responsible for establishing the level of testing appropriate |
| for each Project, and approving the test plans. </p> |
| <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> |
| <p><b>Licensing</b><br> |
| All contributions to Projects under this Charter must adhere to the Eclipse |
| Foundation Intellectual Property Policy.</p> |
| <p> </p> |
| </td> |
| </tr> |
| </table> |
| |
| </body> |
| </html> |
