Is your feature request related to a problem? Please describe.
If there's a problem with the code of a plugin, we should not crash our whole application because of this.

Describe the solution you'd like
Define a boundary when loading plugins into the system that validates the plugin state on the assumption the plugin author messed up somehow. We should display this (and the error) on the plugins view, so that the user has some idea of what has gone wrong.

Is your feature request related to a problem? Please describe.
Ensure that all contributors to the codebase adopt a common coding style so it is easy to pick up any code in the app and work with it if someone is familiar with the codebase.

Describe the solution you'd like

• Enable the built-in Microsoft Rosalyn Code Analyzers for FxCop under project properties dialog.
• Add or generate an editor.config for the solution.

Describe alternatives you've considered
Don't have an alternative, it would have to be a lot of effort in PR reviews!

Additional context
None.

Is your feature request related to a problem? Please describe.

• We have some namespaces that exist as legacy to the previous structure rather than a specific purpose. This is mostly the Core namespaces.
• We have some file names that either don't match their class or aren't consistent (DependencyInjectionExtensions for example).

Describe the solution you'd like
We should go through the code and adjust the namespaces, classes, and file names to align better with project structure.

Additional context
The exception is the DI extensions, which should remain in the Microsoft.Extensions.DependencyInjection namespace for ease of discover-ability.

Installation needs to be easy for non-developers, so we should have some kind of install/update process in place. Look at WIXSharp or Squirrel.Windows as likely solutions

For our custom C# modules, we'll need a way for them to be dynamically loaded at runtime when the user activates the module while the bot is running.

We could possibly use AssemblyLoadContext.Default.LoadFromAssemblyPath(path) from the System.Runtime.Loader package in order to get the assembly loaded and then we'll use some kind of reflection to find the interfaces we're looking for.

We might be using a custom interface, or it could be something loaded into mediatr, but should discuss before implementing something for this.

This depends on #13 existing, since that's how we'll find the interface we're calling in their code.

Is your feature request related to a problem? Please describe.
The root cause of #33 is potentially a null reference exception.

Describe the solution you'd like
To prevent null reference exceptions we should switch all projects to use c#8 language features with nullable reference types:

    <LangVersion>8.0</LangVersion>
    <nullable>enable</nullable>

Describe alternatives you've considered

• lots of guard clauses
• lots of extra unit tests
• lots of frustration :-)

Additional context
I have disabled unit test that are causing this issue for now in the PR for #9

Store the Plugin/Module data (it won't do anything yet).

• main - current released version.
• dev - collaborative development branch for the next version. Branched from main. Merges into main.
• release-* - collaborative release branch for tying up final loose ends, meta-data, versions, etc. Branched from dev. Merged into main then tagged v*.*.*.* before main merged into dev.
• hotfix-* - collaborative hotfix branch for fixing issues in released version. Branched from main. Merged into main then tagged v*.*.*.* before main merged into dev.

We should allow the user to choose a port number from a set of port numbers to avoid collisions with other applications they may be running.

Current Choices:

• http://localhost:1111

Add documentation for contributing to the project.

Allow user to change the theme of the application at runtime.

Add automapper and mapping profile unit tests.

We need to set up logging infrastructure for the project, since there are many things that will need some form of logging throughout.

Prevent a CustomCommand from running if it's not Enabled.

This depends on #3 being in place first.

A question for discussion

If the app were to adopt FluentValidation as the main validation mechanism for MediatR requests and other object validation rules, then it would be possible for @benrick to create validation rules on stream and then solicit volunteer help to add unit tests for them afterwards, using the validator as a specification.

If desired, it is also possible to integrate validators into the MediatR pipeline - See https://softdevben.blogspot.com/2017/12/using-mediatr-pipeline-with-fluent.html

Save CustomCommand to the data store after making any changes to it.

So users don't have to pick the theme they like every time they load the application, we should save it and load it the next time they open the application.

This requires and depends on #7 being done first.

For developers who want to create custom scripts in python, we should have those plugins get called through the correct adapter for the format the scripts follow.

Further to the fun and games on stream, I have some time to help if you have some issues to work on.

@benrick would you like a PR that branches the DI into extension methods in the seperate assemblies and pulled out interfaces so implementation can be internal scope?

Additionally if you have a way to easily populate a DI container, such as the above extension methods, then I have a Unit Test that checks for missing DI registration in child dependencies.

As the project grows we may wish to add a number of forms of documentation to it. From xml comment style help for the APIs of the Plug-In SDK to general markdown documentation and UML system diagrams.

To help enable this I would recommend switching the project structure to mode the existing sln and associated projects into a src folder and to add a docs folder to the repo root.

This will also be needed if we are to have a CI/CD build pipeline(s) in place as they will also need folders.

Doing this at an early stage, before too many would-be contributors have taken forks, will be best as once more collaboration happens such major structural changes are an issue.

On a related note it may now also be time to create a dev branch from master.

Use GitHub Actions to do a simple Build and Run of the project tests. We'll add requirement to PRs into main/dev that they have to pass the automated build.

Long term plan is that we'll actually need to package up builds using actions as well.

Add yUML document for Component dependencies diagram.

Happy to volunteer for this one.

Restrict the command responses based on the Access defined on the CustomCommand.

This depends on #3 being in place first.

Allow Simple Commands to have text replacement based on argument numbers.

Example:

CommandWord: !hug
Response: "Time for a big hug for $arg1!"

Input: !hug DevChatter
Output: Time for a big hug for DevChatter

Input: !hug @Brendoneus
Output: Time for a big hug for @Brendoneus

This depends on #3 being done first.

Describe the bug
Unit tests for code in the main branch are failing.

To Reproduce
See CI Build - https://github.com/SimonGeering/ChatterBot/pull/1/checks?check_run_id=963659950

Expected behavior
A clear and concise description of what you expected to happen.

Wire up the CustomCommands to send their Response to twitch when CommandWord seen as the start of a message from Twitch.

We should get some top level error handling in place at a minimum as well as establishing a strategy for how error handling is done generally in the application.

This will leverage #46 to log the handled errors as well.

Create an interface for the custom chatter plugins to receive data and take actions based on this. We'll eventually want this interface to be packaged up and be used by developers wanting to build custom plugins for the bot.

@benrick needs to make an architecture decision as to what tech stack to use for a CI/CD Build pipeline.

I would previously have recommended Azure DevOps, but given that we are not looking to do any form of Azure deployment with this one it is not as important. So in the interests of keeping it simple and all in one place, a GitHub Actions option may suffice.

Once a decision has been made I should be able to help get a yaml file together so there is a basic Build and Run Tests pipeline in place for every PR.