🎩 What? Why?

Refactors the proposals seeds to individual methods.

There are lots of good reasons why doing this (lower the complexity of these classes, make it more readable, etc). But my main reason is to provide an API to be able to work on some issues that we need to have lots of contents (like #11874).

So, this API would be like:

seed = Decidim::Proposals::Seeds.new(participatory_space:)
seed.create_proposal!(component:)

Apart from that I fixed some sampling that was too complex, and I've removed the Endorsements from here (as we're doing it at #11996). Another difference is the use the n and m variables. Apart from not wanting to pass it as a parameter, I prefer to have some randomness there, so we don't have always the same contents in all the spaces (like always only one rejected proposal, another approved, another evaluating, and so on)

For making the review process easier, I tried to do granular commits, so I recommend reviewing this on a commit by commit basis.

Testing

Regenerating the development_app database should have different kind of proposals (almost the same as before):

$ bin/rails db:drop db:create db:migrate db:seed

You can play with the methods like this too:

participatory_space = Decidim::ParticipatoryProcess.first
component = participatory_space.components.find_by(manifest_name: :proposals)
seed = Decidim::Proposals::Seeds.new(participatory_space:)
800.times.each { seed.create_proposal!(component:) }

♥️ Thank you!