[crossfire] Organizing efforts, was Re: Project: New Intro

Nicolas Weeger nicolas.weeger at laposte.net
Sun Jul 1 03:57:52 CDT 2007


>   My thought here is that each month (or maybe more/less frequently, based
> on how long it takes to do the different things), the developers should
> decide what is the most important thing to change/add/fix.  My rationale
> here is that if the developers agree that some issue is most important,
> they are much more likely to help out.  If the general developer response
> is 'that isn't very important', then you could pretty much figure they
> probably aren't going to put much effort in.  Note it may be reasonable to
> do less frequent votes, on the basis that after the top priority is done,
> whatever was #2 probably makes sense to be the next top priority, etc.  But
> new projects may pop up, or the completion of one may spawn a new one
> (before such and such feature was added, no one thought of something or it
> wasn't feasible).

No, not developers. Developers *and* players. I'm afraid developers deciding 
will lead back to current situation, focused on the code and not contents.
For us it's sometimes sexier to document the whole code than fix a messy 
complex bug that isn't too important (but still bothers players) :)
One important thing, though, is documentation. We should clearly document 
things, so we have 1) reference when something seems strange 2) detailed 
explanation non coders can understand and comment on (example: bracers will 
add armour, but only if it's the "best" armour bonus - thus if you cast a 
spell giving armour+5 your bracer armour+2 won't have any effect ; or how 
resistances / immunities work).

>   In the context above, developer is anyone that is willing to help out to
> get the project done - doesn't mean coder, could be map maker, artist,
> person writing documentation.  but someone that just plays the game
> probably shouldn't be included, as that isn't going to help get the project
> done - my idea here is that you want the project decided on by those
> actually going to do the work. One the project is decided on, all are
> welcome to pitch in ideas, etc.

Player feedback is important. I would even say that's the critical thing, else 
we end with a developers-only game.

>   I tend to think that it is best of the project lead starts by sending out
> a fairly detailed document - the reason I say this is that a fair number of
> developers have been around a long time, and can probably come up with a
> fairly complete starting plan without a lot of input.  They should still
> send that out and get input, but having a good starting point may trim a
> week or two off the discussion, and also provide a clearer picture to
> everyone what the idea is. Some of the basis here is also that some points
> have already been extensively discussed in the past - new points are
> welcome, but we don't necessarily need to fully discuss all the issues
> again.

Again, developers will focus on code, whereas we need also players.
Once something is decided, yes we can start doing code / preparing for coding 
tasks. Not before.

>   The role of the project lead/coordinator is to take the pieces and make
> sure they all work.  In the case of the map example, look over the maps,
> make sure they meet various standards, basic idea behind the map, and link
> up the exits, etc (possible that some maps completed before the ones they
> link to).

No, the role of the coordinator is to make sure the work is done, he's not 
necessarily the only one working :)

>   I don't mean to have draconian policies in place in the above - in fact,
> just the opposite.  What I really want is something in place so that
> projects can be decided fast, what needs to be done decided fast, and that
> broken down into pieces so that it can be completed rapidly.  That's not to
> mean without thought, but lots of things has been extensively discussed,
> and all the discussions in the world don't really make it so that the
> project gets done any faster.

We do need a draconian policy on some things, though. IMO, we should reject 
things if they don't bring anything to the game, or are messing with other 
things.
As an example, I'd say my logger and newspaper plugins shouldn't have been 
committed in their current state - they are basically useless for now, and 
didn't really correspond to any needed feature.
So we should forbid some commits sometimes, else the code will go astray.


Nicolas
-- 
http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref 
de l'aléatoire !]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070701/1cd1228b/attachment-0001.pgp 


More information about the crossfire mailing list