I guess no one agrees on my philosophy on managing an open source project. I'll sum them up here, you can agree or dis-agree.
I think the project should be well managed, at all times, it should know exactly what it wants to be implemented. These descriptions should be specific, as specific as possible. They should be discussed, and agreed upon by a majority. Rather than shooting for a specific time period you want to release in, we should take advantage of the no deadlines of open source, we should shoot for what features we want our program to have. What things we want it to do. And we should allways know what we want done (like I said earlier). Instead of having general "make the game better" type to-do's, the specific ones take the burden off the implementor to know what to implement. Smaller tasks work better, as you devide what you want to achieve into small, do-able parts. Like, being able to do a task a night would be excellent (rather than doing long nights, the tasks should be small enough for that). Then you have atleast something, preplanned, that you can do with that small amount of time you find squeezed in somewhere where you have nothing else to do, rather than feeling anything you start to do will take an indredibly long time and you'll never achieve it in that small amount of time you've found squeezed inbetween sleeping and eating sunday night, so you just say why bother, and make no progress. I personally do this allot (its one of my failings), and I know allot of other people who contend to the same thing. The descriptions of what I would like to see (and some of what you guys wanted if you suggested anything, which seems unlikely at this point), aren't very one day-ish. They could easily be seperated into a bunch of logical sub tasks, and you can slowly work your way through the subtasks, in those small time periods, and make progress, and soon enough (sooner than you predict commonly), you finish. As well, having a full, in depth to do list allows you to know what your missing, and when your complete. It is, indeed, you will actually have concrete details telling you that you are finished, rather than trying to decide, on the spot, whether you have done enough or not. You should ignore the amount of people you have available, as wiping it off and saying "i don't want to do it, i hope someone else on the project does" makes no progress. That being said, I do have an excuse for not being able to program allot of the things I suggest: I don't know the system, and it isn't well documented enough for me to learn. That also being said, we should put documenting the system a top priority, above all else, and when every nook and cranny is documented, we can proceed, because that "work force" will finally be trained enough to do their job, and any second before then is a waist of time. By ignoring your work force, you set higher goals, and surprise yourself by achieving them. Indeed, being too ambitous doesn't help, but you can set very high long-term goals and still make out fine as long as you set out short term goals to achieve them. I'm setting out short term goals to reach a long term goal: release a kick ass game with a top notch user interface, intuitive gameplay, and nice graphics. You shouldn't throw away good ideas, ideas that would make your game better, just because they sound too far out of sight to be do-able. Every one of those ideas, when implemented, puts you one step closer to releasing a kick ass game. If you have already released a kick ass game, those ideas makes your game more kick ass, so throwing them away doesn't make your game any better. All of that being said again, ideas like "Globulation 2 should be in 3d" are certainly far fetched, but once again, globulation 3d would be more kick ass then globulation 2 (no offense), so, if it comes into the possibility relm (We find someone willing to do 3d graphics for globulation 2), then why through away the idea. Instead, advertise that we are looking for people willing to do allot of 3d graphics, and, if luck has it, we find a person, get good graphics, do some partial rewrite of the front-end library, and bang, our game has become that much more kick ass. All in all, I think big lists are better. You know what you want, you have planned goals. But those big lists should also be well sub-devided, tasks managed, and very specific, keeping the "work-force" on task, including oneself. I think we shouldn't throw away ideas that would make our game better just because we are lacking in workforce, instead, work towoards those goals, however slowly, and ask for help wanted on the areas you can't work towoards (like a hardcore programmer trying to do nice looking 3d graphics). Agree/dis-agree, I think this method would suite this project, like others, well. Feel free to discuss my method, as allot of you seem to disagree. _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
