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

[Asmodean]

I have started this thread to counter what I am starting to see here. Namely a bunch of guys starting to make changes, without coordination, and seemingly without access to eachother's documentation.

Now I'll start by saying that I am not a coder, so I won't get into the technical details of this. But care has to be taken somehow that this doesn't get jumbled all from the start.

An online version of VSS would be great, but since we don't have that, and since we don't have access to any other common network than the internet, let's start there. Apolyton.

Let's set up organized thread to

1) Document the changes that are made
2) upload the files that are changed
3) Discuss which of these files go into the Apolyton project, and why

Now there are at least 4 different copiled version out there, all not the same. Do we go with one of these, or do we combine them, taking the best from each. If the Apolyton project is ever to amount to something, coders need to work with the same set of source files, not 4 different sets.

We need to, at some point decide on who does what. We need to decide on the order that things have to be done, and we need to name a project manager. Those that work on the Apolyton project then need to work with the project manager, and do the stuff the he assigns them to do.

Of course things get a little mixed up here at the start, since everybody is excited about this, but somebody has to take over here, or we'll never get anything done.

I would do it, but I know next to nothing about coding (my project management skill lie in other areas) so this rules me out. But what about Locutus? He seems to know about coding, and I am sure he can manage this project.

Asmodean

[Tamerlin]

Thanks Asmodean, I was considering posting something in the forum to say the same thing as you do here.

Unfortunately I am not a programmer myself and though I would like to help I don't know how.

IMO, the first things to work on are:

1 - the bugs and fixes needed for the original game
2 - the sound library
3 - the AI

But before working on anything I agree that the priority should be given to the organization (who is doing what) and the methodology (how to work for the better of the community).

[Ekmek]

This thread was supposed to start organizing. and there are volunteer names and jobs on it.

http://apolyton.net/forums/showthrea...threadid=93204

[Asmodean]

I am aware on that thread, E.

This is not supposed to be an organizer thread. I meant this as a wake-up call, since nobody seems to take any notice that project management is badly needed here.

Let the people who have already volunteered come forth and take over in their assigned areas, before it is too late.

Asmodean

[J Bytheway]

Alas, noone explicitly volunteered to lead anything. Considering how much trouble we had finding presidents for the DG, I'm fairly sure it won't be easy to find a project lead from amongst our ranks.

[kaan]

Dont worry about getting this thing under control, well be bound to make a common source tree sooner or later.
Right now the right thing to do is to let ppl play with the source and get familiar with it, next step is getting the sound and directX things ported to an open platform but thats in the future for now.

my 2 cent
kaan

[Asmodean]

Originally posted by kaan
Dont worry about getting this thing under control, well be bound to make a common source tree sooner or later.
Right now the right thing to do is to let ppl play with the source and get familiar with it, next step is getting the sound and directX things ported to an open platform but thats in the future for now.

my 2 cent
kaan

Hmmm...no next step is getting a common source tree. The project is (in my mind) doomed without it, and without proper documentation.

With code this complex, we simply have to work on the same source. The scale of the project we are undertaking here commands it.

What I seek here is for those that have gotten as far as compiling a playable version to document the steps needed to get that far, and post these steps. Next document changes made after that, so that the rest of us can get an idea in what direction we are heading.

And please...someone with coding knowledge...step up to the plate and accept the position of project manager I'm sure myself, and any others with actual project management experience will be able to help with everything planning related, except for the actual coding. But we do need a project manager.

Asmodean

[Dale]

And yet, when I predicted this sort of thing happening back at the end of July, I got told to shutup. *shakes head*

[Pyaray]

Originally posted by Dale
And yet, when I predicted this sort of thing happening back at the end of July, I got told to shutup. *shakes head*

*Pyaray hands Dale a cookie and gives him a knowing nod.*

[Maquiladora]

Originally posted by J Bytheway
Alas, noone explicitly volunteered to lead anything. Considering how much trouble we had finding presidents for the DG, I'm fairly sure it won't be easy to find a project lead from amongst our ranks.

Keygen was interested, no? I say we force him regardless.

[Asmodean]

Originally posted by Dale
And yet, when I predicted this sort of thing happening back at the end of July, I got told to shutup. *shakes head*

Dammit we have to make this work. This is one of the few instances where I hate to be right. We need management.

On the other hand, I wont be the guy standing at the sidelines shouting at the players to cooperate, but getting ignored all the time.

Dale: What do we do to press this issue??

Asmodean

[Immortal Wombat]

Take charge. At least initially.
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.

[Locutus]

I don't mind being the project manager (of the programmers, I'd probably be (one of) the best candidate(s), if only for practical reasons (being ACS CtP1/2 Manager and all)).

But do we really want a programmer to take this job? It's not like we have flocks of them... And it remains to be seen how many of the ones that we have will still be here in 6 months.

[Dale]

Pyaray:

I see it everyday, in everyway, where excitement over-rules planning. And yes, I am in the IT industry. Looking for a job actually if anyone knows of anything going (since Hewlett-Packard moved our whole division to India)!


Asmodean:

*whispers quietly so Keygen doesn't hear*

We could fill Keygen's PM box with messages to take on the leadership. He was (as Maqu says above) the only one even slightly interested in the lead.

[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).

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).

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.

By that time we should have a good grasp of the game and can hopefully move forward with actually implementing new features and making more radical changes to the game. This should probably start conservatively, with things that everyone agrees should be changed (such as the AI) and only gradually move on to features that not everyone may be happy with (such as strategic resources). That way people who want a better AI aren't automatically stuck with a resource system they don't like. But that's long term thinking...

[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!