MINUTES, REVIEW USERS GROUP
(The RUG; our motto: "Don't tread on us")-from Dr Sinnett, but I think it's pretty cool--ewb
2/26/01

Dr. Bradley brought the meeting to order shortly after 1:00. Members of the Users Group introduced themselves. The group includes both SRAs and GTAs, with at least one member from each IC [confirm] and also includes Sherry Zucker from OER, Anthony Coelho from RPC, and programmers from ROW/Logicon.

By way of introduction, Dr. Bradley explained her role as the Review Advocate. She works with the eRA Management Team and reports to the RPC on the needs and proposed actions of the Users Group.

The Users Group itself was preceded by the Review Joint Application Design Team or JAD. As Sherry Zucker from OER explained a little later in the meeting, the JAD was composed of eight members from CSR and several other ICs, as well as the programmers, and was purposefully small so as to expedite reaching a consensus on issues and moving forward with the design process. Dr. Bradley and Ms. Zucker explained that the task of designing the basic module had been largely completed by the JAD, so it was now time to migrate to the Users Group format to better integrate input from all the ICs. To provide continuity, all of the members of the former JAD are members of the Users Group.

Dr. Bradley expects that the Users Group will meet at least monthly, with another meeting on the books for March 26. Note that an additional meeting was scheduled later in the meeting for March 5.

Dr. Bradley expects that, in addition to regular meetings of the entire ug, there will also be focus groups which will be formed as the needs arise. In that regard, Dr. Panniers is already working with some IC representatives on the issue of percentiling. Parties interested in helping with this endeavor are encouraged to contact him.

Since IMPAC II is, in essence, a single database, and since the needs of the review community impact on (and are impacted by) developments in other modules, some of the Users Group members will serve as liaison to other groups. In particular, Tracey David and Everett Sinnett will also be serving on the CM JAD, which will soon be working on the redesign of that module, while Bonnie Ellis is liaison for Reports and Queries Also, Kay Valeda from the NHLBI brings knowledge of the CM module to the Peer Review user group.

Dr. Bradley explained that the function of the Users Group will be for members of the Users Group to bring issues and suggestions for enhancements to the group for discussion and, in return, take issues and knowledge back to their fellow users. Dr. Bradley encouraged members not to be timid about asking questions on functions about which they are confused or which may be unfamiliar, since the Users Group members are expected to serve as resources to their colleagues in the ICs. Users Group members are also expected to gather input from their colleagues on potential enhancements to the module and to bring those items to the Users Group. However, the Users Group meetings are NOT to be used to report bugs. That should be done through the IMPAC II Helpdesk - (301) 402-7469

A question was raised regarding what will happen to a new suggestion. The answer was that the Users Group will need to assign a priority to the new suggestion. It will then be added to the list of enhancements and will be considered, largely based on its priority in relation to the other items on the list, for future implementation. One exception to working in priority order would be cases when a cluster of enhancements are related to a single screen or function; in that case, the programmers would be able to efficiently handle the entire cluster, even if some of the suggestions had a lower priority. One of the first orders of business for the Users Group will be to evaluate the list of enhancements already identified and confirm that list or consider rearrangements to it.

There was some discussion of the Release Notes, which are posted on the web at with each new release of the software. The intent of the notes is to let users know what bugs have been fixed and which enhancements have been enabled. However, feedback from Users Group members was that many of the end users don't seem to want to be bothered with checking these notes. One reason for that resistance is that many on the Users Group find the notes to be overly cryptic and not that helpful. Sometimes, you would need to know the history of a problem in order to be able to understand the notes. One suggestion was that Users Group members take on the responsibility of reviewing these notes as they are released so that they may, in turn, explain the notes to their colleagues, either serving as a resource as questions arise or proactively distributing the notes or some synthesis thereof. A subsequent suggestion was that "Release Notes for Dummies" be prepared for distribution at Users Group meetings.

Andy Greenleaf of Logicon, who has been involved in the programming and oversight for the module from its inception, then gave the group a walk through of the major screens. Most of the functions have been in place for some time now, so these minutes will only reflect some of the more recent enhancements as well as significant questions raised during the demonstration. One recent enhancement is that the Select SRG screen will now allow IC users to select on Work Groups.

Greenleaf pointed out that program staff in the ICs have access to the "Review Order" screen. Apparently, this order is presented as being a "tentative" order in which the applications might be discussed at the meeting. However, it was pointed out that many SRAs only use that screen to order vote sheets and assignment reports (often alphabetically) while the actual order in which applications are discussed is determined by the need to group similar mechanisms, applications from one IC vs another, to accommodate one day reviewers or phone reviewers, etc. As an editorial note, this situation emphasizes the need for SRAs to be in communication with their IC program reps with regard to the actual review order. Perhaps also, the display available to the IC program reps might include the notation that contact with the SRA to determine the actual order in which applications will be discussed is recommended.

During the presentation, Greenleaf mentioned that the Assignment screen is scheduled for an overhaul to improve and simplify its function. In this regard, there was mention of the automatic conflict checking function. Users need to be aware that the system was designed to check for potential conflicts for the SRA to check. As such, the system checks the "employment" data in the Person module. In cases where a reviewer has left one institution for another but no one has entered an "End date" for the previous employment, the system will consider that employment to still be active. Since joint appointments are a very real possibility, this should not be considered a bug. While it was shown that users can update this information while using the Assignment screen by navigating through three or four screens, the suggestion was made that this process be simplified.

Enhancement suggestion - Simplify conflict checking so that users can easily delete/end a previous employment record in the Person database more easily from the Assignment screen.

Scarlett Gibb pointed out, with regard to scoring options, that users should NOT use the scoring option of DF in the score entry screens, since this creates some problems when bridging to IMPAC I. Rather, the Reassignments Screen should be used to move the application out of the affected meeting before releasing scores. A paper 901 should then be used to move the application to the proper meeting and council. Greenleaf pointed out that IC users have the option of moving an application from one council to another.

There was a brief discussion of split votes. Since these are no longer used, they have note been programmed into the module.

Daniel Fox, who is currently in charge of the Review Development team, gave a brief demonstration of the upcoming summary statement functionality. This system is currently being tested by former JAD members. The current design calls for files to be labeled with the application number. Users Group members re-emphasized the desirability of including the PI last name as part of the file name, and the programmers agreed that this is one of the items on their to do list. Anthony Coelho reported that the RPC has recommended that the "standard" font for summaries should be Arial 10 point. While some on the Users Group questioned the need for such uniformity, the consensus seemed to be that it would be important for Council books to have the same font throughout. Coelho also reported that a subcommittee of RPC is working on standardizing the subheadings that will be used for the various portions of the text of the summary statement. Such standardization will allow the system to flag these sections for independent retrieval; it could also allow for an index function which would allow users to jump directly to a given section. Greenleaf reported that documents prepared in WordPerfect may suffer from some conversion problems, but so far, the problems identified have not been of the sort which would interfere with normal summary statement production. In response to a question, it was stated that mathematical symbols should appear in the final summary statement just as they were input in the original document. Toward the end of the meeting, there was discussion of the loss of "special characters" when converting to Arial font. Two points were made on this issue. First, the IMPAC I system requires that these symbols (such as Greek characters) be converted to English spellings, so users need only continue their current practices for now. Second, the programmers indicated that they will look into how to preserve those special characters during the conversion process. At the end of the meeting, it was decided that there will be an additional meeting next Monday, March 5 at which time a full demonstration of the summary statement functionality will be provided. Also, efforts will be made to include all Users Group members as pilot testers of the function should they so wish.

Greenleaf, in continuing the demonstration, pointed out the Purge assignment data button which, he suspects, has been underutilized. This function should be carried out at some point after each meeting to protect that data from being accessible under a Privacy Act request. When IMPAC I is no longer needed, users will need to use the "Release Meeting" function in IMPAC II; when that happens, the system will be designed to automatically purge the assignment data at the time the meeting is released. As an editorial note, the JAD members had requested that users be warned of that ancillary action when releasing so that required conflict reports, etc can be run off before that information is erased.

Subproject functionality will be discussed at a future meeting.

Greenleaf concluded by noting that users have undoubtedly discovered many useful "tricks" to help them do their jobs. He encouraged the Users Group to be a forum where such knowledge can be shared. Dr. Bradley latter suggested that Users Group members should be encouraged to share tips learned form this and other meetings with their colleagues.

Next, the existing list of enhancements was passed around to the Users Group. It was noted that many of the descriptions are somewhat cryptic, so Greenleaf agreed that he will e-mail a PDF file which contains more detailed information on each item. Dr. Bradley noted that ACTION ITEMS for the Users Group will be to (1) evaluate and confirm (or change) those existing priorities and (2) consider additional enhancements.

The meeting was adjourned at approximately 3:30

A special thanks to Dr. Ev Sinnett for preparation of the minutes

Attachments

No attachments.