Hi all, our bug scanner has reported some NPE bugs.

1.The first one is at FileInJarReadableDataSource.java#L99 since the variable inputStream may be null.

2.The second one is at [SimpleHttpClient.java#L1

expected input in json file : "tolerance": true,

but chaos init tolerance input is written as "tolerance": "True"

Some patterns should be avoided when writing programs with P# (especially as some of them can break our controlled testing infrastructure). We should make sure to document these.

Add document for docs/issue_process.md to summarize how we should use issues and do a PR.

This should include:

• What the labels mean.
• What they imply for people's work queue (design and feature issues versus bugs)
• How to close them.
• How to integrate issues into meetings (read before meeting, add comments after meeting)

Make a PR.

The following text is a request from Emmanuel Ardillon in the EDF internal bug tracker:

Subset simulation is available in OpenTURNS, but it does not appear either in the "Theory" part of the doc or in the "Examples" part.
The only available information concerns the SubsetSampling class in the API part of the doc.
An example would make it more accessible to users.
What is needed:

• a use cas

Many aspects of Streamly are written in spaghetti code... Functions should be explicit and should take input rather than reading global variables.

More object-oriented functions should be used.

This will be the first code cleanup of Streamly!

Implement a Concatenate function for Q1Way and Q2Way. It would empty one queue by moving its elements into another queue.

Currently, we use JSON for serialising data as it was easy to implement and is human readable. This should be switched to Protobuf or similar before a production deployment.

Maybe having a drop-down and sorting out incidents based on their difficulty could be handy.

I have some suggestions on how to make an actual documentation for OpenCossan (yes again 😄) since now the Wiki is pretty much outdated (at least for development) and the internal Matlab documentation is horrible to use.

I will prepare an example of what I have in mind and present it at the first day of the Cossanthon.

In the Software module test planning tables, there is no way to indicate which test technique(s) were selected for the module/unit. Another field needs to be added to the Software test planning tables to allow the user to document which test technique(s) were selected.

This will be easiest to implement by adding a checkbox at the end of each row. It will also require a new field in the RTK Pr