<p><b>@waehlisch</b> requested changes on this pull request.</p>

<p>Further comments will follow.</p><hr>

<p>In <a href="https://github.com/RIOT-OS/RIOT/pull/10162#discussion_r252470969">doc/memos/rdm-draft-petry-riot-design-goals.md</a>:</p>
<pre style='color:#555'>> +## 2.8. Education
+
+The broad technical scope of RIOT makes it useful as a basis for education.
+This requires:
+
+  - The presence of didactic materials related to RIOT
+  - Clear and easy to find documentation
+  - A general availability of supported hardware and tools
+
+# 3. Design philosophies
+
+RIOT satisfies the requirements of all the use cases given above, and does so
+in its own unique way, a way that reflects the collective personality of the
+RIOT community. RIOT is the Friendly IoT Operating System: it is friendly to
+users, allowing them to easily build and deploy IoT solutions that are stable
+and trouble-free.
</pre>
<p>You should also explain why RIOT is friendly to developers.</p>

<hr>

<p>In <a href="https://github.com/RIOT-OS/RIOT/pull/10162#discussion_r252471678">doc/memos/rdm-draft-petry-riot-design-goals.md</a>:</p>
<pre style='color:#555'>> +  - Include and support any relevant hardware
+
+## 2.8. Education
+
+The broad technical scope of RIOT makes it useful as a basis for education.
+This requires:
+
+  - The presence of didactic materials related to RIOT
+  - Clear and easy to find documentation
+  - A general availability of supported hardware and tools
+
+# 3. Design philosophies
+
+RIOT satisfies the requirements of all the use cases given above, and does so
+in its own unique way, a way that reflects the collective personality of the
+RIOT community. RIOT is the Friendly IoT Operating System: it is friendly to
</pre>
<p>s/and does so in its own unique way, a way that reflects the collective personality of the RIOT community./ based on rough consensus within the RIOT community to reflect the collective personalities of the RIOT contributors and users./</p>

<hr>

<p>In <a href="https://github.com/RIOT-OS/RIOT/pull/10162#discussion_r252472154">doc/memos/rdm-draft-petry-riot-design-goals.md</a>:</p>
<pre style='color:#555'>> +  - Control various specific actuators such as motors, solenoids, or valves
+  - Collect and send data with a low latency, or at least a well synchronized
+    timestamp
+  - Potentially have a very low unit cost, particularly when the networks are
+    implemented in mass market products such as automobiles
+  - Potentially run control algorithms themselves.
+
+## 2.5. Edge systems for building management and automation
+
+Various sensing and environmental control tasks can be done by edge nodes in
+buildings. The nodes need to be able to:
+
+  - Sense temperature, light, humidity, pressure, current, etc
+  - Control temperature, light, ventilation, etc
+  - Connect to the building management system, via wired or wireless connectors
+  - Deliver data with controllable timing and accuracy.
</pre>
<p>Punctuation is inconsistent in the list of items. You probably should finish each item with a ".".</p>

<hr>

<p>In <a href="https://github.com/RIOT-OS/RIOT/pull/10162#discussion_r252473066">doc/memos/rdm-draft-petry-riot-design-goals.md</a>:</p>
<pre style='color:#555'>> +#### Energy efficiency
+
+RIOT nodes sometimes need to last for several years without external power, so
+they need to manage energy carefully. RIOT's tickless scheduler lets devices
+sleep while they aren't collecting data.
+
+Modules outside the core should leverage the benefits and address the
+programming challenges of such a scheduler. They shouldn't demand that users do
+the same.  They should, however, allow users to manage power through different
+modes and functions.
+
+#### Small memory footprint
+
+Most of RIOT's targeted use cases are well addressed by devices in class 1 of
+the taxonomy presented in [1]. If small price differences are important or the
+energy budget is particularly tight, the available memory might be near the
</pre>
<p>Gap in argumentation: Why does a tight energy budget directly correlate with tight memory?</p>

<hr>

<p>In <a href="https://github.com/RIOT-OS/RIOT/pull/10162#discussion_r252474279">doc/memos/rdm-draft-petry-riot-design-goals.md</a>:</p>
<pre style='color:#555'>> +available ROM by over half, depending on the architecture.
+
+RIOT should provide out-of-the-box support for devices with ~10 KiB of
+available RAM and ~100 KiB of ROM. It should be just as possible to address
+real use cases involving even smaller devices, starting at ~2 KiB of RAM and
+~10 KiB of ROM, via manual configuration, and via modules which prioritize
+memory efficiency in their design without of course departing from any
+specifications that are used to describe the module.
+
+#### Constrained networking
+
+RIOT should deliver best-in-class communication performance and robustness.
+
+Network stacks should remain up-to-date as relevant standards emerge; they
+should be adequately extensible to support this. Users should be able to
+configure them according to technological options, and choose between
</pre>
<p>s/to technological options/to their needs/</p>

<hr>

<p>In <a href="https://github.com/RIOT-OS/RIOT/pull/10162#discussion_r252475756">doc/memos/rdm-draft-petry-riot-design-goals.md</a>:</p>
<pre style='color:#555'>> +available RAM and ~100 KiB of ROM. It should be just as possible to address
+real use cases involving even smaller devices, starting at ~2 KiB of RAM and
+~10 KiB of ROM, via manual configuration, and via modules which prioritize
+memory efficiency in their design without of course departing from any
+specifications that are used to describe the module.
+
+#### Constrained networking
+
+RIOT should deliver best-in-class communication performance and robustness.
+
+Network stacks should remain up-to-date as relevant standards emerge; they
+should be adequately extensible to support this. Users should be able to
+configure them according to technological options, and choose between
+high-quality implementations which address performance tradeoffs differently.
+They should be able to get the best performance and most relevant functionality
+out of whatever resources they have available.
</pre>
<p>I'm not sure if I can follow the argumentation. Most aspects are not specific to the networking subsystem in RIOT but might be applied to other parts in RIOT as well.</p>
<p>Regarding networking, I think we want to express that RIOT considers constrained environments but that RIOT values interoperability (for the sake of inter-connectivity = IoT) more than saving one bit. Do we agree on this?</p>

<hr>

<p>In <a href="https://github.com/RIOT-OS/RIOT/pull/10162#discussion_r252477662">doc/memos/rdm-draft-petry-riot-design-goals.md</a>:</p>
<pre style='color:#555'>> +Above the HAL, the only thing that modules should know about hardware is
+whether its build dependencies are provided or not. If they aren't, the module
+should adapt accordingly, or not compile.
+
+## Real-time capabilities
+
+Different real-time guarantees are required for different use cases. Low
+frequency sensing needs only soft real-time support and can handle less timing
+accuracy so long as the timers support long timescales. Sensing and control
+applications which do not require hard real-time guarantees are also supported.
+
+RIOT should deliver soft real-time guarantees which address the use cases given
+in section 2. It should provide timers which can competently handle the
+timescales of any application.
+
+## Interoperability
</pre>
<p>Why is interoperability limited to networking? What about I2C, USB etc.?</p>

<hr>

<p>In <a href="https://github.com/RIOT-OS/RIOT/pull/10162#discussion_r252478724">doc/memos/rdm-draft-petry-riot-design-goals.md</a>:</p>
<pre style='color:#555'>> +
+## Modularity
+
+Logical separation of the different modules of RIOT enables a highly distributed
+community to separate development work while reducing the risk of knock-on
+effects across the system. It also allows third parties to develop modules,
+expanding development efforts from just the RIOT community and repo. There is a
+balance to be struck, however: too fine-grained can come at a cost of
+unnecessary complexity, higher resources, and difficulty of understanding.
+
+## Independence of the underlying hardware
+
+Development should be able to be done once and run on any platform using RIOT.
+To achieve this with reduced development effort in porting, the hardware is
+abstracted and the APIs are uniform at as low a level as possible.
+
</pre>
<p>I'm not sure if I like the order of the subsections. For example, the current text in "Versatility" reads like high-order insights that should be moved to the beginning of this section.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/RIOT-OS/RIOT/pull/10162#pullrequestreview-198348277">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AEn7YCVgGdrdzb5GRXUDT-3lsfdy2DXKks5vIiizgaJpZM4Xb9Mj">mute the thread</a>.<img src="https://github.com/notifications/beacon/AEn7YKGLszbI6lT0ifyH6JboozngiAfqks5vIiizgaJpZM4Xb9Mj.gif" height="1" width="1" alt="" /></p>
<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/RIOT-OS/RIOT","title":"RIOT-OS/RIOT","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/RIOT-OS/RIOT"}},"updates":{"snippets":[{"icon":"PERSON","message":"@waehlisch requested changes on #10162"}],"action":{"name":"View Pull Request","url":"https://github.com/RIOT-OS/RIOT/pull/10162#pullrequestreview-198348277"}}}</script>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/RIOT-OS/RIOT/pull/10162#pullrequestreview-198348277",
"url": "https://github.com/RIOT-OS/RIOT/pull/10162#pullrequestreview-198348277",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>