As the game is nothing made of stone, I am all with Luiji when he says
that “everything can be changed after release 2.0.0,
implicitely”. Music, just like any other asset in the game, is open for
improvement or even replacement in later development always. Stonifying
the decision on something is against our intention to continuously
improve the game. The vote I called for is not meant as an instrument to
force an asset into the game for all times, but only to achieve a
releasable state of 2.0.0 in a reasonable amount of time. Implicitely
this of course means that the song will be in later versions as well,
but it does not imply that it is exempt from improvement efforts.
It is however correct when datahead points out that such decisions are
usually not reversed. This is actually good for the game, because
otherwise we would be voting for every single asset for every version of
the game. However, datahead, you then conclude from “usually” to
“always” without further elaboration which I don’t think is
correct. Following my above explanations there is always the possibility
to improve on the game in all of its parts, including replacement or
removal of musical assets in case there’s a valid reason to do it.
Your voting suggestion fails to fit the game development intentions. In
case your option 1 is voted for we are bound to never remove the song
again, which is a rather undesired result in my opinion. Even more, you
revise your own suggestion for option 1 again with the unless clause
following, which makes it obvious that it is not a good idea to vote on
the subject in such a way: There is not enough data to vote on
currently, and for an ever-binding decision there will never be. Can you
predict whether kirbyfan will revise his song later again? Predict
whether someone entirely different steps up with a new replacement? A
vote should always result in one, clear decision, that does not need to
recur to conditions of any kind unless absolutely required. Or, in other
words: Votes should solve a problem at hand for now for an indefinite
amount of time into the future, but when new data comes in it may be
time to re-think and even re-vote. Option 1 is actually a non-vote thus:
Decide on something forever, unless it needs to be redecided. If you
take apart the “forever” and the “unless...” (which are as shown
contradictive), then you arrive at the call for vote I made: Decide for
now, and revise if data changes.
Your option 2 hits the same problem from a different side. While option
1 aims to stonify things admitting that it can’t, option 2 voids the
purpose of voting completely. It summons up the very same vote again
after the 2.0.0 release, and then we can repeat the procedure
indefinitely for every new release. The purpose of voting is to find a
binding decision for the future on the ground of the data we have at the
current moment. Option 1 wants to decide for the entire future
regardless of changing data, and option 2 wants to decide only for now
and not the future. Both options thus fail to fit the purpose of voting.
Quintus's proposed vote seemed to imply a permanent decision
No. My understanding of a vote, as outlined above, is “decision for an
indefinite amount of time into the future, under the condition the
environmental data does not change”. What startles me a bit is that you
actually argue against stonifying decisions, then try to achieve that
with your option 1, which you then fail to achieve with the condition
you attached to it.
but if we aren't going to make a decision based on all options,
we should just accept the music as-is and be done with it. This,
however, defeats the purpose of critiquing songs or artwork.
As I explained the two options you gave are not of much use, this
conclusion falls. Apart from this, practise has shown in the forums that
voting does not imply stashing any critiques. We made suggestions to
kirbyfan’s song, and he improved his song. After a while, we ended up
with two high-quality versions where nothing more is to improve. At that
point, it is just to vote on which of the two versions we should use. In
my opinion this is a proper procedure to include artwork into the game
if the team fails to agree on one of multiple good versions. Of course,
voting right when a new artwork is submitted is wrong, but we haven’t
done this here, thus I don’t share your fear of critique disappearing.
Sidenote for everyone: You don’t have to sent a courtesy copy to the
mailinglist :-). Please strip your emails from the long fullquote at the
end, the ML contains all the messages even in sorted order.
I will reject HTML emails. | Ich akzeptiere keine HTML-Nachrichten.
Use GnuPG for mail encryption: | GnuPG für Mail-Verschlüsselung:
My key fingerprint: | Mein Schlüsselabdruck:
B1FE 958E D5E8 468E AA20 | B1FE 958E D5E8 468E AA20
8F4B F1D8 799F BCC8 BC4F | 8F4B F1D8 799F BCC8 BC4F