The GridPP Wiki The case in favour of it Generic, standard information (e.g. GridPP Approved VOs) Common use cases (e.g. proxy renewal) Core task responsibilities/procedures Common forum to share our specific experiences (installation, tests, debug …) Augmenting vendor supplied documentation Cut down on the “over and over again” To demonstrate: the challenge, the mastery and the contribution that we all like to make (Dan Pink, motivation expert) But: avoid Brain Burps (stuff that won’t get maintained, no matter what)

Problems The wiki should augment the other documents, such as vendor supplied material, lists and alerts, Google etc. Hence there is the risk that documents will become stale or ambiguities will arise. For this reason, the idea of KeyDocs (McNab) has arisen. There is no “planning” within the GridPP wiki. It is simply a shared space that we maintain together. So we documentation coordinators have to rely on you to look for areas where you could make a contribution (or ask us). If you feel there is a document that you could write, or review, then please do so. If you notice that documents are stale and out of date, then adopt them (or ask us). This is (sort of) an altruistic enterprise, like Linux and Apache etc. Like those projects we don’t know if it works, but we trust to experience that it does.

Progress Structure is emerging; see As of Friday, 13 th, there were 28 documents in the list of KeyDocs. 17 have been reviewed, and 13 are considered to be up to date: 7 relate to storage topics, 3 to documentation, 2 Accounting, 2 Monitoring, 2 Wider VO (Approved VOs), 2 Security, 3 Ticket Follow-up, 2 On duty coordination, 2 Regional Tools, 1 each on Core Grid Services, Staged Roll-out, Grid Interoperation. Thanks are due for these contributions. Re: specific experiences relating to topics like WNs, CEs, APEL, BDII, ARGUS. We propose a new area (Cluster Management), and (as an example), I've added a tutorial involving EMI CREAM:

Conclude Good reports and data in the wiki can help define what we need to do, cut down on the googling and repeated mistakes, form a basis for sharing our experiences, augment the vendor supplied documentation and describe our own individual set-up and use cases. It's important to have a way of sorting the wheat from the chaff, hence the KeyDocs process. Over time, we hope poor documents will be removed, and new ones will be written to plug gaps in our knowledge. It depends on each of us to try this. We’ll persist with that which works, and change that which doesn’t.

Discuss? (i.e. generate some requirements) In a recent TB_SUPPORT thread, it came out that, apart from documentation for individual products, there is no integrated documentation for the overall process. Yet VOs experience difficulties with this. Should EGI make it a requirement for overall processes to be documented via, e.g. the glite User Guide? Should GridPP, as a group, suggest a particular middle-ware distribution (e.g. EMI, UMD,...) and document that, or should there be no such suggestion? Are are expectations for site admins crystal clear? Or are there mysterious elements that need to be exposed and explained? Is it transparently obvious how the planning, monitoring and security structures of GridPP work? Or do we need more definition. More? Questions? Tips? Requests? Criticism?