Design process and template for Mbed-OS #7561

SenRamakri · 2018-07-19T19:01:15Z

Description

This documents the software design process for Mbed-OS. Anyone developing for Mbed-OS can use this process to submit the design to get it reviewed from the broader Mbed-OS developer community. This change contains documentation on the process, design template and an example design document. The template is developed based on the philosophy that it should capture the details of software design and not how the development itself is tracked/tested. Please look at below docs for more info:

Design Process:
https://github.com/ARMmbed/mbed-os/pull/7561/files#diff-43cd5a0825320bdbd0598823eeb945ab

Design Template:
https://github.com/ARMmbed/mbed-os/pull/7561/files#diff-a494f1e71adb00e6a436fa9d963fb214

Example Design Document:
https://github.com/ARMmbed/mbed-os/pull/7561/files#diff-44bf7630a4f8e06c3c8cb9e9d5659b75

Pull request type

[ ] Fix
[ ] Refactor
[ ] New target
[x] Feature
[ ] Breaking change

cmonr · 2018-07-20T01:46:53Z

@SenRamakri I'll put this in my queue for review for tomorrow, but I do want to ask, is there a reason that this is coming into this repo instead of the Handbook?

SenRamakri · 2018-07-20T02:18:48Z

@cmonr - Good question, there are few good reasons for this to be in mbed-os repo. The idea is to have design documents in the same location where the corresponding implementation is and these are supposed to be living documents and capturing updates to the implementation anytime. Also the current model for the docs repo is to publish with each mbed-os release(as htmls) under os.mbed.com. Design documents can come in and can change any time and may not fit that use case. It also makes sense for developers to use single repo with code and its design documents as they will be working on both of them in unison and also helps with easy cross-reference. Also being in same repo helps with binding the specific versions of design document to the version of code changes, this will be tough if they end up in different repo. Thus, it makes sense for us to keep the process/template in mbed-os itself where developers can easily find/adopt it. Hope this answers the question.

0xc0170 · 2018-07-20T14:17:36Z

docs/design-documents/design_template.md

+    - [Custom Headings Here](#custom-headings-here)
+
+### Revision history
+1.0 - A brief description for this version, e.g. Initial revision - Author name - Date


do we need revision here? It's in git so we see what has changed and when. No need to version this document like this

@0xc0170 - I think we need the revision here because an author can make multiple changes in github to capture the new ideas or to match the implementation. But they all might point to one logical design. That's why I thought a revision here makes sense. For example, some one might push a change and then may decide to make some typo fixes/minor interface name changes which will be updated into the document. But it doesn't change the design logically. Its more like major design version and git versioning will be more like minor versioning.

Should we put it at the end like in IETF RFC? I would say it's not something you want to read first.

If we keep a revision number (as opposed to using git) we need to agree on what it should be. Maybe it's more appropriate to say: "This document's revision addresses Mbed OS 5.10 onwards"? That way it's more understandable to see what versions of the OS this document addresses.

0xc0170 · 2018-07-20T14:25:37Z

docs/design-documents/README.md

@@ -0,0 +1,40 @@
+# Design Process for Mbed-OS
+This document defines the software design process for Mbed-OS. Anyone developing for Mbed-OS should use this process to submit the design to get it reviewed from the broader Mbed-OS developer community.


What does it mean "design" ?

When to use this process? When I do large refactor or want to submit new feature or change user API? HAL change?

Its up to the developer to make a judgement on whether a design doc is required for a change. For small changes its definitely not required. But for changes with lot of code turmoil its best to have a backing design document. Let me try to see if we can update the process document to capture this guideline.

I think it's "Mbed OS" (as opposed to "Mbed-OS") ;)

0xc0170 · 2018-07-20T14:28:51Z

docs/design-documents/README.md

+* It's suggested to write one design document per change, which could be a new feature, defect fixes, tools changes etc. Do not try to address multiple changes in the same document.
+* The design document will follow the format represented in [Design Document Template](https://github.com/ARMmbed/mbed-os/blob/master/docs/design-documents/design_template.md)
+
+* For each design submission, create a folder under *https://github.com/ARMmbed/mbed-os/docs/design-documents/{AREA OR COMPONENT}*. The area/component would be Drivers, Platform, Connectivity, Security, Peripherals etc. 


Do we have areas/components listed anywhere? We got similar problem in labels here on github. I would like to document them and use them here/labels/elsewhere

That's good idea, we can make a initial list. It can be expanded later as well.

0xc0170 · 2018-07-20T14:29:22Z

docs/design-documents/README.md

+* For each design submission, create a folder under *https://github.com/ARMmbed/mbed-os/docs/design-documents/{AREA OR COMPONENT}*. The area/component would be Drivers, Platform, Connectivity, Security, Peripherals etc. 
+  If your implementation is creating new APIs, you should try to match the folder name directly to the new API, otherwise 
+  use the title of the feature as the folder name. 
+  For example, if your implementation is adding new EMAC API, you may name the folder as **New_EMAC_API** or if you are creating a new Serial Driver for Mbed-OS you may name the folder as **Serial_driver_for_Mbed-os**.


I would vote for lower case naming new_emac_api

Well the folder name also serve as the title, that's why I thought it should be capitalized as required.
If more people align with lower_case we can definitely change it.

I'd rather not have 100 folders. We should match it somehow to Mbed OS repo structure.

Yes - hopefully for new features within a component we can just make pull requests that update the existing design doc? Also do we really need design documents for fixes?

0xc0170 · 2018-07-20T14:31:26Z

docs/design-documents/README.md

+Its highly encouraged to create diagrams to depict your software design. The [Design Document Template]((https://github.com/ARMmbed/mbed-os/blob/master/docs/design-documents/design_template.md) provided here uses diagrams generated using draw.io. draw.io generates XMLs for each diagram and those corresponding XMLs are also provided under the diagrams folder, and you are free to use that as your reference for generating your own diagrams. And, when you are generating your own diagrams it would be better to provide the metadata/other files(e.g, if you are using draw.io provide XMLs from draw.io) required for future editing of those diagrams.
+
+## Design Process
+* Developer generates a design document located under *https://github.com/ARMmbed/mbed-os/docs/design-documents/{AREA OR COMPONENT}* and generates a pull-request to Mbed-OS.


Would this be rather : first github issue to discuss the idea (gather feedback) - is it worth my and yours time? Then take time to write it down and create PR with the design specifications

Its ok for developers to gather feedback on some idea if they want, which I think is already happening. But when they have decided to go ahead implement the idea a design document could be generated to capture more details and for later reference.

Its ok for developers to gather feedback on some idea if they want, which I think is already
happening.

I was after if someone already put effort to write down and it gets rejected - I have seen it with pull requests that contained lot of effort but were rejected - maybe my question should have been : when is design document approved and integrated (as well when its rejected and closed) ? How to maximize the success of the design document. I believe ideally it would be if issue gets enough traction and +1 from involved parties, design document would be approved and later implemented.

I would say extra issue is redundant. Explain your idea in this RFC straight away. Maybe it's worth pointing out that the initial submission of the RFC doesn't need to be complete and refined.

0xc0170 · 2018-07-20T14:35:59Z

docs/design-documents/design_template.md

+    - [Custom Headings Here](#custom-headings-here)
+
+### Revision history
+1.0 - A brief description for this version, e.g. Initial revision - Author name - Date


this revision history is not needed here (sufficient to have it in git)

Please see my comment above.

0xc0170 · 2018-07-20T14:38:28Z

docs/design-documents/README.md

+It's possible that a new implementation may require changes to some previous implementations. In that case, capture
+the new changes in the original design document as well. Also create references to other(or older) design documents in the
+References section for the new design document.
+


I comment here but it comes after design phase - what about the implementation ? Is author expected to implement, or rather anyone can do, etc. I think a section here would be sufficient about "after design doc is accepted"

No really, its possible that design document author could be different from implementer. In fact, that's where the document really helps. If the document is detailed enough, anyone can take the document and go do the implementation. Its not absolutely necessary that implementation should be started only after design document review. The only guideline here is if there is change to design it will impact your implementation as well, and thus for large features where lot of design feedbacks are expected it's advisable to start your implementation once major feedbacks are captured. Again, its up to the implementer to make that judgement depending on how big/which part of mbed-os the feature is. For example, API designs can be very intensive and may drastically change over the period of review. In those cases, its best to delay your major implementation cycle until that agreement is reached. But for very localized implementations not impacting other parts of the system/application writers it may be ok to have an implementation initially along with design document.

Correct, I was looking for an answer : what are the next steps after design document is accepted. I would expect this question once first design doc from community is accepted. "What's next?"

What I was thinking here - post design doc accepted. Firstly, design docs are assigned priority. If it's high, we would like to have it implemented right away - either by us or community. Lower priority, will wait for implementation (welcome to do by anyone anytime).

A paragraph describing "next possible steps" . What others think?

SenRamakri · 2018-07-20T17:35:16Z

@0xc0170 - Thanks for your review and I have added a general guidelines section which might help answer some of the concerns you raised. Please take a look.

iriark01 · 2018-07-23T06:27:54Z

@SenRamakri just one comment: we can publish docs at any time (every 10min or so), we don't have to wait a full quarter. So that in itself is not a reason not to put them in the docs repo.

SenRamakri · 2018-07-23T16:16:50Z

@0xc0170 - I agree that we can technically publish docs anytime. But my point is we still have to take another step to get it published(like generating the html and deploying). But, design-docs here is immediately available when merged and can be pull-ed into local repos.

0xc0170 · 2018-07-25T11:54:59Z

docs/design-documents/design_template.md

+```C
+char in_byte = 0;
+int num_bytes_read = read(&in_byte, 1);
+if(num_bytes_read == 1) {


if () - space there (check also the rest of the examples) so they follow our code style

bulislaw

I've reviewed the README, I'll do the rest tomorrow.

bulislaw · 2018-08-07T15:41:49Z

docs/design-documents/README.md

+* For each design submission, create a folder under *https://github.com/ARMmbed/mbed-os/docs/design-documents/{AREA OR COMPONENT}*. The area/component would be Drivers, Platform, Connectivity, Security, Peripherals etc. 
+  If your implementation is creating new APIs, you should try to match the folder name directly to the new API, otherwise 
+  use the title of the feature as the folder name. 
+  For example, if your implementation is adding new EMAC API, you may name the folder as **New_EMAC_API** or if you are creating a new Serial Driver for Mbed-OS you may name the folder as **Serial_driver_for_Mbed-os**.


I'd rather not have 100 folders. We should match it somehow to Mbed OS repo structure.

bulislaw · 2018-08-07T15:45:14Z

docs/design-documents/README.md

+Its highly encouraged to create diagrams to depict your software design. The [Design Document Template]((https://github.com/ARMmbed/mbed-os/blob/master/docs/design-documents/design_template.md) provided here uses diagrams generated using draw.io. draw.io generates XMLs for each diagram and those corresponding XMLs are also provided under the diagrams folder, and you are free to use that as your reference for generating your own diagrams. And, when you are generating your own diagrams it would be better to provide the metadata/other files(e.g, if you are using draw.io provide XMLs from draw.io) required for future editing of those diagrams.
+
+## Design Process
+* Developer generates a design document located under *https://github.com/ARMmbed/mbed-os/docs/design-documents/{AREA OR COMPONENT}* and generates a pull-request to Mbed-OS.


I would say extra issue is redundant. Explain your idea in this RFC straight away. Maybe it's worth pointing out that the initial submission of the RFC doesn't need to be complete and refined.

bulislaw · 2018-08-07T15:48:47Z

docs/design-documents/README.md

+
+## Design Process
+* Developer generates a design document located under *https://github.com/ARMmbed/mbed-os/docs/design-documents/{AREA OR COMPONENT}* and generates a pull-request to Mbed-OS.
+  * NOTE: If you are part of an organization and would like to do design review within your organization before landing the pull-request, its ok to do so.


Do we really need this point I think it's rather obvious.

bulislaw · 2018-08-07T16:14:54Z

docs/design-documents/README.md

+## Design Process
+* Developer generates a design document located under *https://github.com/ARMmbed/mbed-os/docs/design-documents/{AREA OR COMPONENT}* and generates a pull-request to Mbed-OS.
+  * NOTE: If you are part of an organization and would like to do design review within your organization before landing the pull-request, its ok to do so.
+  * The pull request may also include the initial code implementation. It's upto to the develper to decide if the initial implementation comes along with the design document or later.


I would mention that it's advisable to start with a basic outline of an idea, so people can discuss it and then refine it.

I feel like these should be two separate PRs - otherwise you'll have to update the code implementation in sync with each change to the spec.

For NFC we have a PR up for the spec + an internal PR with the API. We rebase the API branch regularly against the spec branch.

bulislaw · 2018-08-07T16:15:44Z

docs/design-documents/README.md

+* Once the design is approved, implementation is completed/adjusted according to the latest design document. Developer can create the pull-request with the final implementation, if its coming separately.
+
+## Capturing future changes to design
+If your implementation changes in future, corresponsding design documents may be updated to capture the new design.


may -> should? should be updated

"corresponsding"

bulislaw

Great work! It looks good. Some general suggestion, the README should be rather small I would say. The process should be defined here https://os.mbed.com/docs/v5.9/reference/software-design.html and guide people through the process. The README should probably reference it and possibly add some hints. We should also get it reviewed by the docs team.

bulislaw · 2018-08-08T10:21:10Z

docs/design-documents/design_template.md

+# Mbed-OS Design Document
+Write your feature title above, in this case its "Mbed-OS Design Document"
+
+# Table of Contents


Do we really need this, it feels like a high maintenance part.

The contents makes it really easy to navigate for large documents. Also makes it easy to see the context specific sections as we let authors to add specific sub-sections as they want.

Yes, I think contents really makes it easy for large docs and to find the sections. Please see my previous comment.

bulislaw · 2018-08-08T10:22:09Z

docs/design-documents/design_template.md

+    - [Custom Headings Here](#custom-headings-here)
+
+### Revision history
+1.0 - A brief description for this version, e.g. Initial revision - Author name - Date


Should we put it at the end like in IETF RFC? I would say it's not something you want to read first.

bulislaw · 2018-08-08T10:25:50Z

docs/design-documents/design_template.md

+* `Reading from and Writing to the device` - Read and Write interfaces should be implemented to support sending single/multiple bytes. 
+* `Resetting the device` - Functionality to reset the device should be provided.
+
+**NOTE: If you already have supporting architecture documentation in the form of technology documents or other existing documents


We should make clear it has to be public.

donatieng

Great stuff @SenRamakri :). I have a few comments below.

donatieng · 2018-08-08T12:31:08Z

docs/design-documents/README.md

@@ -0,0 +1,40 @@
+# Design Process for Mbed-OS
+This document defines the software design process for Mbed-OS. Anyone developing for Mbed-OS should use this process to submit the design to get it reviewed from the broader Mbed-OS developer community.


I think it's "Mbed OS" (as opposed to "Mbed-OS") ;)

donatieng · 2018-08-08T12:33:32Z

docs/design-documents/README.md

+* For each design submission, create a folder under *https://github.com/ARMmbed/mbed-os/docs/design-documents/{AREA OR COMPONENT}*. The area/component would be Drivers, Platform, Connectivity, Security, Peripherals etc. 
+  If your implementation is creating new APIs, you should try to match the folder name directly to the new API, otherwise 
+  use the title of the feature as the folder name. 
+  For example, if your implementation is adding new EMAC API, you may name the folder as **New_EMAC_API** or if you are creating a new Serial Driver for Mbed-OS you may name the folder as **Serial_driver_for_Mbed-os**.


Yes - hopefully for new features within a component we can just make pull requests that update the existing design doc? Also do we really need design documents for fixes?

donatieng · 2018-08-08T12:35:04Z

docs/design-documents/README.md

+  See [Example Design Document](https://github.com/ARMmbed/mbed-os/blob/master/docs/design-documents/example_feature_design/example_feature_design.md) for example design document.
+
+### Using diagrams in Design documents
+Its highly encouraged to create diagrams to depict your software design. The [Design Document Template]((https://github.com/ARMmbed/mbed-os/blob/master/docs/design-documents/design_template.md) provided here uses diagrams generated using draw.io. draw.io generates XMLs for each diagram and those corresponding XMLs are also provided under the diagrams folder, and you are free to use that as your reference for generating your own diagrams. And, when you are generating your own diagrams it would be better to provide the metadata/other files(e.g, if you are using draw.io provide XMLs from draw.io) required for future editing of those diagrams.


For the NFC design spec we're using plantUML/plantText which lets your describe UML diagrams in text formats (and therefore make them easily versionable)

Thats great point, draw.io was only an example. Engineers are ok to use their favorite tools.

donatieng · 2018-08-08T12:35:44Z

docs/design-documents/README.md

+
+## Design Process
+* Developer generates a design document located under *https://github.com/ARMmbed/mbed-os/docs/design-documents/{AREA OR COMPONENT}* and generates a pull-request to Mbed-OS.
+  * NOTE: If you are part of an organization and would like to do design review within your organization before landing the pull-request, its ok to do so.


donatieng · 2018-08-08T12:37:46Z

docs/design-documents/README.md

+## Design Process
+* Developer generates a design document located under *https://github.com/ARMmbed/mbed-os/docs/design-documents/{AREA OR COMPONENT}* and generates a pull-request to Mbed-OS.
+  * NOTE: If you are part of an organization and would like to do design review within your organization before landing the pull-request, its ok to do so.
+  * The pull request may also include the initial code implementation. It's upto to the develper to decide if the initial implementation comes along with the design document or later.


I feel like these should be two separate PRs - otherwise you'll have to update the code implementation in sync with each change to the spec.

For NFC we have a PR up for the spec + an internal PR with the API. We rebase the API branch regularly against the spec branch.

donatieng · 2018-08-08T12:38:09Z

docs/design-documents/README.md

+* Developer generates a design document located under *https://github.com/ARMmbed/mbed-os/docs/design-documents/{AREA OR COMPONENT}* and generates a pull-request to Mbed-OS.
+  * NOTE: If you are part of an organization and would like to do design review within your organization before landing the pull-request, its ok to do so.
+  * The pull request may also include the initial code implementation. It's upto to the develper to decide if the initial implementation comes along with the design document or later.
+  * Although, if you are planning a large change, its encoraged to start the design review early before the implementation. This also help to avoid major re-work of your implementation if required by the design review.


"encoraged" -> "encouraged" / "help" -> "helps"

donatieng · 2018-08-08T12:38:56Z

docs/design-documents/README.md

+* Once the design is approved, implementation is completed/adjusted according to the latest design document. Developer can create the pull-request with the final implementation, if its coming separately.
+
+## Capturing future changes to design
+If your implementation changes in future, corresponsding design documents may be updated to capture the new design.


"corresponsding"

donatieng · 2018-08-08T12:40:29Z

docs/design-documents/README.md

+References section for the new design document.
+
+## General guidelines for creating design documents
+Its up to the developer to make a judgement on whether a design docucment is required for a change. It may not be required for minor fixes and small localized changes. But for changes with lot of code turmoil across multiple components or if its new feature or functionality being added its best to have a backing design document. Its also ok for developers to gather initial feedback on some idea before they decide to implement. Its also not absolutely necessary that implementation should be started only after design document review. The caveat here is if the proposed design is changed significantly in the process of review it will impact your implementation as well. Thus for large features where lot of design feedbacks are expected it's advisable to start your implementation once major feedbacks are captured. For example, API designs can invite lot of feedbacks. In such cases, its best to capture those feedbacks before starting the implementation cycle. But for very localized implementations not impacting other parts of the system/APIs it may be ok to provide an initial implementation(in the same PR) as a reference along with design document.


"docucment" / "its" -> "it's" / "feedbacks" -> "feedback"

Is it a summary? It feels a bit redundant with what's explained in the paragraph starting line 4. Might be worth breaking this down in bullet points (here are the steps).

donatieng · 2018-08-08T12:46:36Z

docs/design-documents/design_template.md

+    - [Custom Headings Here](#custom-headings-here)
+
+### Revision history
+1.0 - A brief description for this version, e.g. Initial revision - Author name - Date


If we keep a revision number (as opposed to using git) we need to agree on what it should be. Maybe it's more appropriate to say: "This document's revision addresses Mbed OS 5.10 onwards"? That way it's more understandable to see what versions of the OS this document addresses.

SenRamakri · 2018-08-08T20:48:43Z

@bulislaw - Good point about the https://os.mbed.com/docs/v5.9/reference/software-design.html. I'll get this reviewed from Docs team and also add docs in Handbook to refer this process. I still think process README itself still belongs here, but will add some description in Handbook and create a link to here.

SenRamakri · 2018-08-08T20:55:48Z

@bulislaw @donatieng - Thanks for your detailed reviews and please see my replies above. And I have put in fixes for all other comments.

@bulislaw - I have also removed some redundancy in descriptions in README as you pointed out. And I also think its better to have revision history in the beginning so that people can see whats changed between versions and its relatively smaller section as well. I have added new directory structure under design-documents to make it better organized.

@donatieng - Good point about mentioning the Mbed-OS version in Revision section. I have added a comment to capture your feedback, please take a look on that as well.

SenRamakri · 2018-08-08T21:03:21Z

@AnotherButler - Can you please review this and probably copy edit for consistency?

Copy edit file for active voice, precise language and consistent style across documents.

cmonr · 2018-08-24T05:38:00Z

@ARMmbed/mbed-os-core @ARMmbed/mbed-os-docs @sg-@sam-taylor-arm @neilwjackson
@AnotherButler @ChiefBureaucraticOfficer @sreekan-a

This is a reminder that a PR is still waiting to be reviewed by you.

0xc0170 · 2018-08-24T13:11:12Z

@AnotherButler happy with PR (approve or request changes) ?

Copy edit file for consistency, grammar, spelling and voice.

Edit template for formatting and major typos.

ghost · 2018-08-27T18:39:38Z

@cmonr - Looks good to me.

0xc0170 · 2018-08-29T10:18:32Z

As this received already few approvals (internal reviews already done), entering CI stage

0xc0170 · 2018-08-29T12:10:22Z

/morph build

mbed-ci · 2018-08-29T13:27:06Z

Build : ABORTED

Build number : 2947
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/7561/

cmonr · 2018-08-29T14:45:42Z

/morph build

mbed-ci · 2018-08-29T17:30:54Z

Build : SUCCESS

Build number : 2953
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/7561/

Triggering tests

/morph test
/morph export-build
/morph mbed2-build

mbed-ci · 2018-08-29T18:46:16Z

Exporter Build : SUCCESS

Build number : 2569
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/7561/

cmonr · 2018-08-29T21:00:08Z

Reshuffling the Integration Test queue. Will restart shortly.

cmonr · 2018-09-01T04:23:54Z

/morph test

mbed-ci · 2018-09-01T07:56:39Z

Test : SUCCESS

Build number : 2733
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/7561/2733

SenRamakri requested review from bulislaw, sg-, 0xc0170, sam-taylor-arm, NeilJackson-AlifSemi, a user and adbridge July 19, 2018 19:02

cmonr requested a review from AnotherButler July 20, 2018 01:47

cmonr added the needs: review label Jul 20, 2018

0xc0170 reviewed Jul 20, 2018

View reviewed changes

0xc0170 approved these changes Jul 25, 2018

View reviewed changes

SenRamakri requested a review from donatieng July 25, 2018 14:25

bulislaw reviewed Aug 7, 2018

View reviewed changes

bulislaw reviewed Aug 8, 2018

View reviewed changes

donatieng reviewed Aug 8, 2018

View reviewed changes

SenRamakri added 3 commits August 8, 2018 13:53

Design process and template for Mbed-OS

cde5e6e

Added general guidelines section for design process

65433fb

Updated with review comments fixes

196094d

SenRamakri force-pushed the sen_MbedOSDesignProcess branch from 332b7c6 to 196094d Compare August 8, 2018 20:41

Copy edit README.md

072cbb4

Copy edit file for active voice, precise language and consistent style across documents.

cmonr added the release-version: 5.10.0-rc1 label Aug 24, 2018

donatieng pushed a commit to donatieng/mbed-os that referenced this pull request Aug 24, 2018

Move NFC design docs to docs/design-documents/ according to ARMmbed#7561

588c26c

donatieng mentioned this pull request Aug 24, 2018

NFC APIs Design Specification #7426

Merged

donatieng pushed a commit to donatieng/mbed-os that referenced this pull request Aug 24, 2018

Added revision history & table of contents according to ARMmbed#7561

653ab6a

Amanda Butler added 2 commits August 24, 2018 10:52

Copy edit design-template.md

43974e3

Copy edit file for consistency, grammar, spelling and voice.

Edit example_feature_design.md

10b9ad7

Edit template for formatting and major typos.

AnotherButler approved these changes Aug 24, 2018

View reviewed changes

cmonr added the risk: A label Aug 27, 2018

0xc0170 added needs: CI and removed needs: review labels Aug 29, 2018

cmonr added risk: G and removed risk: A labels Aug 29, 2018

0xc0170 added ready for merge and removed needs: CI labels Sep 1, 2018

0xc0170 merged commit 864332f into ARMmbed:master Sep 1, 2018

0xc0170 removed ready for merge risk: G labels Sep 1, 2018

		@@ -0,0 +1,40 @@
		# Design Process for Mbed-OS
		This document defines the software design process for Mbed-OS. Anyone developing for Mbed-OS should use this process to submit the design to get it reviewed from the broader Mbed-OS developer community.

Design process and template for Mbed-OS #7561

Design process and template for Mbed-OS #7561

Conversation

SenRamakri commented Jul 19, 2018 • edited

Description

Pull request type

cmonr commented Jul 20, 2018

SenRamakri commented Jul 20, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

0xc0170 Jul 23, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SenRamakri Jul 20, 2018 • edited

Choose a reason for hiding this comment

0xc0170 Jul 23, 2018 • edited

Choose a reason for hiding this comment

SenRamakri commented Jul 20, 2018

iriark01 commented Jul 23, 2018

SenRamakri commented Jul 23, 2018

Choose a reason for hiding this comment

bulislaw left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bulislaw left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

donatieng left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SenRamakri commented Aug 8, 2018

SenRamakri commented Aug 8, 2018 • edited

SenRamakri commented Aug 8, 2018

cmonr commented Aug 24, 2018

0xc0170 commented Aug 24, 2018

ghost commented Aug 27, 2018

0xc0170 commented Aug 29, 2018

0xc0170 commented Aug 29, 2018

mbed-ci commented Aug 29, 2018

cmonr commented Aug 29, 2018

mbed-ci commented Aug 29, 2018

Triggering tests

mbed-ci commented Aug 29, 2018

SenRamakri commented Jul 19, 2018 •

edited

SenRamakri commented Jul 20, 2018 •

edited

0xc0170 Jul 23, 2018 •

edited

SenRamakri Jul 20, 2018 •

edited

0xc0170 Jul 23, 2018 •

edited

SenRamakri commented Aug 8, 2018 •

edited