ACM SIGAda APIWG Procedures

Draft, 13 January 2003

The following DRAFT procedures describe the process for registering both Registered Private APIs and Registered Public APIs.

Please review these Procedures and email your suggestions to ClydeRoby@IDA.Org. Have any steps been omitted? Are any of the steps in the wrong order? Should there be links to other information (e.g., examples of forms -- if so, please email a suggested format for the forms)?

Registered Public APIs

Registered Public APIs are those Ada bindings to APIs that evolve as the particular API evolves. These APIs are usually developed and/or maintained by an interested group of individuals. Anybody can submit a request for the development and/or maintenance of an API to the APIWG Chair to make it publicly available from the APIWG web page as a convenience to the Ada community. The APIWG Chair will then create the necessary infrastructure within SIGAda to initiate the creation of the API's Subgroup.

To "register" a Registered Public API by an individual or group (the API POC), the following steps are followed:
  1. API POC sends a request to the APIWG Chair to add the Registered Public API to the APIWG web page
  2. API POC provides the Name, Company Name, Address, Phone Number, and Email Address of the person to contact concerning any Intellectual Property Rights about that API and its artifacts, especially licenses; API POC provides this information for all interested individuals (or group of individuals)
  3. API POC provides all useful artifacts for the API to be placed on the APISWG's web page(s) for that API; these include, but are not limited to, the following:
  4. APIWG Chair requests approval from POC to place the API on the API Home Page
  5. APIWG Chair requests appropriate license information from POC
  6. APIWG Chair requests that the POC signs any ACM approval/permission forms
  7. APIWG Chair will seek all the necessary permissions from the owner/originator so that the API and appropriate artifacts are publicly available
  8. API POC signs the APIWG License and Permissions forms
  9. APIWG Chair facilitates the approval of the Subgroup by the SIGAda Executive Committee
  10. SIGAda EC establishes an APIWG Subgroup for the Registered Public API
  11. When the APIWG Chair receives the appropriate approvals, then:
  12. APIWG Chair announces to the general Ada community about the availability of this API
  13. API Subgroup is now responsible for:
  14. API Subgroup Chair is responsible for:
  15. APIWG Chair maintains current artifacts for all Registered Public APIs
  16. APIWG ensures the Subgroup is viable and maintains effective API web pages
  17. Members of the Ada community provide feedback to the APIWG Chair and Subgroup Chairs on ways to make the API information provided more valuable and usable to the Ada Community

License(s) to be included with API artifacts

One of the most important artifacts that must be included with the development of any particular API is the license(s) that are included with it. It is very important to the APIWG that the license(s) for the Ada specifications for the API be as non-restrictive as possible; if at all possible, this non-restrictive license should also be placed on all other artifacts of the API. The license(s) for the Ada specifications shall include language such that anybody can implement an Ada body to the Ada specifications.


Registered Private APIs

Each Registered Private API has an individual or organization that is responsible for it. These APIs are usually developed and/or maintained by a third party. Anybody, particularly a developer of any Ada API, can submit their API to the APIWG Chair to make it publicly available from the APIWG web page, with appropriate permissions from the developer, as a convenience to the Ada community.

To "register" Registered Private APIs:
  1. Request APIWG Chair to add the Registered Private API to the APIWG web page
  2. APIWG Chair calls for discussion and vote from APIWG members about newly requested Registered Private API
  3. If APIWG approves newly requested Registered Private API:
  4. If APIWG does not approve newly requested Registered Private API:
  5. When the APIWG Chair receives the appropriate ACM approvals, then either:
  6. APIWG Chair announces to the general Ada community about the availability of this API
  7. APIWG Chair maintains current artifacts for all Registered Private APIs by maintaining appropriate contact with POC for Registered Private APIs; this may include appropriate compressed sets of useful information, e.g., Ada source code specs and bodies (if available) or other information
  8. Members of the Ada community provide feedback to the APIWG Chair on ways to make the API information provided more valuable and usable to the Ada Community

Discussion and Vote for Registered Private APIs

The APIWG Chair calls for a discussion about including the Registered Private API on the APIWG web page. This discussion will take place on the APIWG email list over a period of ## days|weeks. After that period of time, the APIWG Chair will then call for an "email ballot". This email ballot will occur via the APIWG email list and last for ## days. At the conclusion of this vote, the APIWG Chair will contact the API's POC with the results. If the results are negative, appropriate rationale (mostly gathered from the negative votes) will also be given to the API's POC.


Last update 31 December 2002, comments to Clyde Roby (ClydeRoby@ACM.Org)