<div dir="ltr">and maybe as pointed before one more <span style="font-size:12.8000001907349px">responsibility </span><div><span style="font-size:12.8000001907349px">     hardware automatizing that could be reponsible of automatizing powering </span><span style="font-size:12.8000001907349px">off</span><span style="font-size:12.8000001907349px">  </span><span style="font-size:12.8000001907349px">on routers or mobility of routers or something like this with arduino or ESP...</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 11, 2015 at 11:49 AM, Nemesis <span dir="ltr"><<a href="mailto:nemesis@ninux.org" target="_blank">nemesis@ninux.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>I agree 100%.<br>
      <br>
      And I would add the following, please tell me if you (plural you)
      also agree.<br>
      <br>
      There were quite some people that wanted to help out but it was
      not clear what they could do.<br>
      I think we need more roles, firmware preparation and test manager
      are not enough.<br>
      <br>
      I think we need to have these responsibilities:<br>
      <ul>
        <li>firmware preparation: like now - better if firmware is ready
          before the event with a fixed revision as previously suggested<br>
          <br>
        </li>
        <li>test plan: individuate test scenarios realistically, that
          is, according to the situation of each event (number
          volunteers, technical issues and so on)<br>
          <br>
        </li>
        <li>flashing: flashes devices in mass<br>
          <br>
        </li>
        <li>configuration: reviews config of the past year, checks if
          they can be reused as is or need to be modified, if modified
          gets them approved by the routing devs - better if the basic
          configs are ready before the event<br>
          <br>
        </li>
        <li>deployment & debugging: deploys the testbed and works
          until everything works correctly, updating configs if
          necessary<br>
          <br>
        </li>
        <li>test scripts: writes and tests the scripts to execute tests,
          like much Henning and Thijs did this year, and passes the raw
          data to the graph generation<br>
          <br>
        </li>
        <li>graph generation: writes (or reuses an already written set
          of) scripts to generate graphs from raw data extracted from
          the test scripts<br>
          <br>
        </li>
        <li>documentation: prepares drawing of topology, takes photos of
          the testbed for the presentation, writes an outline of the
          test plan, stores all the configs and scripts used during the
          process for later publication<br>
          <br>
        </li>
        <li>routing team: developers of all the routing protocol
          involved oversee the whole process, with particular attention
          to the test plan phase, configuration and test scripts.<br>
        </li>
      </ul>
      Of course one person can help out with more than one function.
      This year I helped out with configuration and documentation, while
      henning helped out with test scripts, deployment and debugging.<br>
      <br>
      With regular meetings as Pedro suggested plus a high level
      description of the process it should be easy for volunteers to
      understand how they can help out and start working asap.<br>
      <br>
      Federico<div><div class="h5"><br>
      <br>
      <br>
      On 08/11/2015 12:01 AM, guifipedro wrote:<br>
    </div></div></div><div><div class="h5">
    <blockquote type="cite">
      <pre>[About testbed]

Our routing protocols work very well but we did (in my opinion) an
epic fail in human communication.


I propose planned, face to face, regular and short meetings for next
testbed coordination in battlemesh v9 with all the teams [0] involved
in.

Each representative team member could answer this questions [1]:
1. What did you do yesterday?
2. What will you do today?
3. Are there any impediments in your way?

This meetings should be assisted for example with an etherpad or
similar application to have a writing version of that organized verbal
conversation.

[0] and all the members
[1] inspired by daily scrum meeting,
<a href="https://www.mountaingoatsoftware.com/agile/scrum/daily-scrum" target="_blank">https://www.mountaingoatsoftware.com/agile/scrum/daily-scrum</a>
_______________________________________________
Battlemesh mailing list
<a href="mailto:Battlemesh@ml.ninux.org" target="_blank">Battlemesh@ml.ninux.org</a>
<a href="http://ml.ninux.org/mailman/listinfo/battlemesh" target="_blank">http://ml.ninux.org/mailman/listinfo/battlemesh</a>
</pre>
    </blockquote>
    <br>
  </div></div></div>

<br>_______________________________________________<br>
Battlemesh mailing list<br>
<a href="mailto:Battlemesh@ml.ninux.org">Battlemesh@ml.ninux.org</a><br>
<a href="http://ml.ninux.org/mailman/listinfo/battlemesh" rel="noreferrer" target="_blank">http://ml.ninux.org/mailman/listinfo/battlemesh</a><br>
<br></blockquote></div><br></div>