[crossfire] Organizational Infrastructure
Mark Wedel
mwedel at sonic.net
Thu Jul 5 22:54:54 CDT 2007
Alex Schultz wrote:
> Hi,
>
> Well that the discussion on organizing efforts seems to have died down a
> bit I'll sum up that the consensus seems to be from what I have seen here:
> -The idea of organizing and focusing on a mini-project is good
> -Some kind of procedure for selecting mini-projects to focus on
> would be good
> -Projects should have a leader responsible for setting out the
> direction of it (and perhaps other duties for it)
> -The idea of some form of vote deciding which project seems good, so
> long as it avoids either players or developers drowning out the other's
> interests
> -Projects should have a leader and outline before being on the
> voting list, and if selected should have the leader create a detailed
> plan shortly afterwards
For the last point, I'd say that projects should ideally have a leader, and
not make that a hard requirement - otherwise, to some extent, the developers can
basically drive what projects are being worked on in any case, by only choosing
to be leaders of projects they want - in a sense, the developers would
pre-select the possible voting choices.
But my thought is more that I could see some projects (or todo items at least)
already have pretty good information - enough to vote on, but no one signed up
to be a leader.
>
> So therefore, the main points that need to be decided are:
> -How exactly should the voting/decision process work?
Quick thoughts:
- For each vote, 5 (or so) projects are voted on
- The #2 vote getter for previous vote is always on the next ballot (and maybe
#3 also). #1 should be done, so no need to vote on that again.
- Remaining ballot entries decided by vote gatherer - based on discussions on
mailing list, perceived importance/dependencies of project, etc. If the just
completed project now opens up the way for other projects (clear dependency),
those could go on the list.
In terms of actual votes, I'd suggest the same type of method used for source
code control - some form of ranked choice voting, so you don't get ties (in the
case of a tie, or very close vote, perhaps the second item automatically becomes
the next one to do, without a vote.
For counting of actual votes, I'd do two counts - one of developers, one of
non developers. Thus, you'd get a list of top choice for developers, and a list
of top choice for non developers, and hopefully they correspond. I'd probably
keep a fairly quick voting time (about a week) - that should be enough time for
active people to vote - sure, someone could be on vacation, whatever, but it
would seem a vote here and there isn't going to be the end of the world - its
not like a lost vote is going to result in the mini project getting canceled -
it just means it won't be done this month.
>
> The third issue though, of what infrastructure should be used for
> deciding what project, is a tricker question I believe. It could be
> handled manually on the mailing list like with the version control vote,
> however there are two issues with that IMHO: 1) It isn't of sufficient
> accessibility to players and 2) it takes notable manual effort to set up
> each time (not a critical issue, but it would be nice to make future
> attempts at deciding a project as effortless as possible).
> I believe that due to both of those issues would be solved by a
> dedicated but simple web based interface for this, however perhaps that
> would be overkill or someone else has a better idea. So what
> infrastructure should we use to plan/decide?
Taking votes shouldn't be that hard - it wasn't for me.
While mailing list may not be as accessible, the flip side is that perhaps
even for player input, we care more about those players that are on the mailing
list, and thus, for lack of better term, more serious players?
A problem with a web based tool is that I think you may need some form of
authentication - otherwise, with the vote totals I'd expect, I think it would be
pretty easy for the vote to get manipulated - one person stuffing 5 votes into
the tool might be a enough.
And ideally, you don't want to have to do revotes because of suspicious
results, etc - ideally, you want to decide that fairly quickly so work can start
- if we spend a month voting, that doesn't really help anything.
Now certainly, the vote for the next project could be started as the previous is
finishing up. But I'm be reluctant to do it too early - the risk there is that
if the current one is 50% done, and the vote is done for the next one, and it is
really cool, you may end up loosing interest (or perhaps people even looking at
what to do for the next one), so that the current one tends to languish. If you
don't really know what the next one is, I think you may avoid that to some extent.
More information about the crossfire
mailing list