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. _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
