Member Node Wranglers
    Fridays at 10:30 am Alaska
                    11:30 am Pacific
                    12:30 noon Mountain
                    1:30 pm Central
                    2:30 pm Eastern

GTM info:
29 August 2014
                                                         
Attending: Amber, Rob, Robert, Bruce, Skye, Chris, Laura, Dave, Jing, Matt

Regrets: Mark, Rebecca


Agenda: 

        1. High profile issues (or current items of interest)
        
                epad for the meeting: http://epad.dataone.org/2014-08-22-Dublin-Core-Discussion
                conclusion:  we are recommending that MPC use qualifieddc as their Dublin Core  metadata;  this will support MPC in standing up their MN before their  October review; long-term we want to support their native DDI metadata  
                (Previous discussions here: http://epad.dataone.org/MNWranglers-20140822 )
        
  
Inviting developers to the MNW meetings in Phase 2 - the intent is that devs involved in current MN deployment would be able to provide information/updates, and gather information they need as well.  Not everyone needs to come to every meeting.  Have a very quick update of active developments, and those who need to stay for more detailed work can and others can drop off the call.    
  
          1.  The draft letter to become a (level 3) SP has been circulated to relevant people within DataONE 
          2.  The collaboration was discussed at the Leadership team teleconference – level 3 will be a starting point
          3.  The letter is currently being reviewed by the DataONE leadership  team
           Current status: the letter went to LT a couple weeks ago, Rebecca will  send on to Bill cy Amber/Dave) There is an appendix -  is this  information required as part of the SP agreement?  
           What's the next step after we become an XSEDE SP?  We live as an XSEDE SP for a while, then we look at the possibility of an XSEDE MN? (nothing beyond us becoming a SP) before the AHM.
          
 
        1.5   Current MNs
                 Dryad listObjects issue, see https://redmine.dataone.org/issues/6010 
                     Ryan says they haven't been able to address this issue last 2 weeks
                   
                LTER transitioning from metacat instance to PASTA GMN; 
                      The PASTA GMN is behaving nicely in stage.  There are issues, however,   with the old metacat data we are trying to bring over (see above).
                
        2. Status of upcoming MNs
     
    Future
        5. Around the room
                Rob: Soren is leaving EDAC, Hays Barrett is the new POC (email traffic working on getting Hays set up appropriately to do EDAC things); 
                        documentation work with Laura (Laura needs to read her email :)); 
                        a browndog MN: http://browndog.ncsa.illinois.edu/index.html#home - Ian Foster, plan to target long-tail data, see also Brian Heidorn; see also: 
https://opensource.ncsa.illinois.edu/confluence/display/BD/Brown+Dog+DataONE+Member+Node and 
https://opensource.ncsa.illinois.edu/confluence/display/BD/CIF21+DIBBs%3A+Brown+Dog
                Chris: nope; for Phase 2, we need to think about how we can scale up (re: time it takes to get a MN online)
                Matt: in LT, CDL is thinking about creating a new platform called DASH (?)
                Robert:  nope
                Dave: nope
                Skye: nope
  


        3. Old action items
                 MN Documentation - MN Deployment and MN Ongoing Operations - Laura to    do  this  -- working on identifying needs and best methods to address    those  needs, including ask.dataone.org, documentation in mule1 or  on    dataone.org, etc.

Laura to ask Rob about order of testing (when and where) - document this, also what does "good to go" mean?
             
        4. Not-high profile issues
        
               Process for end-of-implemention (when/how to indicate a MN is    "upcoming" on the dashboard, etc.) - Laura and Amber - we had   previously  decided that when a MN goes into stage testing, it is   appropriate to  show them as an upcoming MN.  However, in redmine we   don't currenty have  a status indicating what stage a MN is working  in.   We have a "testing"  status, so we had thought we'd use that -  when a  MN changes status to  "testing", we can show it as upcoming.  We  still  need to explicitly  define the process and who does what when,  and try  it out on the next  MN(s) in the queue.
              Amber: maybe list them on web as "upcoming" when we go to staging --   but we need a redmine state to show that staging has started.   Dave to   look and see if can notify Amber and Laura (and Bruce?) when  there  are  changes to the stage and production node lists. Need a redmine  state to  show that staging has started.
            
            (Was under Current MNs related to SANParks, CDL, etc.)
              LT  to address Memorandum of Understanding (re: operations and service   expectations) between DataONE and MNs  -  is there anything I (LM) can   be doing to move this along, draft something up, pull out the work   previously done, etc.?? (Rebecca, Mark, & Laura have been tasked   with this and will begin work week of 8/11)  -- or maybe not.  Wait a  bit until Phase 1-Phase 2 transition over?

       

Tickler (things to revisit periodically)

Purpose of MN Description Document (past and future) 
        Intent is to describe the (potential) MN, identify the     types/quantity/formats of data they hold, - perhaps we need a      "friendlier" format, perhaps an interview process;
        Workflow: should this information (MNDD) be collected at the   beginning   of the process, or is the way we've been doing it lately   (after the   fact) a new way of doing business??  Also consider if   this  information   gathering (form or interview) is the best use of   resources for those   potential MNs who may or may not become a MN if   implemented as a first   step.  Possibly change the workflow? Is a pdf   the best way to view the   information?
    Next steps:  Laura to come up with alternative(s) to current MNDD - content is good, but format/mechanism needs some work.  
    Another thing: Laura and Amber to look at workflow for last stages of implementation, test with EDAC  too late for that, need to pick another one.
    Also -- how does the MN DD relate to: 
                    the node document:  https://cn.dataone.org/cn/v1/node  - developers have/create this information (node registration, see updateNodeCapabilities)
                    and redmine??    <--- work with redmine as mostly-authoritative source
        Could a spreadsheet be a viable solution?  Maybe.  A database would     work.  In any case, some information is appropriately "private" -    how    would we handle that?
                

Revisit the default "only results with data"     checkbox to unchecked; plan is to move the   checkbox from search   page   to results page but remain checked by default, initial draft  in    development environment.
               
Bob's feedback about the dashboard - he suggested a count of MNs on the dashboard (MNs, RNs), probably/maybe an easy thing to do a count of MNs and RNs and display