Part of me worries we are collecting feedback a bit too soon, as we haven't finished a vote or had even one ratification phase yet (I think ratification is really important to curb some of the "excesses" we may get from the system).
But since we are here, my thoughts so far.
The Amazing Good
Considering this is our first run of this (a pilot effectively), honestly, I don't think it could have gone better. The issues have been minor and were worked out quickly, all of the early vetoes were reasonable to me, we are seeing major participation on both the proposal and voting fronts, to me its been a big win so far.
The Recursive Bottleneck
One of my fears is that this looks like a tremendous effort on Recursive's part. A lot of organization, review, retitling, moving of threads, etc. I am worried about burnout longterm with this process, or simply the process grinding to a halt should Recursive go on a break or a vacation for a while. While I want to create the most organized and efficient process we can, at the end of the day it has to be sustainable. That might mean less polish and less organization.
The "Rider" Problem
I don't mind large proposals with multiple parts....within reason. For example, making multiple changes to a policy tree at the same time is fine to me, its all "in theme". I do think there have been proposals that ask for X and Y, and Y has NOTHING to do with X. This similar to riders in the US congress, where bills are passed to do a thing, and people slip in a little cheddar for their own interests that has nothing to do with the original bill. I want to curb that whenever possible, so I do think we should focus on keeping proposals as close to their "true intention" as possible. If you want to make a change to skirmishers...don't be tossing in changes to recon units. If you want to change a building, don't throw in a CS change in the same proposal....etc etc.
Ratification - Is 1 month enough time?
This is a wait to be seen, but I am a bit concerned that 1 month is not enough time to do proper ratification. Not everyone plays as fast as I do
Some people won't even play 1 game in a month. We may need to extend this to a few months to ensure people are actually playing with these changes before they give feedback.
Multi-choice Yes/No votes
I can respect the multi-choice for proposals with multiple options. But I think its really weird to have a yes/no vote that you can vote on both. If you want to abstain....don't vote.
Proposal Freezes
I'm already seeing a lot of calls to open up more time for changes and amendments. During the voting phase, during the sponsorship phase, etc. I STRONGLY urge us to resist these temptations. I think it is VITAL to the new process that our more casual forum goers and developers get a dedicated time that they can review things and vote with the confidence that they can go away for a few weeks, and what they voted on remains as is. We need to respect that there will be people who literally swing by the forum once a month, do all of their voting, and then return to the shadows.
I get that people are excited, and the idea of waiting another month "seems so long", but realistically, this is LIGHTNING fast compared to what we do now. Because right now its all up in the air, you have an idea, maybe it gets some attention, maybe it doesn't, maybe we do a poll....realistically most ideas right now take a lot longer than a month to get through. The idea that you can come up with an idea and have a definitive answer on whether it will go into the mod in less than a month is MUCH faster than we operate now.
A dedicated voting forum
I think we should have a dedicated forum for this. Yes we will have less proposals in the future, but I think its disruptive to other more casual threads. I get it takes away the proposals from the main page, but frankly, if people can't be bothered to check out 1 subforum to vote....they shouldn't be voting.
Enforcement
One elephant in the room, what happens in a scenario where a dev decides they don't like the proposal they are coding. Maybe they make a slight change to the proposal in their code to make it more like what they want, or maybe they just keep pushing it off for implementation (aka the classic the president doesn't enforce a new law, so it effectively "dies"). Ultimately this is something for the devs to work out amongst themselves, ultimately they have to do a bit of this today anyway, but its something in the back of my mind. Or...perhaps long term the answer is "sponsorship does mean a dev is interested in your change". If ultimately we are proposing a bunch of things that the dev team doesn't like...that probably won't serve us long term (after all they have to be code AND maintain those changes). Perhaps it would be better if sponsorship was more discerning.
![[party]](/images/smilies/partytime.gif "Party [party]")
