[crossfire] Organizing efforts, was Re: Project: New Intro
Mark Wedel
mwedel at sonic.net
Mon Jul 2 17:02:47 CDT 2007
Alex Schultz wrote:
> Mark Wedel wrote:
>> Having project leaders before the project is worked on/voted on makes sense.
>> And as I think about it more, it would generally be good to have the detailed
>> project plan before voting, so people actually know what they are voting on.
>> OTOH, writing up project plans for all the potential things to do is a daunting
>> task. The flip side is that if someone is willing to rite up the plan, there
>> is probably at least one person willing to work on the problem.
>>
> Well, I would say perhaps not the full detailed plan, but at least some
> sort of outline of what would need to be done. I wouldn't want this
> requirement to make the process too much effort really.
Yeah, outline would be fine. Something more than 'spells should be
rebalanced', but less than a final plan. As said, once the project is decided,
there would be more discussions, so you probably don't want to spend a large
amount of time on a detailed plan that may have lots of changes/additions.
So I'd probably say two levels of plans:
Brief overview - used in the voting stage, maybe about a paragraph long. Can be
informal.
Details plan: Used to divide up work - I'd note that this plan may be more
functional (maps of this nature is needed), because that may be easier to divide
work parts into, where as the overview may be a broader design goal.
Note that I'd tend to expect that most discussions would be more in the nature
of broader design guidelines, and the lead would then have to take those
discussions and form it into the more functional plan of what changes are needed
to get there.
The reason I think this is the case that in order to really be able to have
many people work on one project, they need to have somewhat detailed idea of
what is expected/needed.
To use the beginning map discussion as an example - right now, discussions are
broadly based on type of maps and the like needed. But at some point, that
needs to get transformed into a list of the maps needed with a brief
description, so that I, or other people, could sign up to make some of those
maps and know what is needed.
> Well, so far as I can see, two valid concerns have come up on both sides
> of this:
> 1) Only developers vote and the interests of what makes the game fun and
> what players want is lost
> 2) Both developers and players vote and that tips the scale to a project
> that developers are highly disinterested in and thus little gets done
> about the 'chosen' project
>
> Because of these issues, I don't believe we can simply have just
> developers, or just developers and players as the voting pools. The way
> I believe this could be solved to satisfy both concerns would be by
> making this "Top 5" list to vote on, heavily influenced by polling
> players about what interests them of the larger list of projects. This
> way, what players are interested in will be remembered and will
> influence the process, but the selected project will not end up being
> one that will disenchant developers.
One thought here might be to do something similar to what was done with the
voting for versioning control system. Use a form of selective voting, open it
up to everyone, but categorize the different vote takers, eg, developers,
testers, players.
thus, if developers vote foo as #1, and bar as #4, and players vote bar as #4
but foo as #5, but both developers and players vote qubit as #2, then maybe
qubit is done instead, as it has general support from both sides.
I agree that we want the players involved. I just think that if the players
drove the process, things may not work. I expect that there are a lot more
players than developers, so their votes if taken individually could swamp the
results (if only 25% of the players agreed on something, that could still be
more votes than all the developers if they agreed on a single thing).
So I'd probably say now that the vote should be open to everyone, but the
person running the vote (most likely me) can weigh the input from different
groups of people in different ways. Probably one list of preferences from
developers, and another from non developers, and hope something on that list
coincides.
More information about the crossfire
mailing list