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.

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:
   • compilable Ada source code (Ada specs and bodies)
   • test code and/or validation code
   • rationale
   • examples
   • tutorials
   • useful tips
   • known problems
   • lessons learned
   • appropriate licenses and/or permissions
   • other documentation
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:
    • APIWG Chair creates a new web page for the API on SIGAda's server
    • After permission is granted, APIWG Chair places the source code for the API and all available artifacts on the API's web page
    • APIWG Chair creates a link from the APIWG web page to API's web page; the API's web page can now be used to document the API and provide artifacts
    • APIWG Chair creates a new mailing list for the API's Subgroup (effectively creating the subgroup); the mailing list is used to:
      • Conduct the business of the API's Subgroup
      • Coordinate the Subgroup's agreed-upon voting process, including the number of qualified voters that constitute a quorum
      • Notify interested parties of major API events
      • Archive, on the ACM server, the exchange of email messages to maintain a record of the Subgroup agreed-upon voting process and provide a historical context to new members of the Subgroup
12. APIWG Chair announces to the general Ada community about the availability of this API
13. API Subgroup is now responsible for:
    • Development and Maintenance of the API as it evolves
    • Providing additional useful data and/or artifacts to post to the API's web pages
    • Evolving the API with the Subgroup's agreed-upon voting process, including the number of qualified voters that constitute a quorum
      • Baselining the API
      • Versioning new releases
      • Notifying general Ada community about lastest version of API
        • web
        • quarterly Ada Letters publication
        • API mail list
        • monthly announcement on the SIGAda-Announce mail list to the SIGAda Membership
        • announcements to other mail lists, e.g., Ada-Europe, Team-Ada, WG9, etc.
      • Posting to the web about the latest version of the API
    • Developing the appropriate license(s) to be used for the availability of the artifacts for this API, most notably licenses for sources
14. API Subgroup Chair is responsible for:
    • Defining the voting process for their Subgroup, including the number of qualified voters that constitute a quorum
    • Developing, Maintaining, and Evolving the Ada Binding to their API using the Subgroup's agreed-upon approach, particularly if there are two or more candidate APIs being considered
    • Maintaining their API and its artifacts on their API's web page, including Subgroup-approved baselines and versions for their API
    • Recommending replacements when they are no longer able to perform their duties as Subgroup Chair
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

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.

1. Request APIWG Chair to add the Registered Private API to the APIWG web page
   • Provide either of the following to the APIWG Chair:
     • Source code of the API, both Ada specifications and bodies
     • Link to developer/submitter website for the API
   • Provide other useful artifacts, not limited to the following:
     • compilable Ada source code (Ada specs and bodies)
     • test code and/or validation code
     • compressed files of useful sets of information
     • rationale
     • examples
     • tutorials
     • useful tips
     • known problems
     • lessons learned
     • appropriate licenses and/or permissions
     • other documentation
   • Provide Name, Company Name, Address, Phone Number, Email Address of person (POC) to contact concerning any Intellectual Property Rights
   • Provide rationale why API should be a Registered Private API
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:
   • APIWG Chair requests approval from POC to place the API on the API Home Page (usually for an API with third party Intellectual Property Rights)
   • APIWG Chair requests appropriate license information from POC
   • APIWG Chair requests that the POC signs any ACM approval/permission forms
4. If APIWG does not approve newly requested Registered Private API:
   • APIWG Chair contacts POC giving reasons why API not approved by APIWG
5. When the APIWG Chair receives the appropriate ACM approvals, then either:
   • APIWG Chair creates a link from the APIWG web page to API's web page
     OR
   • APIWG Chair creates a new web page for the API on SIGAda's server
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

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.