Moving Standard to Maintenance Mode - Documentation

[RegganThomas]

This issue outlines the criteria for moving a standard into maintenance mode, defining responsibilities, establishing review schedules, and documenting any changes or updates that are made during the maintenance phase.

https://docs.google.com/document/d/1AdK2_vSNdXf280TgDdGhXsVsjhXvOD0sQSzQgWxH2IY/edit

We're putting together a draft proposal from WSMs to describe the problem space and some workflows to facilitate discussions within TASC

[ohofmann]

@RegganThomas Is there any existing documentation, or even just the meeting minutes from the workshop around retiring standards (or putting them into maintenance mode) that could be used to populate the draft document?

[RegganThomas]

@ohofmann Please find the meeting transcript and the presentation from the April Connect meeting (2024) attached - https://docs.google.com/presentation/d/1EwQmjpO5XmXGXoCivFbxapkAuFAXSuFM/edit#slide=id.g2cd7607c460_0_32 Meeting transcript - https://otter.ai/u/TNKd24FxmK__Vud9eoMUxNXRSSQ?utm_source=copy_url TASC April Connect meeting agenda - https://docs.google.com/document/d/1YisI8J_6GDHqxnkjkLAnZzmLdU6tQqDJ/edit Link to Miro: https://miro.com/app/board/uXjVKQx5bKM=/?share_link_id=519570302129

[jkbonfield]

Thanks to Andy for chairing a great Connect topic on this. I had some thoughts which I put in chat, but are perhaps better tracked here.

• Maintenance can be ambiguous, but perhaps it's right for something which is post-development. I have issues though with labelling everything post-1.0 as maintenance. A product may well have a roadmap with initially 1.0, then 1.1 is this set of new features , 1.2 is that, etc. Post-1.0 is still in active development. While formally we could say 1.0 is under maintenance and 1.1 is in development, this isn't normally how people see software products where there is a single product and you don't get a choice of which version you buy - it's always the latest. While with specs and protocols, yes you do get that choice sometimes (eg plenty use HTTP/1.1 while HTTP/2.0 exists), using this term can lead to misunderstandings.

• We need a separate term for things that are essentially on life-support, although maybe not one with such negative connotations. Perhaps preservation mode? I'm unsure, but there are plenty of choices in the thesaurus to try out. It's not necessarily a downwards spiral either, so we need a term which implies it can go into that status and back out of it again. Eg "paused" or "maintenance hiatus".

• Deprecation is a very overloaded word and means different things to different people. For some it's "we're going to kill this off". For others it's "this isn't our favoured solution - use something else instead". However all of them are somewhat negative and imply obsolescence. If a product has fundamental flaws, such as baked in security issues, then yes I agree it makes sense. Likewise if there is a newer product which is now our favoured solution, then deprecated can make sense (but I prefer "obsolete"). However to deprecate something purely because of a lack of maintainers is a both a failure of communication and also missing an opportunity. I would never volunteer to take up a position on a deprecated product. Why would anyone? It's something clearly that very few would care about and the audience is going to be shrinking all the time. However if we're just open and state "Position vacant: maintainer needed" (or "product manager") then it advertises itself as an opportunity to step up and make a difference, with the knowledge that your input is highly likely to be appreciated. I also fear what the external view of GA4GH would be from industry considering taking up our standards if they see things listed as deprecated purely due to a lack of apparent interest. At best it'll encourage people to just take the work on build upon it themselves inhouse given GA4GH is no longer interested in maintaining it. At worst it may discourage people from using other GA4GH products as it implies we don't consider longevity. This is clearly wrong, which is why I think it would be a huge home goal to label a product as deprecated unless it really is dead and should never be used again.

In short, words matter, especially when it's a single word or short phrase used as a status to describe a product.

[ohofmann]

I liked the Connect session as well; @andrewyatz - can you link to the product owner (?) proposal in this discussion?

Agree on the maintenance label; I would probably not make a distinction between versions and either have the whole standard under active development, or in maintenance (which to me indicates just bug fixes and minor issues) and finally a 'frozen' status due to lack of maintainers, resources or general support.

Deprecated really should only be used if a standard has been superseded by a newer version, or we are shifting to a different approach entirely and do not recommend the use of this standard anymore. Even in frozen form many of the current GA4GH standards are still useful and should be applied (particularly if the alternative is doing nothing, using free text, etc.).

[RegganThomas]

@ohofmann - Link to the product owner proposal - https://docs.google.com/document/d/1a0O3mFceDBzupaceF9DtAzjRbu4FQtJXN8nmPCk1S-Y/edit#heading=h.mc11oyljuolv