Wish List - Wish List: Wish #175

<Member picture

0 Dislike

Alissa Nedossekina

Tool version release notes management

This wish stems from http://nanohub.org/wishlist/general/1/wish/109

Requirements as per Gerhard:

Handling of version annotations, or release notes for EVERY new version of code. It should be part of the contribtool process where the developers are being asked to enter some ptoper english text about the new release.

Look for example at the very cluttered description that is now in tools/rtdnegf

All these version notes should go with the “versions” tab.

Also each of the releases a developer should see the list of open tickets, questions, or wishes that may be “clicked-on / chosen” indicating that the new release of the code closes these items or addresses these items.

That should create a link on the versions tab to the question or the wishlist or a ticket number. It should also close these tickets, questions, and grant the wishes.

Comments (2)

  1. Gerhard Klimeck

    goes along with validation and telling the users what is changing. I get this as a question all the time when I give a nanoHUB talk.

    Reply Report abuse

    Please login to comment.

  2. George B. Adams III

    A key point is that, with nanoHUB, simulation tools are not released, instead they are published.

    Almost all of the simulation tools on nanoHUB represent codes that would not be available, traditionally, because the authors would not have made them available due to competitive issues and/or lack of incentive. We want the developers to think of themselves as authors and be motivated as they are when they are authors. We want them to receive significant benefits for publishing their tool, as they do by publishing journal papers. We want them to expect to shoulder similar responsibilities as they do when publishing.

    So: 1) The terminology on the pages when versions are created should use the word publication in preference to release. 2) All author information fields from the current version should be presented and confirmation of each field received before re-using it and change of any field allowed. 3) Any co-authorship change from version to version should be explained and require a major version number change. 4) If there is no co-authorship change, then all usage data and ranking should probably inherit to the new version. 5) Reviews need to be labeled by the version for which they were given. All reviews should appear in the Reviews tab, but they should be labeled by the version.

    Reply Report abuse

    Please login to comment.