Building the social and technical bridges to enable open sharing and re-use of data
RDA EURDA USCONTACT US LOGINREGISTRATION

An Adoption phase for RDA Working Groups?

An Adoption Phase for RDA WGs?

Background

  • WGs have an “end date” after 18 months (and Council do not wish to see this changed)

  • WGs (and some IGs) produce outputs, but adoption of these outputs often only takes off after the WG finishes

  • There is no agreed way to enable the results of adoption to flow back into WG/IG activity

  • OAB have discussed this, and have communicated recommendations to TAB and Council: https://rd-alliance.org/sites/default/files/Recommendations%20from%20subcommittee.docx. These include: [...] the OAB co-chairs should express to Council the OAB’s deep concern that outcomes must be sustained and renewed.  There is currently no formal process for that process given that working groups stand down after 18 months.  The issue must be addressed.

Purpose

To consider whether RDA should make available as an option a formal structure to ensure that there is a group responsible for driving the adoption of a WG’s outputs.

Question: If implemented, should such a structure focus on adoption or improvement or both?

Context

This diagram is a first pass at indicating the high-level flow of a generic WG. The question marks indicate where RDA processes currently don’t provide any space or guidance.

Proposal

RDA offers existing WGs the option of a formal adoption phase after a WG completes. This phase would:

  • be optional

  • could involve a changed membership

  • involve liaisons from Secretariat, TAB and OAB (required? optional?)

  • last for an expected duration agreed by the group in consultation with RDA

  • provide updates at Plenaries

  • be supported and recognised by RDA

Question: Additions/deletions/amendments?

Goals of the group:

  • work with existing adopters to support the adoption process and document any successes, failures, and lessons learnt

  • find new adopters

  • collect feedback from adopters and make sure it is considered for inclusion in the outputs

  • maintain and update the output (as much as possible)

  • work with RDA Secretariat to document and publish adoption stories

Question: Additions/deletions/amendments?

Issues for discussion

Who is responsible for

  • finding adopters after the WG end date?

    • RDA Community, special role for OAB?

  • collecting / receiving feedback from adopters, e.g. updated requirements, or suggestions for improvements?

    • group itself?

  • implementing requirements / suggestions?

    • up to them?

  • managing and promoting improvements that have been made by adopters?

    • Managing - group, RDA central - promoting?

  • documenting and publishing adoption stories on the RDA Web site and elsewhere (e.g. Nature comments section)?

    • RDA comms + group?

  • retiring the output if it has been superseded / replaced by something else?

    • adoption group to decide?

    • From the OAB’s recommendations (see above): The OAB should review adopted impacts on an on-going basis to assess when it is appropriate for the outcome to be updated to avoid a level of divergence in the use of the output that will begin to compromise interoperability.

  • How can RDA best support adoption groups?

    • act as an incubator

    • facilitate conversation with funders

    • provide communication infrastructure, e.g. licenses for project management tools, communication tools, etc

    • facilitate communication with news agencies (Nature comment section, OA journals) - RDA can write about RDA success stories. Just having these stories on the RDA Web page is not enough

Question: Additions/deletions/amendments?

 


  • Log in to post comments
  • 6220 reads
  • Wenbo Chu's picture

    Author: Wenbo Chu

    Date: 26 Nov, 2015

    The adoption phase concept is a great idea in general. RDA builds its success on user organizations‘ success by adopting outputs produced under RDA umbrella. 

    But it must be clear the 18 months term will maintain unchanged. And adoption phase should not be abused to delay identifying users at the WG initiation and working phases.

    Not sure about roles of OAB, TAB and WGs in the adoption phase. Try one or two WGs and see what happens?

  • Ingrid Dillo's picture

    Author: Ingrid Dillo

    Date: 27 Nov, 2015

    I think the adoption phase will in a way be the final proof of the pudding for the WGs. So it is very important to structure and support this phase at least for a period of time through RDA. I would maximise the period though to 18 months max.I hope that the recognition of this phase does not entail any formal and lengthy procedures. futhermore, I think it would be good if every group in this phase gets someone from the OAB especially appointed to them. Preferably this is someone from an organisation that will be an adopter. Maybe there should also be a TAB liaison. Finally I would think that it might be good to also have a communication plan wirtten somewhere along the line, in collaboration with RDA. Now communication elemetns are spread here and there but it might be more effective to really think this through and design a roadmap at the start of the adoption phase.

    Hope these first thoughts are helpful..

     

  • Larry Lannom's picture

    Author: Larry Lannom

    Date: 29 Nov, 2015

    Andrew's note is a good summary of the issues to be addressed.

    My primary comment on the best approach for Outputs adoption and maintenance is that it depends on the output and the group. So, at least at the start, it will have to be flexible.

    If RDA does enable a new kind of group - the Adoption Group (AG to go with WG and IG?) then we need to think carefully about exactly what such a group is expected to do. Monitor? Proselytize? Test and experiment?

    I understand the desire to keep to the 18 month schedule, but for anything ambitious it really isn't enough time for a volunteer group to accomplish a lot. That leads to the 'it depends' comment. If the output is the reflection of a funded project and some subset of the group can spend significant amounts of time on the project, then it is reasonable to expect significant progress in 18 months. But if not, then its tough. At some point in my association with W3C joining a group required a promise to commit at least 25% of your time to the effort. As a result I didn't participate in any groups and we dropped out of W3C shortly thereafter.

    In the case of DTR we knew we weren't finished and so a core group is planning on a new WG tentatively entitiled Data Typing, to work on things like federation and finalizing (or not) on a common data model. I suppose this could be thought of as a sort of adoption group - track the various projects using and/or prototyping the technology and extend the Output to the point where some level of standardization could be contemplated.

    This is an important topic.

    Larry
     

  • Mark Parsons's picture

    Author: Mark Parsons

    Date: 30 Nov, 2015

    In line with some of the comments already made, we need to be very clear that this is not just an extension of the WG, and that the focus is on adoption not continued development. The group should have a defined time limit and it should typically generate new WGs for major updates to Recommendations.

  • Simon Cox's picture

    Author: Simon Cox

    Date: 18 Jan, 2016

    OGC has been dealing with similar issues.

    In that context:

    (a)   There is a clear distinction made between a ‘Standards Working Group’ – which is explicitly responsible for delivery of a document defining some technology – and other kinds of groups

    (b)   OGC has the notion of ‘Change Requests’ – which are proposals for atomic modifications to an existing standard, and may be submitted by anyone, anytime. However, the most relevant ones come from early adopters finding bugs!

    (c)    Recognising that change-requests tend to accumulate over time, the standard lifespan of SWGs has recently been changed. By default, a SWG is now ‘persistent’ and stays in operation in order to process submitted changes

    (d)   OGC has a conformance testing system, which is primarily aimed at providing a way for vendors to demonstrate conformance to a standard. Essentially this provides an executable version of the specification. However, it is far from comprehensive, and takes a lot of resources, and it is not clear if it has a viable future

    (e)   A lot of OGC developments emerge from ‘testbeds’, which run approximately annually, and are live for about 6 months, but only involve a specific set of participants. There are regular suggestions that some kind of persistent testbed is needed to provide a permanent harness for testing, available to all-comers, but it struggles to find a host or funding. 

submit a comment