Although we generally let Workgroups manage themselves, here are some tips that have proven useful in the past.

Guiding principles

  • Transparency – We communicate in the open, and all schedules and minutes are published on the wiki
  • Scenario-driven – Our desire to solve real-world issues with software interopability drives the creation and improvement of our specifications.
  • Minimalistic – We write just enough specification to address our scenarios. We do not create specifications for their own sake.
  • Incremental – We work fast and deliver a specification in a relatively short period of time. Later versions of a specification can expand their focus and address more scenarios.
  • Implemented – We seek to deliver real implementations with our specifications. Our specifications and our software can evolve together.

Creating new workgroups

See creating new workgroups.

Getting started

After the Steering Committee approves the creation of the Workgroup, the Workgroup lead should:

  1. Work with the Webmaster, who will set up a wiki, mailing list, and Workgroup Participation Agreement (WPA) for the new Workgroup.
  2. If you haven’t already done so, register at the OSLC website, complete the Members Agreement, and complete the WPA for the Workgroup.
  3. Create an initial presence on the OSLC wiki that outlines the intended Workgroup scope and objectives, including posting the Workgroup Charter itself. The easiest path here is to copy the wiki home page from an existing workgroup.
  4. Email the main OSLC community mailing list and announce the new Workgroup and solicit new members. See this post for the Architecture Management Workgroup for an example. Include an initial date for a Workgroup kickoff call, with at least 30 days notice for people to learn about OSLC and the new Workgroup.
  5. Email friends and colleagues about the Workgroup and ask them to tell others.
  6. Offer to meet with potentially interested people to get their ideas and encourage participation. Use the talents of active OSLC members to share how things work with prospective participants.
  7. Encourage interested OSLC members to complete the WPA for the Workgroup.

Kickoff meeting

Your first meeting agenda should include:

  • Introductions of members and their motivation for joining in;
  • Discussion of the Workgroup scope and objectives, OSLC guiding principles, and basic operating procedures;
  • Exploration of possible scenarios that might be included, or examples of those that might be out of scope;
  • Existing related industry specifications or standards to consider;
  • OSLC terms for contribution and IP covenants;
  • Frequency and timing for regular Workgroup calls; consistent, bi-weekly calls are usually the norm.
  • Ask for volunteers to capture high-interest scenarios on the wiki. Use these as a future discussion point in recognizing the range of possibilities and in deciding the subset of scenarios that will be the focus of the coming spec iteration.

Have regular meetings

Use regularly scheduled meetings to review proposals, have discussions, and share news.

Choose reasonable times for regular meetings

Poll Workgroup members for their availability. Recognize the geographic location of each participant and try to select a time that is reasonable for everyone. Consider a rotating start time if necessary.

Send out calendar invitations in addition to email

Send out calendar invitations and e-mail rather than relying simply on e-mail. Many people are simply calendar driven! LinkedIn allows you to set up events and create calendar entries that work across a variety of mail and calendar programs.

Use the OSLC website to document as much as possible

Workgroups should strive to do all of their work using the infrastructure provided at the OSLC website. Decisions, discussion, and rationale should be clearly documented on the Workgroup’s wiki.

Publish meeting agendas and minutes

Meeting agendas should be published on the Workgroup mailing list and on the wiki two days in advance of meetings.

Detailed meeting minutes and recommended decisions should be posted the day after. Minutes should include:

  • participants in attendance
  • topics covered
  • important comments and discussions
  • to-dos.

Use the mailing list to propose and document decisions

Decisions should not be made during meetings –use the mailing list to propose a decision and come to a consensus. Every recommended decision should be stated in its own email so that it can have its own thread of discussion.

Set milestones

After the kickoff, set a milestone plan. Although they may be quite high-level at the start, it’s helpful to set goals for completion of a full spec iteration. Four- to six-month cycles are typical. Short cycles help to manage scope and keep things practical. Consider setting milestones for:

  • Completing the authoring and selection of scenarios
  • Proposing an initial specification draft
  • Completion of substantive contributions to the specification
  • The start of specification convergence, final editing, and IP covenant gathering
  • Specification completion
  • Anticipated service provider and consumer implementations

The stages of specification development

Scope
Propose, document, and prioritize the scenarios and technical objectives that you will address in this version of the specification.
Draft
Contribute to and comment on the proposed specification through a series of drafts.
Converge
Allow the broader community to review and comment on the draft specification. Meanwhile, start building implementations and prototypes.
Finalize
Polish the specification to correct errors or clarify language. Submit the specification to the Steering Committee for review.
Final
The Steering Committee approves the final form of this version of the specification. A final specification must have a working implementation and a test suite.

Submitting a specification for Finalization

For a specification to be finalized, the Workgroup should provide the following to the Steering Committee:

  1. Proposed Specification for finalization;
  2. Two or more implementation reports;
  3. Endorse a test suite that tests at least the MUST clauses of the proposed Specification. Preferably the test suite should come from Eclipse Lyo;
  4. Documentation explaining the linkage of the specification to the scenarios that drove the specification development.

For the Steering Committee to consider a Specification, Workgroups must present items 1–3 listed above; the documentation (item 4) can be completed at a later date.

← Creating new workgroups Privacy policy →