Describe 30/60/90 day activities for a specification committee

[waynebeaton]

I'll start with relatively coarse-grained bullets. This is my first cut and it will be modified based on feedback.

In the first 30 days...

• Establish committee membership as defined by the working group's charter, for example:
  • Appoint Strategic Member representatives
  • Appoint PMC representative
  • Call for nominees and initiate elections for elected positions
• Inaugural meeting
  • EMO presentation on "how to operate a specification committee"
• Identify chairperson and secretary
• Establish initial policies regarding standing items, dissemination of minutes, use of public/private channels, etc.
• Set up mailing lists and other committee resources (e.g., GitLab repository)

In the next 30 days...

• Establish meeting cadence
• Ballots to create one or more Specification Projects

In the next 30 days (although likely somewhat longer term)...

• Ballots to approve Release Reviews for one or more Specification Projects
  • Ratify Specification Version into a Final Specification

Thereafter...

• Ballots to approve Plan Reviews for subsequent releases
• Ballots to approve Release Reviews
• Ballots to approve Progress Reviews as required
• Ballots to approve Creation Reviews for new Specification Projects

I've avoided talking about specialising the process. By default, working groups adopt the EFSP unmodified and the implementation patent license. In the event that a working group chooses to override these defaults, they can do so a pretty much any point. We could, perhaps, indicate that the first thirty days are a good time to determine that specialisation of the process or that the default need to be overridden and initiate that work. My preference is to not include that discussion in this context.

We also need to make sure that we're adequately capturing "how"; for example:

• how the nomination and election process work for elected positions
• how we identify the chairperson and secretary
• how we run ballots (we already have this captured in the operations guide)
• when a super majority ballot required vs. simple majority vs. single-transferable-vote

In some cases, we have specific rules and in some cases we have best practices.

It falls within the purview of the specification committee to determine how the specifications being developed under their governance hang together (e.g., identify those specifications that are profiles), common themes for coordinated releases, etc. The specification committee may choose to delegate these sorts of activities to another group (e.g., the Jakarta EE Specification Committee delegates this responsibility to the Jakarta EE Platform project leads).

Should we include hooks into branding programmes?

We should probably note that elected positions are periodically renewed as defined by the working group charter (typically this requires an annual call for nominees and initiation of elections for elected positions).

[speedrun2006]

Wayne, In my opinion it may be wise to add some hook to branding programs as some of the specs will target specific characteristics that should be aligned with the branding process.

[waynebeaton]

There are other activities that the specification committee may choose to engage in:

• Identify and designate one or more specifications as profiles (as defined in the EFSP);
• Define the format of specification documents (both file format and document structure);
• Define the nature of TCKs;
• Determine how (in conjunction with the marketing committee) specifications are disseminated (e.g., how they are presented on the website);
• Set themes for releases; and
• Manage other cross-cutting issues (that is, how specifications relate to each other).

The specification committee may choose to defining processes over and above the EFSP:

• How, specifically, specification project teams interact with the specification committee;
• Define the information (and how it is collected/tracked) needs to be in place before a specification project can start the release process; and
• Potentially extend default ballot periods (e.g., require more than one week for release review ballots).

We should emphasize that a steering committee does not operate in a vacuum. Our expectation is that the specification committee has knowledge of the contents of specifications and has been given an opportunity to provide feedback before they are called upon to engage in a ballot to approve anything. The formality of this engagement is determined by the specification committee (by way of example, the Jakarta EE specification committee assigns a committee member as a mentor for every specification; that mentor observes and works with the project team to ensure that they're meeting the expectations).

[waynebeaton]

Wayne, In my opinion it may be wise to add some hook to branding programs as some of the specs will target specific characteristics that should be aligned with the branding process.

The notions of profiles and platforms were added to the EFSP to support the notion of designating specific specifications as being subject to the working group's branding programme. That is, while the working group may support a large number of specifications of varying granularity, it is only those that are designated a profiles that are considered by the branding programme.

That is, when an implementer does takes all of the necessary steps to claim compatibility with a profile (or platform) they can leverage the associated brand (generally this means that they can associate the compatibility logo with their brand, get listed as a compatible implementation, etc.)

In this context, designating profiles (and platforms) is an important part of the branding programme and the specification committee is expected to work with others in the working group (e.g., the marketing team) to "right-size" the profiles and otherwise determine the nature of the branding programme.

Note that a branding programme can be built around profiles or specifications. A working group may opt to engage in a branding programme that supports whatever specifications they choose.

Note that the EFSP attaches no specific meaning to the term profile than that a profile references other specifications (that is, a profile is an aggregation of specifications). The EFSP attaches no meaning to the term platform; that is left to the discretion of the specification committee.

There is discussion regarding specifications and profiles in the EFSP. There is some very limited discussion in the operations guide.