All,
I'm putting this out on gridpp-ops and tb-support to get to as many
GridPPers as possible. Alessandra has raised a thorny question on
documentation for users. Please see below. Specifically, much of the
documentation we have was generated and maintained by Tom Whyntie who is
no longer part of the collaboration. Hence there are questions about
completeness, accuracy, usefulness etc., and we may want to discuss our
options. Hence I'm inviting your views on the matter. To start things
off, I'll give you my views.
First, should we think big or small? If we think big, our ambition
would be to put in sufficient manpower and focus to this task to make
sure that all combinations of currently "plausible" ways of using the
capabilities of our systems should be usefully documented so that any
user can access them with any of those methods. Given the present
situation (fast changing technologies, limited time and funding,
pressing other concerns ...) I don't personally believe it is right to
take that path. We need to think much smaller than that, I'm afraid. So,
we must address some of the specific issues Alessandra has raised
"quite" cheaply. The choices appear to be:
a) Get another "Tom" who is as thorough and good (I don't think this is
on the cards) or
b) Get someone (me?) who just responds to documentation issues as and
when they occur, by applying the changes required by "VO Champions",
sysadmins and various users in the current manner, i.e. via github.
c) Put the material in some wiki (e.g. GridPP wiki) that Site Admins and
certain other users can access to update it .
Alternatively, we could do something more radical. We could document the
operational baseline that each existing VO has adopted. Then, when
another VO comes along with similar or overlapping requirements with one
or more existing VOs, it would be a cut-and-paste job to make a new
baseline. Each VO would have one document from a standard template to
describe how they operate with respect to security, job submission (Grid
or cloud tech), storage and file management, file transfer, monitoring,
planning and so forth. From that, training and end-user documentation
could be generated.
Alessandra suggests option (c) above (it might be possible to do a quick
and semi-automatic translation from Github to wiki?) But perhaps we
should discuss these and other ideas, perhaps starting with a short
session at the ops meeting tomorrow, and maybe setting up a longer
meeting later. Anyway, that's all I have to say on the matter for now.
Please feel absolutely free to give me your feedback on these issues.
See you (or hear you) tomorrow perhaps. Cheers,
Ste
On 21/05/18 12:49, Jeremy Coles wrote:
> Hi Alessandra,
>
> Yes we should discuss. I was not previously aware of this issue on updates. We designated Steve as lead on the ops area for documentation… so Steve please could you pull together the options and the pros and cons to guide the discussion. If there is time during the ops meeting we can progress it then, but otherwise a special meeting can be set up this week or next for those interested/affected.
>
> Jeremy
>
>
>
>
>
>
>> On 21 May 2018, at 19:05, Alessandra Forti <[log in to unmask]> wrote:
>>
>> Hi,
>>
>> I'd like to start a discussion about the gridpp documenation location. Tom did a tremendous job to write documentation for users. He however chose a mechanism to maintain it (github) that requires the existance of a person in charge of the project or everyone who wants to contribute to be added.
>>
>> https://github.com/gridpp/user-guides
>>
>> while discussing with UK-LSST there have been already instances in which the documentation needed change and couldn't be updated. Last year they tried with a pull request which is still unanswered after almost a year (and I note there is another pull request waiting since January), this year I told them I would raise the issue to put this documentation in the wiki (again I must say). Could we discuss alternatives with minimum effort required if someone wants to update?
>>
>> cheers
>> alessandra
>>
>> --
>> Respect is a rational process. \\//
>> Fatti non foste a viver come bruti, ma per seguir virtute e canoscenza(Dante)
>> For Ur-Fascism, disagreement is treason. (U. Eco)
>> But but but her emails... covfefe!
>>
--
Steve Jones [log in to unmask]
Grid System Administrator office: 220
High Energy Physics Division tel (int): 43396
Oliver Lodge Laboratory tel (ext): +44 (0)151 794 3396
University of Liverpool http://www.liv.ac.uk/physics/hep/
|