Problem:
Currently the project documentation is lacking in key ways.

Solution:
Add documentation where missing and alter where incomplete.

AC

As a collaborator when I check the project docs...

• I find modules have docs that clearly outline module purpose and introduce high level concepts and context
• I find function docs that makes usage and behaviors clear
• Provide good examples for adding my own

Problem:
We have no test coverage for randomizer.ex

Solution:
Write some tests!

AC

• write tests for each function

Problem:
The Matrix module has some untested behaviors in it.

Solution:
Write tests to cover the untested behaviors.

• read tests to understand behaviors that are currently tested
• read module to understand what behaviors are there
• add tests to cover untested behaviors
• consider adding tests to cover edge cases and talk with team about it

Behaviors

Tested

• Matrix.new
  • returns a Matrix struct
  • that we return the same number of rows and columns
  • checks that we have a index of where entities were randomly placed

Untested

• check that the entity is indexed correctly and that the entity is not some other entity
• if entities is an empty vec the matrix is returned unchanged

Problem:
Collaborators may find it harder to contribute if it isn't clear where stuff should go or what it should be named.

Solution:
Add some stubs that follow project naming convention.

AC

As a collaborator when I get ready to contribute I'd like...

• To have some modules that will be the home for the code I'm going to write

Problem:
Currently project files/modules are not where they should be give current architectural thinking and naming conventions.

Solution:
Move the project files/modules and rename where appropriate so there is internal consistency.

AC

As a collaborator when I survey the project I find...

• Boilerplate code generated by Phoenix is tucked away so it makes project code easier to see
• Things are internally consistent in terms of project structure
• Modules are named according to a consistent naming convention that makes module purpose clear

Problem:
Currently the project README.md is a mess and is only really useful to its creator.

Solution:
Edit and add to it so that it is useful for collaborators.

AC

As a collaborator when I read the README.md I understand...

• The project's purpose/goals
• What the project is trying to do
• The grand vision of where we're trying to get to
• The general design philosophies that drive the architecture
• Architectural overview
• How to contribute
• Code style concerns of note

Problem:
Currently the repo doesn't have anything set beyond the defaults.

Solution:
Alter the defaults so they fit what we are doing here.

AC

As a collaborator when I want to work on the project I find that there are...

• Only the labels I would care about
• Issue templates that cover
  • bugs
  • features
  • enhancements