Re: [glob2-devel] Thats it, we need a plan

[Bradley Arsenault]

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.