[crossfire] Organizing efforts, was Re: Project: New Intro

[Mark Wedel]

  Quickly catching up with followups:

  I'm not sure we really need graphs to track dependencies - I'm not sure they 
are that complex (there are not that many).  What is really needed is to just 
note what the dependencies are, so we can know there is no reason to bring spell 
reform to the table until class/race/skill changes are done.

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 write up the plan, there 
is probably at least one person willing to work on the problem.

I'd expect in most cases the vote to be pretty clear cut.  I think each vote 
would have to be limited to the top 5 (or so) most important projects, which is 
probably decided by the person running the vote (but once again, I think the 
seasoned developers would have a pretty good idea).  Certainly anything that has 
a dependency on it should almost always be on that list.  And certainly opinions 
could be solicited for what should be on the voting list.

As stated in my original message:  The reason that only the developers vote on 
the next project to work on is because it is the developers doing the work.  The 
testers are important, but for the most part, they are not going to help get the 
project get done.  Likewise for the players.  A big concern I have is that if it 
is opened up to non developers, we'll get a vote that basically none of the 
developers (or too few to for meaningful team) agree with.  So the players say 
'foo should be done first', and developers say 'I could care less about foo'. 
End result, foo is never done, and this system fails completely - if the vote 
has no meaning, why do a vote?

I didn't really state it, but my expectation is that for the top priority 
project, as many developers as needed work on it.  I'd think that in most cases, 
that would probably top out at 4-6.  If only 1-2 people are going to work on 
each project, there really isn't any point to this process - the person working 
on the project would just go an do it, and can coordinate with that other person 
(can probably find 1 other person that agrees with that project)

  My hope is that by concerted effort, things get completed in a timely fashion 
(I think also working as a group may make people work harder/finish things up, 
because in some sense, people are depending on them.  If I individually choose 
to work on foo, no one is really harmed/waiting for me if it takes 6 months to 
complete).  The current process is basically the individuals work on projects, 
and they sometimes get completed.  That really isn't working if our goal is to 
complete the stuff on that list.

The idea behind the lead sending out a project detail isn't a 'this is how I'm 
going to do it, tough luck', but rather provide everyone on the list with a 
detail on what/how they think it should be done.  That doesn't stop further 
discussion.  I just think it will save time for the person to do something like 
'I think skills should be redone.  Here is my list on how they should be redone 
- opinions' vs a 'skill should be redone.  Any thoughts?'  Both solicit 
opinions, but in the first case, you provide some starting ideas.  In a sense, 
the person writing that is probably putting his opinions down first, rather than 
waiting for feedback, and then putting his plan down.

  Another reason for this is that the person leading/working on the project is 
more likely to do so if the plan is one he likes.  If the idea/plans that come 
out of discussion are such that the lead developer things 'this is idiotic', how 
likely do you really think it is he is going to spend much work on that?  He 
doesn't think it is the right direction.

----

  I've said it before, and I'll say it again:  Crossfire is a volunteer project. 
  There really isn't any way to force anyone to do anything.

  So the point here is to try and get something in place so that people will 
want to do the work, and the best way to do that is to make sure those doing the 
work have as much say into what is going to be done as possible.  That certainly 
doesn't mean that others opinions are ignored, but there are lots of 
considerations to take into account - complexity of suggested changes, other 
side effects, willingness to do those changes.

  And last point:  For quite some time, the mode of operation has been long and 
varied discussion about all sorts of points, with developers going off working 
on what they want to work on.  The end result of that is very few of the 
'important' projects on the TODO list get done.  so I would hardly say the 
current method is working especially well.