User Support News 30 April 2007

The items from which I expect feed-back are marked in red and the items which I propose as action items in the JOC meeting are marked in bold red .

For your information, the User Support tasks have been summarized in the CMS User Support internal area in CMSUserSupportTasks.


Tutorial session were decided to be held outside of any major CMS/Computing/Offline/Physics weeks.

The next tutorial is planned for in June, possible items: new DBS, iguana, cfg's in python Any other suggestions


  • WorkBook: to get started and up to first analysis
  • Reference Manual: brief description of content and purpose of each package
  • CMS Offline Guide:
    • description of algorithms
    • usage and "how-to" documents which are too detailed for the WorkBook
    • gathers information currently spread in numerous wiki pages to a single structure.


Peter Kreuzer has agreed to update the page on available sample WorkBookDataSamples#SamPles.

CMS Offline Guide

Work in progress:
  • almost all main pages created, JetMet and DQM still missing
  • most reco and physics objects need an extensive effort in documentation (apart from vertexing and b-tagging most pages are littel more that templates)
  • continuously moving in any CMSSW documentation outside these pages (the pages renamed to start with SWGuide, edited following the Offline Guide format and linked from an appropriate place)

Reference Manual

A reminder of the documentation milestone in Note that this is meant to be a very short description (and it is vital that we have such in the cvs directory), all the detailed documentation should go to the Offline Guide.

There was a discussion of the scope of the ref. manual and documentation and the my summary is the following:

  1. No one is really taking care fo the doxygen pages at the moment, and I have raised the issue of the need for it in the JOC meeting and identifying the person is an action item.
  2. I'm strongly in favour of single source of information and against any duplication.
  3. The twiki documentation in the Offline Guide should contain all the information needed and links to the doxygen generated interface pages and to the cvs for the code itself when needed.
  4. For the data formats, I'm in favour of a solution which is easiest to keep up-to-date and maintain. If you like to document them in SWGuide instead in doxygen pages, I have nothing against it.
  5. My understanding is that doxygen documentation is useful and it is used and will be used by users and developers for browsing the class interfaces. Browsing the classes is more user-friendly in doxygen than it is in cvs browser or in lxr (which do have other functionalities) - correct me if I'm wrong.
  6. All the packages should contain a minimum amount of documentation (i.e. the short statement fo the purpose of the package which I'm requiring for the documentation milestone). This can be done in a controlled manner only when the doc source is in the cvs area as it is for the doxygen and not in twiki pages. This issue should not even be under the user support, as a minimum documentation should be an obvious part of the software development process itself.

The two last points are in favour of maintaining a minimum, but uniform level of documentation in the reference manual. The main points are the documented class interfaces and the Package.doc page which shortly states what this package is meant for. The rest is - in my view - easiest done in the Offline Guide, the main problem remaining the issues which differ from a version to another.

Getting help


Savannah reporting getting smoother but still not very much used. I have set it as a primary entry point for the user support help page.

-- CMSUserSupport - 30 Apr 2007

This topic: Main > CMSUserSupport > CMSUserSupportNewsForManagement > CMSUserSupportNews30Apr07
Topic revision: r1 - 2007-04-30 - CMSUserSupport
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback