Add CONTRIBUTING.md

[tsmartt]

This is meant to be a set of guidelines for anyone contributing to follow, and this PR is meant to spark constructive criticism.
Please feel free to propose additions where any might be lacking, and modifications with good justification.

[yachtcaptain23]

IMO the article is dogmatic, other's like such as https://thoughtbot.com/blog/reusable-oo-composition-vs-inheritance suggest that the developer should understand the trade-off between composition vs inheritance.

[tsmartt]

I agree, that's why I put prefer.

[tsmartt]

Another thought I had was mimicking the behavior of mutations and interactor, but which a much simpler setup, something like:

# frozen_string_literal: true
module My
    class Service < BaseService
        class COMMAND
            include ActiveModel::Validations
            validates_presence_of :param1
            validates_presence_of :param2
        end
      def self.build
        new(tp_need: TPNeed)
      end
      def initialize(tp_need:)
        @tp_need = tp_need
      end
      def execute(param1:, param2)
        result = @tp_need.do_something(param1, param2)
        if not result
            return fail("Some error message")
        end
        success("Did thing")
      end
    end
  end
end

The base class would be something like 40 lines of ruby and would give us what we need with no extra frameworks. It instantiates the COMMAND class with the parameters and validates, if validation passes, it calls execute.
By passing the params both to self.build and execute, we are free to use ruby's type system features to help stabilize the code. To invoke it you just My::Service.build.call(param1: '1', param2: '2')

For most things you could probably even leave out the COMMAND -- since the type system could take care of basic things like non-nil, etc.. could add it in for more complex scenarios like email validation.

But we can leave this for a followup-PR.

[tsmartt]

@yachtcaptain23 going to merge this tomorrow unless any further thoughts.