EGI user support requirements publicity
In the beginning when the requirements tracking (RT) system was setup it was not publicly accessible, it required to have an EGI SSO (Single Sing-On) in order to submit new requests or to see the existing user support requirements. That led to many discussions inside of the user communities about difficulties to track their requirements and to show them to the others. After some discussions at EGI.eu and it-support the decision was to provide anonymous public access to the requirements tracking system, but that still was not enough for the user communities having public access and specific RT dashboards .
At that time some of technical services provided by the EGI, started to develop so called “gadgets” and UCST decided to provide such service for requirements tracker as well. There is already a blog post written about the Training marketplace and Requirements tracker gadgets - New gadgets for the EGI Training Marketplace and the Requirement Tracker. Some of the user communities already successfully adopted RT gadgets for their websites e.g. LSGC VRC or WeNMR VRC. But RT gadgets, despite of the fact that they can be highly customized, they still provide only listing for open or solved requirements and most of the important details user communities must find inside of the each ticket.
As time was passing, User Community Board (UCB), where all user communities representatives are present wanted to have a high level view on all user communities requirements in a one single place. Inside of UCST we decided to find another approach and together with an it-support the new mechanism was developed to synchronize the ticket details between RT system and EGI.eu Wiki, it could be called “RTreader”. We created a new structure to list requirements and by using “RTreader” to synchronize their important details in a clear and self-explanatory dynamic page which is named Track User Support Requirements. The page provides currently open requests, status, important details and as well as the stage the requirement currently is in. The “RTreader” mechanism is based on RT API and our developed MediaWiki Extension which allows displaying all the requirement - ticket fields inside the EGI Wiki by simply using markup language as we used to e.g.:
<rt ticketid=<id> field=<requirement ticket field>/>
There is also the dynamic page dedicated for listing the solved requirements submitted by user communities. For the mechanism we use RT queries to feed the MediaWiki RSS Reader.
At the moment as our experience shows that whichever system you are going to take as base for your requirements tracking demands, there will be always something you will have to customize – either your processes or the base system or both. The main important features the systems should have are: easy ways of customizing the user interface, creating personalized dashboards and/or gadgets, API and/or structured export of the interested data as well as possibility to add custom workflows and data fields.
So, it will be interesting to see how does EGI requirements tracking system will change in the near future, what other requests for the improvements will be or basically in a few words: what is next ?
