Below are a series of requirements developed by the Petroleum User Group Technical Committee for a system to manage the PUG "LIST"
The key point is that the “system” is not just a text document or collection of spread sheets or web pages, but a proper database with joins, relates, queries, etc. Once that basic design is implemented, and the proper building blocks are in place, you can continue to evolve a robust application. We’ve moved this List from Excel to Wiki to Sharepoint and back to Wiki -- it would be good to land on a robust solution, and not have to move again for a while!
1. Users: the system should identify Users. Perhaps the ESRI global login ID will suffice for this purpose.
2. Enter: entries by Users will be cross-referenced with UserID above, so they can find them again.
3. Browse: filter by User is also needed.
4. Search: fix type for “text” string.
5. Export: again, filter by User.
7. Administrators: would have access to additional User attributes, like eMail, to follow-up on items.
8. Monitor: should also be able to monitor an entire category.
9. Support: this would really be great for managing the priorities. It should offer some relative value, not just a checkbox or boolean Yes/No. The system could keep the aggregate sum of support for ranking purposes, and use this in all of the above sort, search, filter, and reporting options. A tricky item will be how to Normalize the support across Users.
10. Feedback: there should be a separate place for ESRI to provide feedback after reviewing items. It would be good to know if they have put something in their development plan, have it done in a development release, or there is a Beta release that we could test, etc
11. Difficulty: it would be good to have some measure of difficulty attached to each item. The user could estimate, and then maybe ESRI could revise. Then an obvious method for prioritization would be to compute the Price or Rate as Support (Value) divided by Difficulty. It seems to me the list items have a bi-modal or log-normal distribution of both value and difficulty. Some are very narrow and easy bug fixes, and others are big broad requests that might entail huge design changes. There needs to be a mechanism to cherry pick the easy ones and just bang them out, while also continuing long-term work on the larger issues.
12. Company: perhaps Users are cross-referenced to a company, or ESRI license. And that could be cross-referenced to an Industry, etc. Then ESRI could use this system to manage these issues across their entire customer base, not just the PUG, and we could see added leverage of support from Users outside our industry. Of course, the whole subject of weighting would get more complicated, but I would be glad to help design this system, if the basic building blocks are in place .
13. Close those that are no longer valid have little support.
14. Request additional information, business justification, etc. for those that are too thin.
15. Identify those that need to be evaluated in v10.