<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">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<br>
<br>
<br>
On 08/11/2015 12:01 AM, guifipedro wrote:<br>
</div>
<blockquote
cite="mid:CABr7qmTTvzRk7EUQBNFKLZRiPY=ijD7CLV4acgBNK6Nbj7EyhQ@mail.gmail.com"
type="cite">
<pre wrap="">[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 class="moz-txt-link-freetext" href="https://www.mountaingoatsoftware.com/agile/scrum/daily-scrum">https://www.mountaingoatsoftware.com/agile/scrum/daily-scrum</a>
_______________________________________________
Battlemesh mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Battlemesh@ml.ninux.org">Battlemesh@ml.ninux.org</a>
<a class="moz-txt-link-freetext" href="http://ml.ninux.org/mailman/listinfo/battlemesh">http://ml.ninux.org/mailman/listinfo/battlemesh</a>
</pre>
</blockquote>
<br>
</body>
</html>