Closed kostko closed 9 years ago
Ok, so my plan for the weekend is to address some comments raised by reviewers 2 and 3. Can you two look into that high-level overview and schematic?
I started thinking about the illustrations yesterday, but I have some questions. I will probably prepare some drafts and then we can discuss them.
So I have a question about high-level overview: is it supposed to be a step-by-step illustration of how a user joins a community network by registering a node, flashing it and installing it somewhere? Will this be the story? We can add some detailed steps like firmware builder and tie them to the specific sections in the paper.
Yes, I think that something like this should be in the high-level overview? @mitar? I also like the idea with referencing specific sections, so that it is immediately apparent what happens where.
Yea, I agree. I would also maybe then have a diagram of a node life-cycle. Probably the same. So things do not end with installation. But then you start monitoring, observing warnings, and if a node fails, you can reflash it with new device (potentially different hardware completely), but same configuration.
On the other hand, it should be clear that this is only one possible way to do it and nodewatcher can support others as well. Maybe we should have this diagram in a section explaining wireless community network building and then an example how we do it in wlan slovenija, and referencing the sections. But it should be clear that this is just our motivation, and not required.
Node life-cycle is already illustrated in Figure 1, we should not make redundant plots. Besides, going into too many details about possible, but less likely scenarios will just make the overview complex and dissolve its meaning.
Another question is where should we place this overview in the text? If it is too early then we will be describing the general idea of a generic community network. If it is too late it will not be an introduction any more.
Yea, maybe we should expand Figure 1 then. Like have the social part which leads to technical part, which is then current Figure 1.
One other thing. I think also we need steps before registering a node. So a person learns about the network, wants to participate, come to the site, sees other nodes, wants to add their node. Then they register, and so on.
Not sure how to make this in a diagram. Probably it can be just in text. But I think that the text will have to discuss the whole social and bottom-up aspect as well.
I guess that social aspects are important, but I would not mix them into the overview. The overview has to be short and if you want to discuss the social aspects it can point to a section that discusses them further. But we should focus on comments and those say: the paper does not have an overview that would motivate the technical details - provide one. I do not see a request for detailed social analysis, so that can be another paper :)
How I read is that it also do not have an explanation how a community setup network is done, and what is different from traditional networks. This is what I have in mind when I talk about "social" aspects.
But yea, diagram probably cannot have that anyway. I can write a bit about that then in the text around it.
Attaching the proposed design for Figure 1 by @lukacu for comments, so it will not get lost in the e-mails.
I like it as it clearly shows where the community is involved. I think that this was also one of @mitar's early comments (while we were preparing the initial paper), that Figure 1 should somehow include people. And now it does :-)
So I assume that a, b, c, d, e and f would then be explained in the figure caption?
Yes, the idea is to tie in the letters to the description in caption or in text. I think that this figure still captures the cycle in the current figure, but is less abstract. If the community looks too uniform I can make more silhouettes but it will take time. If you think that something is missing I can add it, but the figure is pretty full already. On 20 May 2015 10:10, "Jernej Kos" notifications@github.com wrote:
Attaching the proposed design for Figure 1 by @lukacu https://github.com/lukacu for comments, so it will not get lost in the e-mails.
[image: deployment-3] https://cloud.githubusercontent.com/assets/543739/7721457/1a3750c8-fed8-11e4-84bb-096349fca95f.png
I like it as it clearly shows where the community is involved. I think that this was also one of @mitar https://github.com/mitar's early comments (while we were preparing the initial paper), that Figure 1 should somehow include people. And now it does :-)
So I assume that a, b, c, d, e and f would then be explained in the figure caption?
— Reply to this email directly or view it on GitHub https://github.com/mitar/paper-nodewatcher/issues/1#issuecomment-103803899 .
I see that you have included the new figure, it looks great! There is just one small typo, it says "mantainer" instead of "maintainer".
BTW, there has really been a lot of feedback from other communities, so we now really have a huge feature table:
I have created a snapshot of the above table and marked the items, which should be checked:
Can you add notes to the table what you think is wrong with each?
Updated.
@lukacu great work on the table!
Btw, Figure 1 previously had a feedback arrow between the generation and configuration stages. This arrow is very important and is also mentioned elsewhere in the paper. Can it be added back somehow (it doesn't need to be so fat)?
Sure, I will update it, I can also make these arrows bidirectional, but I guess that would be too confusing. In any case we should update the text so that this is more clear.
I have now done some updates to the table and described it in text.
BTW, the illustration showing the differences between proprietary and community networks is really nice.
I have now updated the revision letter, adding some responses. You can check if these are ok.
The missing responses are now to Reviewer 1 and the last question of Reviewer 3 about the use of the platform in our community and elsewhere. For this last comment, I think that we should highlight that the Croatian community is using it and we have been able to easily support some new devices, which were previously unknown to us (the lantiq platform). This is already mentioned in the paper so it just needs to be highlighted in the revision letter.
Additionally, we can now say that OTI has decided to use nodewatcher as a basis of their Commotion Wireless dashboard:
I have added the text for the response to Reviewer 1, but someone has to write the details about the changes (I do not know which sections were moved from where). I have set up a skeleton for the summary of changes, so just fill in which sections were moved where.
I have now updated the response to Reviewer 1.
In the table 1, why for manman we have in TP column a check, and not D or S? For webframeworks, what is a difference between -
and custom
?
We are claiming that "Both node database solutions are built on custom web frameworks, further limiting the ease of adoption by a new community network.", but it seems that guifi.net is using Drupal? That is pretty standard web framework.
Yeah, this was from before, because their code really doesn't look to use any framework even though it might be a Drupal module :-) I will fix it.
In the table 1, why for manman we have in TP column a check, and not D or S?
Well, there is no source code for manman, so we can't know which is it. And whoever entered manman into the table just placed a "yes" there.
For webframeworks, what is a difference between - and custom?
For example, Ondataservice is not a web application, so this probably doesn't apply. For the others, I will replace them with "custom".
Hm, but it says that Ondataservice uses PHP. Ok perhaps there is some frontend for that distributed OLSR database. I will just change it to "custom" everywhere.
In revision letter, for reviewer #3, comment 2, should we mention that guifi.net does not support modular firmware configuration generation, nor image generation? I think the reviewer's comment somehow misrepresents what we are claiming to be unique? Should we point to the section where we are clearly explaining this?
Reviewer 1