PROJECT: Project management - let's take care this doesn't go south before we start

[Locutus]

Originally posted by Immortal Wombat
Its the Rule of Sloth: If nobody wants to do a chore, it always comes down to the person who is most annoyed by it not being done.

Ah, so there's a name for how I became an ACS Staff Member... does that mean I'm not the first to get suckered in like this?

[Immortal Wombat]

Oh no, I just invented that. Surprisingly accurate though.

[ahenobarb]

I don't know who is going to get the job, but a good place to start would be to have everyone agree on a list of the real bugs that are in the game (like veterans status, the AI not building commercial improvements, etc.) and then taking each item in the agreed list and making a sticky thread at the top for each of them. Then the coders from groups 1&2, mentioned here can cherry pick the problems they want to work on and when one is solved, move on to the next one. Then when all the bugs in the list have been eliminated and the mod limits have been lifted, remove the sticky status of the threads, and release new patch of the game.

After that, turn to SLIC and the unimplemented feature of the game like PBEM, space, pacman, whatever... With sticky threads for each of them as well.

Then, the part I like to call "crazy ideas" from group 3. Work them into the game, with sticky threads.

Nice, neat, topical.

[Asmodean]

Originally posted by Locutus
As for getting organised, I don't really mind people playing around with the code... that's still the best way of getting to know it.

But I agree we will soon have to start with at least systematically documenting our action, preferably also acting in a systematic fashion and planning our actions.

Right now there may be several different versions of the game out there, but they don't make major changes to the code yet. Just a few lines here or there, nothing that can't be merged (assuming everyone at least documented their own changes).

If that's your decision as would-be project manager, then I respect that. I do advise caution, though. I suggest amending the FAQ with something along the lines of:

If you are a coder, and expect to do any work on this project,
it is vital that you document every change you make to any file in the source tree.
Relevant comments must be added in the code itself,
and you must furthermore keep an external record of every change you make,
and where you have made it, for easy reference.
No undocumented code whatsoever can expect to end up in the Apolyton project.

While we sort out how to get organized, what tools to use, who does what and what to do first, I think it's fine if people mess around with the code a bit and see if they can fix the most obvious bugs. This will also help in quickly getting out a patch once we really get going, which will greatly help in maintaining an interest in this project (it's a plain fact that people in general want to see results and want to see them fast, otherwise most will just loose interest and move on to other things).

Again, the fastest way to results here, would be to get a firm structure going, with regards to who does what. Right now we still only have a bunch of programmers working independently.

When that is done, then it is time for the project manager to decide what gets done and in what order. There seems to be a general concensus that the first order of business should be bug-fixing and implementing the changes from 1.11. If that is the case, fine. But it is the project manager who decides this.

After the first patch we could focus on documenting the code more thoroughly and systematically, and hunt down and fix the more complicated bugs. Once most/all of the known bugs have been fixed (this may be a while), and depending on how long that will take and how many bugs are found maybe also a few times before that, we will want to release another patch.

Why make it harder for our selves. Are we really that good, that we can expect to release a working patch from code that is not systematically documented. I know it's the tedious part, and I know it will put some people off the project, but if we are going to do this, why not do it right?

Look, I know I am the word of caution here, and I you want me to shut up, just say so. I will do it. But I have simply seen too many projects die due to poor management. Let's not make this one the next, shall we?

Asmodean

[Pyaray]

Again, the fastest way to results here, would be to get a firm structure going, with regards to who does what.

Be careful, when it stops being fun, people will leave in droves. Firm structures are the way to make things work in the corporate world, but I've never seen it be succesful in a net project. Net projects only survive as long as they're interesting, if it starts feeling like work, people will start resigning if they don't get a paycheck.

Pyaray

[Asmodean]

You know, you're probably right, pyaray.

By firm structure, I am not that concerned with dates and deadlines. Those things are nigh on impossible to work with on a net project anyway. What worries me the most is the integrity of the source. The coordination between a growing number of programmers that go ahead on their own, with no central coordination.

Perhaps!! it will go well, but there is no guarantee, which is why I would feel more comfortable with a project manager assigning tasks, and taking care of all the loose ends. Off course it would be the foremost task of this guy, whomever it will be, to listen to the coders, and assign only tasks that they're interested in. A net project is doomed if people get to do things they don't like.

Asmodean

[DDowell]

I actually hesitate to change anything in the code since I don't know who is supposed to do what and when.

I don't like the idea of having ten versions of the game lying around. It should be ONE Apolyton version and for that we need some sort of management.

I regret that I can't take it on myself since I'm already involved with another project and don't have time to be anything but a programmer on this one.

[centrifuge]

Originally posted by ahenobarb
I don't know who is going to get the job, but a good place to start would be to have everyone agree on a list of the real bugs that are in the game (like veterans status, the AI not building commercial improvements, etc.) and then taking each item in the agreed list and making a sticky thread at the top for each of them. Then the coders from groups 1&2, mentioned here can cherry pick the problems they want to work on and when one is solved, move on to the next one. Then when all the bugs in the list have been eliminated and the mod limits have been lifted, remove the sticky status of the threads, and release new patch of the game.

After that, turn to SLIC and the unimplemented feature of the game like PBEM, space, pacman, whatever... With sticky threads for each of them as well.

Then, the part I like to call "crazy ideas" from group 3.
Work them into the game, with sticky threads.

Nice, neat, topical.

Ahenobarb as a good idea here. This sounds like an easy way to get organized while keeping everyone: programmers and non-programmers involved.

[Keygen]

I'm still interested in the job

And I truly wonder how I missed the release of the code until today but I didn't expect the release was so closed.
And the funny thing is I was planning to come up with some directions of what we should do with the code one of these days to keep the interest alive

So yes, if that's OK with you I will step forward for the job.

[DDowell]

KeyGen, you are my hero!

Your first priority must be (in my view) to enable the use of CVS (with server here on Apolyton perhaps?).

[MrBaggins]

Sounds great.

As your first task, you might consider coordinating the effort to ensure that we figure out what is causing the problem with the code. We need to find exactly why the darn thing is crashing for some, but not for others. There has to be a common issue, or something those that have got it working have done that others haven't

Martin seems to have it working fine. As does John?

DDowell, Locutus, Solver and myself I know are having issues.

It seems something to do with Assert problems. We need to get some collaboration going to find the solution so that everyone can assist, otherwise there is a lot of potential help going to waste

[Martin Gühmann]

Originally posted by MrBaggins
Martin seems to have it working fine.

I wouldn't call it working fine, I had to make shure that no slic code with slic 2.1 functions were present, otherwise it crashed after the first occurence of a slic function not found message. The debug build gives me a lot of asserts related to UnitGarrisonCounts every turn, even if I had a debug build without this behaviour. But removing the lasted files didn't help.

-Martin

[Asmodean]

Way to go, KeyGen.

Now we can get this show on the road



Asmodean

[Locutus]

So first we had no project leader and now we have two?

Maybe it would be best if the two of us shared that responsibility? After all, I'm pretty much coordinating everything on behalf of the Apolyton staff anyway, and in that responsibility I have access to a lot of stuff others such as Keygen don't (website, directory, ftp, news, forum moderator functions, possibly a CVS server, a direct line with Markos and Dan, Activision, etc). On the other hand, I'm also a programmer and I'm probably most useful to the project when actually coding.

So maybe Keygen and I should work together like Markos and Dan do: let Keygen do the daily routine of organizing the people, setting targets, etc (a la Markos) and let me do background work like website, 'tech support', external communication, etc (a la Dan). And of course we could fill in for each other whenever the other one's not available (though if I'm not here Keygen would need a lot of help from Markos, Dan and Ming).

[Immortal Wombat]

Hooray! A plan!