Draft OGF Structure¶

OGF Structure as defined in GFD.2¶

• working groups (produce documents)
  • chartered w/ milestones, somewhat defined lifetime
  • chairs (2/3)
  • secretary (opt)
  • members (whoever is on mailing list)

• research groups (may produce documents)
  • chairs / secretary / members
  • vaguagly chartered
  • indefinite lifetime
  • may spawn WG

• community groups
  • chairs / secretary / members
  • indefinite lifetime
  • represent community input to drive WGs/RGs

• area
  • collection of WGs and RGs by topic
  • structure of areas are up to GFSG
  • area directors are (usually) assigned to areas, overseeing 1 or 2 groups each

Proposed Amendments¶

• areas are static, not a good match for group topics, very different sizes/activities
  • no static areas, but tags to groups
    • DRMAA: API, Compute
    • OCCI: Cloud, Compute
    • GLUE: Infrastructure, Compute, Data, Networking
  • assign ADs to explicit set of groups, according to their specialization / experience

• feedback between CG and RG/WG not functional, no active CGs left
  • focus CGs around short living efforts (plug feasts, workshops, implementations, OGF events, ...)
  • very low overhead of forming and disbanding(!) CGs

• RG/WG structure seems to work ok
  • weed out dead groups

Proposed Amendments -- Verbose¶

The OGF structure has shown to be both suitable and appropriate for OGFs functioning, and seems to function reasonably well. In particular, the hierarchy [members / chairs / AD / GFSG / VP] has shown to be very functional. Also, the existence of topical areas has given the OGF a useful structure many members identify with.

There is, nevertheless, an observed mismatch on what groups are managed by what ADs: the number of groups managed by any specific ADs varies widely, and load-balancing is formally not trivial, due to the static area structure. That also makes it difficult to replace ADs, as very specific expertise is needed for the new candidates. Finally, groups can often not clearly be bucketed into one specific area.

We propose to make the AD-to-WG assignments more flexible, and in particular to assign groups on a case-by-case basis, based on the expertise of the ADs in question. That change would mostly mostly formalize the currently practiced mechanism. For organizational reasons the notion of topical areas should be preserved though.

Over the last years, we have observed that community groups and research groups did rarely function as intended. Research groups were supposed to spawn working groups based on early, exploratory work; community groups were supposed to inform working groups about standardization needs and uptakes, etc. While there were at least some RGs which functioned as intended, RGs often covered both exploration and standardization. CG were often very short-lived, as continuous participation of OGF customers in OGF events seems not sustainable for them. The feedback of standardization needs via CGs has been lacking as well.

We thus propose a re-interpretation of CGs, as short living, targeted efforts which center around specific activities, such as OGF events, workshops series, plug feasts, standards implementations etc. It should be trivial to create a CG, and to terminate it once its mission is accomplished -- their main purpose is to provide structural, process and tooling support to these efforts.

Related, we propose to rigorously weed out dead groups in a timely manner.