| | 1 | = Telecon 26JUL07 = |
| | 2 | |
| | 3 | This was a telecon with myself, Paolo and Mike, where we hashed out some of the details. See the follow up [wiki:SDSCMeeting02AUG07] for some of the decisions. |
| | 4 | |
| | 5 | |
| | 6 | = Telecon Agenda = |
| | 7 | |
| | 8 | Here's the outline of the agenda, details of each item are below: |
| | 9 | |
| | 10 | 1. Data access policy |
| | 11 | 2. Archive structure |
| | 12 | 3. Web site |
| | 13 | 4. User support responsibility |
| | 14 | 5. Organizing contributed software |
| | 15 | 6. User accounts |
| | 16 | |
| | 17 | These are the things we need to have settled before we meet with SDSC, so that we can get the most out of working with them. By the end of our call tomorrow, we need a short action plan and schedule to ensure that we have a foundation in place for the workshop. |
| | 18 | |
| | 19 | == Agenda Details == |
| | 20 | |
| | 21 | 1. Data access policy |
| | 22 | |
| | 23 | We need to to decide who has read/write access to what data. The ostensible role of this project is to provide a shared space for data, so it seems reasonable to require all users to permit other users read access, but not to write. This may be a hard sell for some, but if we don't require users to share their data, all we're doing is providing free data storage and CPU time. |
| | 24 | |
| | 25 | Please, note we're not talking about public access, that's a future topic. |
| | 26 | |
| | 27 | 2. Archive Structure |
| | 28 | |
| | 29 | I see three ways to organize the data initially: |
| | 30 | |
| | 31 | * by contributor (group/person) |
| | 32 | * by code (e.g., Enzo, Gadget) |
| | 33 | * by topic (AGN, turbulence) |
| | 34 | |
| | 35 | By contributor is certainly the easiest to get things going, and we can add metadata to allow for searching along the other lines. However, by code lends itself to organizing the data and contributed analysis software along the same lines. And by topic may be the most relevant for the workshop. |
| | 36 | |
| | 37 | I think if we want buy in, we should allow users to upload data into their own space, and provide them with some basic guidelines and a means to document what they've uploaded. |
| | 38 | |
| | 39 | 3. Web site |
| | 40 | |
| | 41 | The web site has two roles, to provide documentation, and to allow users to browse and upload the data. At the start, documentation will be far more important, since users will have access to many SRB clients, but only one place to go for information. |
| | 42 | |
| | 43 | I have just gotten access to the web site, and will do my utmost to poke around it tonight, and find out how content can be added. In the worst case, we move the current templates, and put up static content temporarily. |
| | 44 | |
| | 45 | 4. User support responsibility |
| | 46 | |
| | 47 | There will be a significant time commitment at the start of this in helping people to get user accounts, add data, set permissions, etc. Two tools can help right away: a mailing list and good documentation. But, in the end the responsibility falls on us to make sure things work. |
| | 48 | |
| | 49 | I am excited about this project, and am willing to invest time in architecting it, but I do not have time left over for answering emails about logging in. That means either somebody steps up to do this, or we task someone. Jake Streeter is a good candidate, if there is a means to pay him. |
| | 50 | |
| | 51 | As an a reward for anyone who's read this far, here's an anecdote: About a year after I started working for my cousin delivering parts, we started talking about getting a bigger truck to haul more materials. By that time I was writing software to generate automated parts list and track what items were headed to L.A., San Francisco or Vegas, along with scheduling crews and ordering parts. There was no way I could do more driving and take on more responsibility. What I told my boss (my cousin) was: "That truck needs to come with a driver." We bought the truck, hired the driver, and I managed the driver and did more stuff. |
| | 52 | |
| | 53 | Gentlemen, what I am saying is: This truck needs to come with a driver. |
| | 54 | |
| | 55 | 5. Organizing contributed software |
| | 56 | |
| | 57 | It is assumed people adding data will add some scripts or programs for analyzing the data. To support this, we may want a central file location on gpfs-wan (probably not in the archive) or /usr/local/apps (/usr/local/cadac?) where these tools can be added. This may be more of a question for SDSC, since they control the filesystems. |
| | 58 | |
| | 59 | 6. User accounts |
| | 60 | |
| | 61 | This is like the software issue, we need to have our questions ready for SDSC. Namely, how do allow for adding new users before the LRAC proposal is approved? And how do we fast track a bunch of new accounts near the start of the conference? This may involve SDSC setting up an account, and coordinating the add user forms to go in en masse. |
