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