Creating or Joining an RDA Working Group

You are here

22 March 2016 30654 reads

Introduction

RDA Working Groups (WGs) should tangibly accelerate progress in concrete ways for specific communities with the overarching goal of increasing data-driven innovation. Efforts are intended to promote data sharing and exchange, interoperability, data use and re-use, data discoverability and analysis, data stewardship and preservation, and best practice for substantive communities.

Although specific outcomes will vary, all WGs need to develop a Recommendation and should strive for “focused effort and tangible progress.”

  • “Harvestable” efforts for which roughly 12-18 months of work can eliminate a roadblock for a substantial community focused on innovation.
  • Efforts that have substantive applicability to particular segments of the data community, but may not apply to everyone.
  • Efforts where working scientists and researchers can start today to get something done now, while more long-term or far-reaching solutions are being appropriately discussed through other vehicles.

In addition to the shorter-term, outcome-oriented focus of the RDA Working Groups described herein, critical longer-term R&D efforts, supported by Government sponsors, the Private Sector, and others, must continue to promote innovation and discovery. The RDA Working Group process is meant to complement those efforts in the short-term.

Joining a Working Group

You can find a list of the current RDA Working Groups here. Any member of the RDA can join a Working Group by navigating to the group's page and selecting "Join group" in the box on the right-hand side of the group's page. 

Creating a Working Group

Working Groups (WGs) require more commitment than Interest Groups. Working Groups develop Case Statements that describe the Recommendation that the group will produce. Other key parts of the Case Statement include a value proposition, work plan and adoption plan. Case Statements are then reviewed by the RDA Community, Technical Advisory Board (TAB), from a technical perspective, and Council, from a strategic perspective. Review criteria include: 

  • Fit with the overall RDA vision and mission
  • International membership spanning, ideally, three or more continents
  • 2-4 co-chairs leading the initiative
  • Measurable outcomes
  • Outcomes will foster data sharing and/or exchange, and be taken up by the intended community
  • Proposed work, outcomes /deliverables, and Action Plan described in the Case Statement can be accomplished in 12-18 months
  • Appropriate scope of the WG
  • The effort adds value over and above what is currently being done within the community.

You can find more information on the required components and review criteria relevant to a Case Statement on the Case Statement page.

Candidate WGs should contact enquiries [at] rd-alliance.org about their intent to develop an RDA Working Group Case Statement. A Secretariat liaison will then help the group throughout the life of the WG.

The process for setting up an RDA Working Group is as follows (see also Figure 1):

  1. The WG develops their Case Statement describing the Working Group’s beneficiaries, goals, outcomes, and operational approach. The WG chair(s) creates a new Case Statement, if there is already an RDA Organic Group for the group, or creates a new Working Group via the “Initiate new group” tab in the “Creating and Managing RDA Groups” menu (you must be logged in to do this, and the Secretariat moderates the creation of new groups), adds the Case Statement to this group and notifies the Secretariat at enquiries[at]rd-alliance.org. (The Secretariat is happy to help with this step, please email enquiries[at]rd-alliance.org if you would like assistance). 
  2. The Secretariat publishes the Case Statement in the RfC box on the RDA Homepage and notifies the TAB, Council, and the broader community that the document has been posted and is now ready for community review. The community will be given at least four weeks to review and comment on the document. If there have been significant comments during the community review, the WG is expected to post a revised Case Statement, based on these comments.
  3. In parallel to the Community Review phase, TAB starts to review the Case Statement. This is expected to take 4-6 weeks. TAB will come to one of the three following conclusions: After TAB has accepted the Case Statement, TAB will designate a TAB member as liaison to the group. 
    • The Case Statement is sufficient. TAB has accepted the Case Statement, and it will be forwarded on to Council for the final step of the review process.
    • The Case Statement requires revision. TAB will communicate the required changes to the group chairs. Once these changes have been made, the Case Statement will be deemed sufficient by TAB.
    • The Case Statement is rejected. TAB will communicate the reasons for this decision to the group chairs.
  4. After TAB has accepted the Case Statement, Council will review it. This is expected to take about 2 weeks. Council will make one of four possible decisions about the Case Statement:
    • Recognized and endorsed as is: Strong Case Statement. Group is recognized as RDA WG and should commence its work.
    • Recognized and endorsed subject to specific revisions: Worthwhile idea, changes need to be made to strengthen the Case Statement and meet approval criteria. After the approach has been modified, the group will be recognized by RDA and commence its work.
    • Encouraged but not presently endorsed: Good idea but needs refinement. The group needs to mature its concept and refine its Case Statement for approval. Council and/or TAB will provide specific feedback and clarification on what is needed.
    • Not endorsed: The idea is not a good fit for the RDA or does not meet other criteria for approval. Council will provide specific feedback and clarification. Council may feel that the group may be more appropriate as discussion-oriented Interest Groups, from which specific outcome-oriented Working Group ideas and Case Statement submissions may arise later 
  5. If Council perceives reasonable community consistence and clear needs, deliverables, and beneficiaries, they formally recognize the group.

 

WG review process diagram

Figure 1: WG Case Statement Review Process - from Case Statement Developmet to Endorsement

 

Working Group Outputs

Working Groups should deliver their Recommendation after 12-18 months, and can also develop other outputs along the way. For more information on what  WG Outputs look like, please refer to the Working Group Outputs page.

The outputs of recognized Working Groups, especially their Recommendations, are strongly promoted by Council, the OAB, the TAB, the Secretariat, and the RDA Membership at large. We work hard to encourage research agencies, industry, and academia to adopt the products of RDA Working Groups.

 

Closing out a Working Group

After a Working group has delivered its Recommendation, and incorporated any changes coming out of the community review phase, the group will need to choose one of the following options: 

a) The Working Group finishes and disbands, and is now listed under "Historical Groups". The group is expected prior to disbanding to ensure its Recommendation(s) will be dealt with as per its maintenance plan. This might involve passing responsibility to a specific organisation or another WG/IG.

b) The Working Group becomes a Maintenance Group.   The Working Group begins the maintenance phase, with the purpose of:

  • Managing a community focusing on maintenance activities and supporting the adopters of the original Recommendation. Disseminating, making minor revisions to, and updating adopter details and stories of, endorsed Recommendations and Outputs that were produced before the WG's transition to the maintenance phase.

  • Transferring work towards further outputs and proposed new activities to other WGs, IGs, or BoF sessions.

If a WG decides to transition to a maintenance phase, there is no review; the WG informs the RDA Secretariat that it wishes to begin the Maintenance phase and provides details on the following aspects:

  • Rationale for maintenance phase and expected duration

  • Co-chairs & group members intending to support the maintenance phase

  • On-going adoption activities

  • Maintenance plans including publications, facilities, updates and new versions, pilots and demonstrators

An RDA Working Group or Interest Group will be closed and considered inactive (Historical) when:

  • The group has completed their expected outputs (WG) or discussions (IG) and do not plan to continue this activity within the context of RDA. 

  • The group becomes unresponsive to the TAB Liaison’s and Secretariat's request for response for a period of more than 6 months. 

    • The TAB Liaison or Secretariat should make at least three attempts at least one month apart to contact all WG/IG chairs during this period. 

Maintenance Phase Policy

  • TAB and the Organisational Assembly are invited to comment and give feedback on the maintenance phase request from the Working Group.

  • Priority for plenary sessions is given to active IGs and WGs. It is not expected that Working Groups in the maintenance phase would run sessions, since new areas of work should be covered in new groups

  • WGs in the maintenance phase are contacted to ensure continued activity by TAB on an 18-month basis. If the group becomes unresponsive to TAB’s request for response, TAB will recommend that the group should be closed (become a Historical Group) as defined in the above section of this document. 

  • WGs that enter the maintenance phase will be invited by the Secretariat to provide a short summary of the activities in the past 18 months and plans for the upcoming 18 months. If the Co-Chairs become unresponsive to Secretariat’s request, Secretariat will recommend that the group should be closed and considered inactive (Historical) as defined in the section above.

  • Based on the activities in the WG, TAB will make one of the following recommendations to Council:

    • Continuation of the maintenance phase for a further 18 months or a specific period to be justified;

    • Closure of the maintenance phase as a result of:

      • Maintenance phase completed and transition to historical group requested.

      • Not adhering to maintenance phase policy, e.g. new outputs generated, new scope of development foreseen or started, etc.

      • Inactivity or no updates as described above.

c) The Working Group starts a new WG to produce a new version or significant update of the recommendation, or to tackle additional work to e.g. cover more use cases. In this case, there is a light-weight review consisting of  a community review, the OAB is invited to comment, and finally there are quick yes/no decisions by TAB and Council.

d) The Working Group starts a new IG to serve as a platform for communication and coordination around the WG's topic. In this case, the review also consists of a community review, the OAB is invited to comment, and finally there are quick yes/no decisions by TAB and Council.

Withdrawing a Working Group

If you, as co-chair of a WG, and your fellow co-chairs want to withdraw the WG prior to delivering the WG's Final Recommendation, please email the RDA Secretariat at enquiries[at]rd-alliance[dot]org and state the reasons for wanting the group to be closed.  The Secretariat will then contact you about the next steps.

 

For more information, please refer to: