P
Progress Community
Guest
Progress Software Common Component Specification Project Charter Document Charter Document Version : 1.1 Charter Document Last Modified : November 4, 2015 Introduction Progress, together with its partners and customers, will create Common Component Specifications (CCS) for the use in building modern ABL applications. A Common Component Specification is defined as a set of ABL Interfaces and APIs that make up a major subsystem of a Progress® OpenEdge® Reference Architecture (OERA) modernization framework. Specific examples of Common Component Specifications include Security, Session Management and Logging. The transformation of OpenEdge applications is happening globally with a number of different modernization frameworks. These frameworks are developed independent of each other and are not based on any standards. Every modern business application needs common functionality, such as security, configuration, session management and more. The goal of the CCS project is to develop a standard set of specifications for various common components needed in business applications by engaging the OpenEdge community and leveraging its expertise in building best business applications. Such specifications will include API definitions and interfaces, expected behavior and other collateral to sufficiently define the component. Compliance to a common component specification would enable the components of different framework components to work interchangeably, thus providing the end user the flexibility to swap components based on merit. Compliance will offer end users the ability to choose between implementations. In addition, end users will be able to switch implementations with a minimal amount of porting effort. Finally, the Common Component Specifications will also enable creation of standard tools that can be used across multiple framework vendors, thus providing more productivity to framework end users. The specifications will be based on the OpenEdge Reference Architecture . About the Common Component Specification Project Progress will create a participant pool with representatives from our global community of customers and partners. This group will work toward the goal of providing governance to produce a Common Component Specification for application modernization frameworks. CCS Governing Bodies The Common Component Specification has two sets of governing bodies: The CCS Steering Committee CCS Specification teams There may be many CCS Specification teams, but there is only one CCS Steering Committee. Charter of the CCS Steering Committee The CCS Steering Committee has the following charter: Define and drive the standardization process for common components Identify and resolve process issues Approve specification proposals from community members Approve final specification submissions from CCS Speficiation teams Disband dormant CC Specification teams Selection of the CCS Steering Committee The initial make-up of the CCS Steering Committee will be as follows: Progress will be the chair of the committee It will contain five voting members (Progress and four other voting members) Progress® Bravepoint™ will be a voting member independent of Progress for the first term of the CCS Steering Committee If a CCS Steering Committee member fails to make three sequential meetings, the Chair may remove him or her and seek another CCS Steering Committee member. After the first two years, elections will be held to determine who serves on the CCS Steering Committee. Progress, will have a permanent chairmanship and a permanent vote. Elections are held every two years. Every company who has at least one Participant gets to vote for four separate companies to have representatives on the CCS Steering Committee. All CCS Steering Committee decisions are made by majority vote. Participants Any OpenEdge community member who has signed contracts and agreements for the Common Component Specification Project are known as Participants (PT). On-boarding of the PT will be based on certain criteria. PTs can have multiple roles in different projects and can be members of the CCS Steering Committee, Specification Team Lead or Team member. The PT can review specifications during the specification creation process, thus influencing the direction of the specifications, as well as access specifications early during the request for comments phases of the specifications. Specification Teams A CCS Specification team is a group of Participants working on a CCS specification. Every CCS Specification team has a team lead and three separate Participants from three separate companies working on the team. Any Participant can submit a specification proposal to the CCS Steering Committee. If the CCS Steering Committee approves a specification proposal, the Participant submitting the proposal becomes the CCS Specification team lead. To proceed with the specification effort, the CCS Specification team lead must create a CCS Specification team of at least three Participants from three different companies who agree to participate in the CCS Specification team. The CCS Specification team lead can decide to cap the Participants at six team members from six companies. Upon receiving acceptance from the CCS Steering Committee, the CCS Specification team lead must invite all Participants to participate on the CCS Specification team. Each company who is a Participant is allowed to identify up to two individuals to participate in the effort. The invitation period is required to be two weeks or until a minimum number of community members agree to participate in the process. During the two-week invitation period, the CCS Specification team lead cannot reject a Participant as a CCS Specification team member, if the current team has fewer than six people from six separate companies. Once the invitation period has closed, the CCS Specification team lead is not required to (but is allowed to) welcome additional Participants to the team, as long as there are at least three team members from three separate companies. Specification Team Lead Responsibilities The CCS Specification team lead’s responsibilities are as follows: Organize a community mailing list for the team to communicate and for non-team members to observe Recruit and identify team members Organize regular meetings with team members to move the specification forward Deliver the specification on the timeframe made in the specification proposal and on the objectives identified in the specification proposal Remove team members who are not participating in the specification effort Team Member Responsibilities Specification team members have the following responsibilities: Commit two to three hours a week working on the specification Attend team meetings on a regular basis Provide constructive feedback and suggestion that help advance the objectives of the specification The Specification Process The high-level specification process is as follows: Participant submits specification proposal to the CCS Steering Committee. CCS Steering Committee approves or rejects the proposal (criteria to be defined). If the CCS Steering Committee accepts the proposal, the submitter of the proposal becomes the Specification team lead and forms a CCS Specification team. The CCS Specification team using the standard community specification template begins working on the specification. The specification is expected to contain APIs and interfaces for the component and how the component interacts with other specifications. The specification will also contain compliance criteria and/or test suite for compliance of the specification. The CCS Specification team completes a Community Review Draft of the specification to be submitted to the CCS Steering Committee. Within 14 days, the CCS Steering Committee will either approve or reject the Community Review Draft of the specification. If the Community Review Draft of the specification is approved the specification is published to the entire Participant list for a review period, no shorter than 30 days and no longer than 90 days. After the community review period is over, the CCS Specification team incorporates comments it received from the Participants and works toward a proposed final draft. When the CCS Specification team is ready, it submits a Proposed Final Draft of the specification for approval to the CCS Steering Committee. Upon submitting the specification to the CCS Steering Committee, the CCS Steering Committee has two weeks to either approve or reject the specification. If the CCS Steering Committee approves the Proposed Final Draft, the specification becomes a CCS versioned and approved specification. This approved specification will then be available to a broader OpenEdge community. Making decisions within a Specification Team It is the desire that there be unanimous agreement on all aspects of a specification being produced by a CCS Specification Team. However, it is also recognized this is not always achievable. People within the OpenEdge community have years of experience successfully solving things via different technical approaches. In the event that a CCS Specification team can’t reach consensus on a particular topic, the CCS Specification team lead is responsible for driving a resolution via the following process: Present all the approaches being discussed, in the act of doing so, providing each CCS Specification team member with an opportunity to present their approach and / or opinion on a presented approach. Call for a vote on the approaches presented. Each member of the CCS Specification team gets exactly one vote. A simple majority is required to pass the vote. In the event of an even number of CCS Specification team members, and the result of the vote is a tie, the vote of the CCS Specification team lead breaks the tie. CCS Specification team members have the option to abstain on a given vote. CCS Specification team members are responsible for voting on all topics in a timely manner. When calling for a ballot the CCS Specification team lead should set a reasonable time frame for CCS Specification team members to cast a vote. At this time we are not specifying what time frame is considered reasonable. In the event there are issues on a given ballot over the overall fairness of the CCS Specification team’s voting process, CCS Specification team members have the option of escalating an issue to the CCS Steering Committee. The CCS Steering Committee can be contacted at the following mailing list: ccs-st-committee@progress.com . Commitment Progress Commitment to Our Committee Members As part of our ongoing commitment to this committee, Progress is dedicated to providing an open platform for the exchange of ideas and, ultimately, the agreement of specifications for each component. Criteria for Accepting a Specification Upon receiving a specification request from a Participant, the CCS Steering Committee uses the following criteria to evaluate it as a possible standardization effort: Is the proposed specification something essential that all modernization frameworks will need? Are there multiple implementations of the functionality in existence today? Is the proposed timeline for delivering and developing the specification acceptable? Does the community member have the appropriate background to lead the specification effort? In an effort to complete a first revision of the modernization specifications, we anticipate the CCS Steering Committee will be extremely stringent in adhering to the criteria listed above regarding what specifications are accepted. Participant Benefits Compliance to a common component specification would enable the components of different framework components to work interchangeably. By being a Participant, your company has influence, both direct and indirect, over the direction of component specifications: Gain access to common component specifications while they are being developed, Directly impact specifications for a component by leading or being part of the project team for a specific specification Influence other component specification projects through community reviews, discussion forums and meetings Share best practices and form alliances with other OpenEdge partners and customers Participant Criteria The CCS Specification teams will consist of Progress employees, customers, partners and Service Delivery partners from the Progress community. Participants may be from any size or type of company, from any location globally. Please note the regularly scheduled meetings will be conducted during normal business hours in the Eastern Time Zone of the U.S. Participant Termination Progress reserves the right to terminate participation from the Common Component Specification Project at any time. Termination of a membership may result from: Missing two or more consecutive regularly scheduled meetings Misconduct (such as inappropriate behavior in meetings or abuse of their position on the Common Component Specification Project for personal gain) Violating the intent and philosophy of the Common Component Specification Project Charter in any way Violating the terms of Common Component Specification Contributor License Agreement . Participant Application To become a Participant in this project, please submit a completed application . Please allow 10 business days for your application to be reviewed. Due to the popularity of this project, we are not able to accept everyone as a Participant. Specification Proposal Form Participants wishing to submit a CCS specification for consideration by the CCS Steering Committee should send an email to the CCS Steering Committee with the following information: Name of and contact information of the organization or individual submitting the specification request Proposed name of the specification A description of the specification Include why this specification is a necessary part of an overall modernization framework for ABL applications Explain what standardization problem it solves Detail if the specification will be based on the implementation of any existing technologies and if so, which ones (include references to those technologies) Indicate if this is an initial version of the specification or a revision of an existing specification List other Participants that support this specification Identify if other Participants are eager to participate in the expert group Detail timeline expected to deliver this specification Include compatibility requirements foreseen for this specification Updates to the Common Component Specification Project Charter The CCS Steering Committee is responsible for maintaining and updating this charter. Proposed changes to this charter by the CCS Steering Committee are passed if the CCS Steering Committee approves the changes to the CCS charter by a passing majority vote of the CCS Steering Committee members. The CCS Steering Committee will decide if the changes apply to specification efforts that are not final or only to new specification efforts. This decision is also determined by a passing majority vote of the CCS Steering Committee members. Changes to the Common Component Specification Project charter will be communicated to all members of the community via the community forum. © 2015 Progress Software Corporation and/or its subsidiaries or affiliates. All rights reserved.
Continue reading...
Continue reading...