Issue Template

[AGlass0fMilk]

We should come up with an issue template, similar to what mbed-os has, which includes required fields for service proposals.

We can follow the lead of BLE standard specifications that can be found here:
https://www.bluetooth.com/specifications/gatt/

Current working format (example with DeviceInformationService):

<!-- 

Use the following template when submitting proposals for new CUSTOM services to this repository.

 Linking to a standard characteristic/service specification document on the Bluetooth SIG's website is sufficient for standard characteristic/service proposals. When proposing standard services, also include specific requirement information for the Mbed BLE implementation of this service (eg: memory constraints, baremetal support, etc) 

The following site can be used to generate a long-format UUID for custom services/characteristics: https://www.uuidgenerator.net/
This site is useful for generating markdown-formatted tables: https://www.tablesgenerator.com/markdown_tables
-->

### BLE Standard Service: Yes/No
### Proposed UUID(s) or link to specification document:

| Svc Name                 | Char Name         | UUID   | Qualifier | Mandatory Props | Optional Props | Security |
|--------------------------|-------------------|--------|-----------|-----------------|----------------|----------|
| DeviceInformationService | -                 | 0x180A | -         | -               | -              | -        |
| -                        | ModelNumberString | 0x2A24 | O         | Read            |                | None     |

## Overview:
<!-- Give overview of what the proposed services are intended to do -->
The Device Information Service exposes manufacturer and/or vendor information about a device.

## Detailed Description
<!-- Describe each service/characteristic in more detail for each include the following information: brief description of purpose for characteristic, functional requirements, non-functional requirements (eg: build w/o RTOS, memory size constraints, etc), ideas for API -->

### ModelNumberString Characteristic
The Model Number String characteristic shall represent the model number that is assigned by the device vendor.

**Characteristic Behavior**: The Model Number String characteristic returns its value when read using the GATT Characteristic Value Read procedure.

**Functional requirements:** Must be compatible with baremetal builds

[pan-]

That's a great start @AGlass0fMilk , I think we need the following things to structure the activity:

1. RFC/Service proposal template: I think that's what you're proposing above
2. Issue template for raising defects
3. PR template to propose additions
4. Unit test infrastructure (base CMake file with mocks/stubs and utility)
5. ADR template to store architecture decisions
6. Circle CI integration to run unit tests.

Of course the list can be extended but 1, 4, 6 seems to be needed first. What do you think ?

On the template above, I like the format it foes straight to the point. I wonder if Must be compatible with baremetal should be part of an ADR. It makes reuse of services consistent across build targets.

[AGlass0fMilk]

@pan- I agree, I think getting testing setup is a high first priority.

I started with a service proposal template because I wanted to put together a standard format before making issues for a bunch of new services... then we can prioritize what we decide are the most popular services first.

Once we have the infrastructure in place I would like to make a GitHub project to triage the initial batch of proposed services.

Is there a way we can set up automated integration testing? I imagine we would need some BLE targets set up on a publicly-accessible server somewhere. I would host it but my home IP address isn't static 😄

Not sure what you and @paul-szczepanek-arm have set up to run the mbed-os-bluetooth-integration-test-suite. Is it part of CI or do you have to run it manually?

[pan-]

@AGlass0fMilk I made an ADR for the base of the testing setup: #10, the implementation for the setup will follow today. It only covers unit testing.

The infrastructure for integration testing is being reworked at the moment and we don't have access to the old infrastructure so it will come latter. Nothing prevents us to propose pattern for the integration test, even if it is run manually it is still much better than nothing.